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: (De)coders chart - rule > uses less CPU power and battery life on p (Read 10438 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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

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

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

Reply #1 –
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).

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

Reply #2 –
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.
budding I.T professional

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

Reply #3 –
Quote
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)


I believe FLAC is amoung the fastest formats.

Quote
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


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

Quote
7. MPC - slow (complex decoder, not hardware implemented), very short battery life


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.

Quote
*) hardware implemented == DSP chip and NOT firmware decoder


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.

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

Reply #4 –
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.

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

Reply #5 –
Quote
Vorbis and FLAC are software implemented thus slower and more power hungry


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.

Quote
Not sure what you mean by this. Either way, DSP chips aren't really used for audio on most portables.


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

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

Reply #6 –
Quote from: HotshotGG on
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.


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.

Quote from: bukem on
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.


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.

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

Reply #7 –
Quote from: HotshotGG on
Quote
Not sure what you mean by this. Either way, DSP chips aren't really used for audio on most portables.


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


A dedicated ASIC?

A powerful enough microcontroller?

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

Reply #8 –
Quote from: bukem on
4. WV - slower than FLAC (more complex decoder, not hardware implemented(?)), short battery life

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.
lame3995o -Q1.7 --lowpass 17

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

Reply #9 –
Quote from: Jebus on
I wouldn't say aac has a short battery life.

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.
portable: 128 kbps cbr AAC
local: -7 FLAC

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

Reply #10 –
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.

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

Reply #11 –
Quote from: bukem on
Is it integer or fixed point?

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.

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

Reply #12 –
Quote from: Mike Giacomelli on
Quote
7. MPC - slow (complex decoder, not hardware implemented), very short battery life


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.


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.

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

Reply #13 –
Quote from: bukem on
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?


It entirely depends on the implementation.

Quote
And I'd like to ask you as the AAC guru - is AAC decoder easy to implement in ASIC or DSP?


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

Quote
Is it integer or fixed point?


Those are the same thing, aren't they.

Quote
Do it need some kind of buffering during decode process (like OGG)? Thanks in advance.


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.

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

Reply #14 –
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.

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

Reply #15 –
Quote from: bukem on
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.


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).

Quote
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.


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).

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

Reply #16 –
Quote
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.


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

Quote
@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.


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.

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

Reply #17 –
Quote from: Lear on
Quote from: Mike Giacomelli on

Quote
7. MPC - slow (complex decoder, not hardware implemented), very short battery life


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.


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.


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.