Is following chart correct?

(De)coders chart - rule > uses less CPU power and battery life on portables.

1. WAV - fastest (simple decoder, very often hardware implemented*), normal battery life (on flash based players) vs short battery life (on HDD based players)
2. MP3 - very fast (more complex decoder, very often hardware implemented), long battery life
3. FLAC - fast (complexity of decoder less than mp3's decoder BUT not often hardware implemented(?)), normal battery life (on flash based players) vs short battery life (on HDD based players)
4. WV - slower than FLAC (more complex decoder, not hardware implemented(?)), short battery life
4. WMA - slow (complex decoder, very often hardware implemented), short baterry life (on flash and HDD based players)
5. AAC - slow (complex decoder, hardware implemented), short battery life
6. OGG - slow (complex decoder, rarely hardware implemented), short battery life
7. MPC - slow (complex decoder, not hardware implemented), very short battery life
8. APE - very slow (very complex decoder, not hardware implemented), very shot battery life

*) hardware implemented == DSP chip and NOT firmware decoder
?) not sure

I wouldn't say aac has a short battery life.

Generally speaking, complexity in decoding lowers battery life, while compression ratio increases it (less access to disc).

Is there any relevance to why you need to know the complexity of each? and could you make the title of the post shorter next time. Most decoder implementations are firmware based as far as I know.

I believe FLAC is amoung the fastest formats.



I don't think any of these are right either.



MPC is actually very fast. Probably faster then most or all of the other lossy formats. IIRC the stock int decoder was so fast, no optimization was needed at all for real time decoding in the Rockbox port.



Not sure what you mean by this. Either way, DSP chips aren't really used for audio on most portables. I also don't think you need a hardware decoder for WAV. Instead you just parse out the PCM and DMA/etc it to the DAC's input buffer.

Yeap, the title is stupid long - sorry. About hardware implementation of codecs - iAudio U3 for example has hardware based mp3 ,wav, wma decoder but ogg and flac are software implemented thus slower and more power hungry. I'm just asking because I'd like to know that - sorry for bothering.

FLAC decoding is relatively fast, Vorbis on the other hand is power hungary on the decoding side, because of some extra code in the low-level libraries that is not needed and taking up space. Most firmware implementations have some port of Tremor, including the Rockbox. Tremor is the reason Vorbis has hardware support to begin with though.



I am not really sure what else you could use to develope a decoder outside of an embedded system?

If you think Tremor is any faster because it doesn't have "extra code that is not needed taking up space", you are completely mistaken. It might use less memory and need less ROM, but it's not faster.



You're talking about an ASIC. DSP based decoders are also "firmware based" for all intents and purposes. But is the difference relevant? I suspect that at least one reason why there are so few dedicated ASIC's for newer formats is that the general purpose CPU or DSP's of today are powerful and power efficient enough that they simply aren't needed any more. At most, the chip will have some acceleration hardware for typical decoding/encoding operations. On the other end of the spectrum are chips which have decoding hardware for almost all major formats. But those tiny, WMA and MP3 decoding chips that are popular in those 5$ Flash MP3 players, I doubt you will see them for other formats. And I don't think it matters.

A dedicated ASIC?

A powerful enough microcontroller?

I use wavPack (high quality option) @352 kbps nominally on my iRiver H140.
Battery life is only 15-20% lower than mp3 @270 kbps abr nominally.

Full ack. I remember reading a thread (this forum) when someone posted a comparison of battery life and the formats he used. Conclusion: aac and mp3 where very close together.

Thank you all for feedback.

@Garf: If I understood correctly - only some parts of decoding process are accelerated through dedicatated DSP/ASIC, rest is done by software? And I'd like to ask you as the AAC guru - is AAC decoder easy to implement in ASIC or DSP? Is it integer or fixed point? Do it need some kind of buffering during decode process (like OGG)? Thanks in advance.

All lossy codecs I know deal with floating-point compressed data. It's up to the programmer to use fixed-point arithmetic or floating-point arithmetic. It doesn't matter which, but on portables without FPUs, fixed-point arithmetic is the norm.

No, the Rockbox port of MPC wasn't real-time initially. Some assembler stuff was required for that, as well as figuring out what data to put in fast RAM. Currently, on iRiver targets, --standard mode files seems to be a little faster than Oggs at -q5 to -q6 (based on tests with one file, so take that with a grain of salt). MP3 is noticably faster (and AAC is noticably slower). The implementation can make a large difference.

It entirely depends on the implementation.



What is "easy"? What part of the AAC standard do you want to support?



Those are the same thing, aren't they.



It's not possible to answer this without you being more specific what kind of buffering you mean. Any codec using the MDCT (MP3, Vorbis, AAC, WMA, AC3, ATRAC, ...) or any kind of overlap needs to buffer.

I guess that only AAC LC can be considered for hardware implementation because no prediction is used (if i'm right) so is less complex and uses less CPU time. About buffering question, I'm afraid that I can't be more specific about that. Sometime ago I had e-mail conversation with iRiver technician about implementation of OGG on their iFP1xx series. And was told that it can't be done on that specific model because it doesn't have onboard RAM which is needed for OGG decoding and NOT for MP3, WMA decoding. That's it.

You can do the other profiles in hardware too. In fact, I'm quite sure somewhere in the standards process the exact requirements can be found. It's just more work, and you end up with a bigger chip, for a small performance gain, which is why nobody supports anything besides LC (and the HE extensions).



MP3 and WMA decoding also need RAM. Either he meant that the device has specific, dedicated chip for MP3 and WMA (very likely, it's how >90% of the players out there work), or/and he meant that the controller chip didn't have enough RAM to handle Vorbis (the memory requirements for a Vorbis decoder are far higher than those of any other format).

Actually, the U3 uses a Telechips TCC770, which is an ARM9 CPU for decoding all formats. This is "hardware" in the sense that theres a CPU running software to decode things

http://news.apacsource.com/doc/dochtmshow....4333&type=3



Modern portables don't use a DSP for anything. Most don't even have DSPs (Ipod, Iaudio, most iRiver), and if they do, they're used primarily for video support.

All formats are decoded in fixedpoint/integer (which are the same!) since DAPs use ARM or 68k cores with no FPU.

I was refering to ARM since thats what I'm familar with. Looking at the ARM source, theres only a single ARM specific ASM block and it appears to just perform MACs without a hardware MAC unit.