Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Codec performance comparison (Read 41286 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Codec performance comparison

I recently did some performance comparisons of various codecs in Rockbox on arm9e (specifically a Sansa Clipv2).  For this test I clocked the CPU and memory at 40MHz, to mimic the typical low power settings an MP3 players CPU would run at while in low power mode with the screen off.  The results are pretty interesting.

Code: [Select]
128k (give or take for AC3) lossy files:

a52_stereo_192.ac3	17.29MHz
mpc_128.mpc	        18.01MHz
wma_128.wma	        19.26MHz
vorbis_128.ogg	        20.16MHz
nero_128.m4a	        24.26MHz
lame_128.mp3	        26.35MHz



Vorbis uses tremor, mp3 uses libmad, mpc uses peter's fixed point decoder, wma uses my fixed point port of ffmpeg's decoder, nero uses libfaad combined with a lot of code from ffmpeg and a52 uses liba52.

Some caveats:

AAC isn't as well optimized as the others.  It uses the same transform, windowing code as Vorbis, but libfaad is kind of a mess. 

Vorbis and WMA are pretty well optimized. 

MP3 is extremely well optimized, and probably faster then a lot of commercially shipping decoders judging by the much better battery life in rockbox then the retail firmware when decoding mp3.  All the pure MDCT codecs use the same MDCT, which is pretty close to the performance arm ltd claims for their optimized mdct.  MP3 uses its own MDCT, which is within in assembly and within a few instructions of the best known algorithm. 

All low power, low accuracy, etc modes are disabled.  All codecs decode at full resolution, typically > 16 bit.

Some thoughts:

A52 is really fast because its really simple.  It has two transform block sizes, both of which are shorter then most codecs.  In stereo mode its basically nothing but huffman, inverse quant, and then mdct.

AAC is really complicated and the spec isn't freely available, which makes optimizing it difficult. 

MP3 is really slow compared to pure MDCT codecs or pure subband codecs in spite of intense optimization.  This is because it has to do both an MDCT (like Vorbis, AAC, WMA, etc) and a synthesis filterbank (like MPC).  Neglecting the synthesis filterbank, it performs similarly to the other small block sized mdct codec, a52.  This leads to decreased battery life using the format. 

WMA uses the most complicated MDCT scheme of the codecs, but is otherwise extremely simple at mid to high bitrates (low bitrate coding is more complicated).  Consequently, its very fast and very easy to optimize.  In terms of quality per decode time, it and vorbis are probably towards the top.

People say vorbis is slow, but actually its one of the fastest formats tested.  Its fairly complicated, but reasonably easy to optimize and in general efficiently designed.  It does have a very annoying habit of using an unpredictable amount of memory though.  Some files can use up to 500KB of RAM, but most modern ones only need  < 250KB.  Annoying.

I didn't post ATRAC3 results because I don't have an encoder, but its also really, really slow because its a hybrid format like MP3 with a lot of really weird stuff added on top that no other format uses.

ffmpeg codecs are typically the fastest and best written.



Code: [Select]
Lossless Formats

flac_5.flac           7.07MHz
flac_8.flac           7.67MHz
wv_fastx3.wv          24.11MHz
wv_normx4.wv          28.69MHz
true_audio.tta        36.62MHz
ape_c1000.ape         40.66MHz
wv_high.wv            45.07MHz
ape_c2000.ape         57.69MHz
ape_c3000.ape         86.34MHz
ape_c4000.ape         221.24MHz

Some caveats:

flac uses ffmpeg, ape uses rockbox (which was since ported to ffmpeg), wavpack and TTA are the official decoders. 

Lossless formats are more boring to me, so I can't say as much about them.

All the formats are really well optimized, though flac, and ape are probably the best optimized.


Some thoughts:

FLAC is amazingly efficient.  Its probably the fastest compressed format in remotely widespread use.  All formats seem to compress about the same, so if you want to use lossless on batteries, you should probably look at flac first. 

APE is really, really slow.  I didn't benchmark c5000 at low clock speed since I didn't have all night, but it nees around 900MHz.  I would not use APE on a portable device.

Wavpack is probably fast enough that you wouldn't notice much difference in battery life verses flac.  Most devices can't lower the clock below 20MHz anyway.


More results if anyone is interested:

http://www.rockbox.org/wiki/CodecPerforman...0MHz_PCLK_40MHz

Codec performance comparison

Reply #1 –
Wow, that's blown all my preconceptions out of the water!!

I've been using Lame V5 on my clip+ (rockboxed), because I thought it maximised battery life.  Now I'm ready to chuck that in and move to ogg. I much prefer the artifacts introduced by ogg at low bitrate than those created by mp3.

I'll stay away from wma, and it looks like mpc wasn't optimised for low bitrates.

Codec performance comparison

Reply #2 –
Thanks a lot for this interesting comparison, saratoga! One question:

Quote from: saratoga on
WMA uses the most complicated MDCT scheme of the codecs, ...

Can you elaborate, please? What does WMA do MDCT-wise that the other codecs don't?

Chris
If I don't reply to your reply, it means I agree with you.

Codec performance comparison

Reply #3 –
Quote from: C.R.Helmrich on
Thanks a lot for this interesting comparison, saratoga! One question:

Quote from: saratoga on
WMA uses the most complicated MDCT scheme of the codecs, ...

Can you elaborate, please? What does WMA do MDCT-wise that the other codecs don't?



Most codecs have 2 MDCT sizes that are used, one for frames that need good time resolution, and one for frames that require better frequency resolution.  For example AAC-LC uses 256 and 2048 frequency domain samples.  It also puts limits on the order they can be used.  WMA however has 5 transform sizes (and WMA Pro which is very similar uses 6) arranged in powers of 2 increasing to 2048.  It also doesn't put strict limits on the order they can be in, presumably to maximize efficiency by picking the optimal time/frequency tradeoff for every few hundred to few thousand samples.  No other codec that I've seen does this, although different AAC profiles use different size transforms, and Vorbis allows any 2 window sizes to be chosen by the encoder. 

I'm not sure why only MS does this, theres no computational cost in the decoder, and their encoders do take advantage of the extra window sizes very frequently in ordinary files.  Its possible it just doesn't help that much in practice or that they've patented it.

edit:  can't spell

Codec performance comparison

Reply #4 –
would lower bitrate make vorbis even faster to decode?

asking because most of my audio books are at q0, and my music is at between q-2 and q-4(a few are higher due to very noticeable artifacts, but most are in the 2-4 range 2-3 being more common)

Codec performance comparison

Reply #5 –
Quote from: edwardar on
Wow, that's blown all my preconceptions out of the water!!

I've been using Lame V5 on my clip+ (rockboxed), because I thought it maximised battery life.  Now I'm ready to chuck that in and move to ogg. I much prefer the artifacts introduced by ogg at low bitrate than those created by mp3.

Correct me if I'm wrong, but AFAIK rockbox will run in boosted mode (240Mhz) on the Clip+ anyway, because changing clock speed introduced all sorts of crashes. So for now it shouldn't make any difference which codec you use...

Codec performance comparison

Reply #6 –
Quote from: Northpack on
Correct me if I'm wrong, but AFAIK rockbox will run in boosted mode (240Mhz) on the Clip+ anyway, because changing clock speed introduced all sorts of crashes. So for now it shouldn't make any difference which codec you use...

I did read about these problems, but I assumed they had been fixed because people are now getting 15+ hours out of their clip+ (more than the original firmware). However, I never read that this actually had been fixed... I'll look into it.

Either way, knowing that ogg will not use more power than mp3 is enough for me to switch to ogg, considering the better quality at low bitrates.

Codec performance comparison

Reply #7 –
Updated with new results.  Mohamed Tarek has been busy working on WMA Pro and also found time to spot a nasty little oversight in my WMA code thats been slowing it down 3MHz or so all these years.  WMA Pro is also now nearly as fast as the other codecs, but much room for improvement remains.  Andree Buschmann has also been busy with WMA Pro and AAC.

Quote
I did read about these problems, but I assumed they had been fixed because people are now getting 15+ hours out of their clip+ (more than the original firmware). However, I never read that this actually had been fixed... I'll look into it.


Its still disabled on some Sansas, but I think theres still power savings since the CPU can idle more on faster codecs.

Codec performance comparison

Reply #8 –
Hmm seems I can't edit the first post, so heres the updated table:

Code: [Select]
128k (give or take for AC3) lossy files:

wma_128.wma            16.37MHz
a52_stereo_192.ac3    17.29MHz
mpc_128.mpc            18.01MHz
vorbis_128.ogg            20.16MHz
wmapro_141k.wma    22.13MHz
nero_128.m4a            22.35MHz
lame_128.mp3            26.35MHz

Codec performance comparison

Reply #9 –
could we get some speex numbers, im just wondering if speex is faster or slower then vorbis