Compression formats and power consumption Options

[CamelD]

Have there been any studies with regard to compression formats and power consumption? I.e. a study of which formats conserve battery power the best while still offering good sound quality and compression level.

Would such figures vary from one device to the next, or are the decompression algorithms well standardized among manufacturers?

This post has been edited by CamelD: Apr 10 2010, 03:48

[CamelD]

Found two articles:

http://electronicdesign.com/article/embedd...st-Bang-Fo.aspx
http://www.cs.thu.edu.tw/files/paper/ISLab/islab_96_5.pdf

The first (ostensibly) takes listening quality into account and provides clearer results using a "bang for the buck" metric, but is somewhat brief and only covers a handful of formats. The second (as far as I can tell) only mentions listening quality with respect to the AC3 format, but is more thorough in other ways. I suppose the data from the latter could be correlated with listening tests that measure at multiple bit rates, but am not sure exactly.

What do you know from your own experiences?

This post has been edited by CamelD: Apr 10 2010, 03:47

[doccolinni]

http://www.cs.thu.edu.tw/files/paper/ISLab/islab_96_5.pdf

Wow, I had no idea OGG was so hard on power consumption...

No wonder the MP4 player I used started running out of power more quickly after I switched to using OGG exclusively.

What I would like to see is a comparison that shows how much power consumption FLAC causes, too. I've bought SanDisk Sansa Fuze and currently use lossyFLAC and I am almost positive that decoding FLAC uses less processing power than MP3, OGG, WMA or anything like that because FLAC decoding is based on nothing but integer arithmetic, but I would like to be able to get the actual ratio of how much power it consumes compared to decoding MP3 or OGG, so I can know if it's worth it.

[Chef]

FLAC is asking your player to process 600-1200 kb/s vs OGG trying to decode things in a somewhat inefficient way... OGG is still way ahead.

Someone did some tests you can look at:

http://forums.sandisk.com/sansa/board/mess...thread.id=14326

It's pretty gross how bad ogg is on power consumption vs mp3 though. I use OGG because I want to support open source, but man... Still, I wonder how other open source lossy formats are doing.

This post has been edited by Chef: Apr 10 2010, 04:37

[doccolinni]

FLAC is asking your player to process 600-1200 kb/s vs OGG trying to decode things in a somewhat inefficient way... OGG is still way ahead.

Someone did some tests you can look at:

http://forums.sandisk.com/sansa/board/mess...thread.id=14326

It's pretty gross how bad ogg is on power consumption vs mp3 though. I use OGG because I want to support open source, but man... Still, I wonder how other open source lossy formats are doing.

Holy shit, man.

Well, then I guess MP3 is still the way to go...

Aw crap, I liked using OGG and/or FLAC.

I was sure FLAC would be less heavy on power consumption because I thought decoding losslessly encoded audio (especially FLAC which is decoded very easily) would be much easier than decoding something like MP3 or OGG, that was the very reason I decided to use lossyFLAC on Sansa Fuze in the first place. I didn't realise bitrate itself has such a huge impact.

Although, speaking of the bitrate, since I use lossyFLAC (I preprocess with lossyWAV and then encode to FLAC), the bitrates of my FLAC files are averaging at 400 kbps, which is more than two times less than the usual FLAC bitrate, which I suppose was used in those tests. I wonder how lossyFLAC, having such lower bitrate, would perform...

I guess I'll have to do my own test one day.

This post has been edited by doccolinni: Apr 10 2010, 05:26

[saratoga]

Someone did some tests you can look at:

http://forums.sandisk.com/sansa/board/mess...thread.id=14326

It's pretty gross how bad ogg is on power consumption vs mp3 though. I use OGG because I want to support open source, but man... Still, I wonder how other open source lossy formats are doing.

FWIW those tests are not representative of Vorbis decoding performance in general due to an issue specific to Tremor as compiled in the Sansa firmware. I've contacted Sandisk earlier and passed to their engineers a suggestion on how to fix it. Hopefully we'll see this addressed in future firmware versions.

A much, much better source would be the rockbox codec performance wiki page:

http://www.rockbox.org/wiki/CodecPerformanceComparison

CPU Clock speed for ARM7TDMI:

flac_8.flac 13.37MHz
mpc_128.mpc 22.95MHz
vorbis_128.ogg 28.13MHz
wma_128.wma 28.64MHz

Finally my dual core version of libmad for mp3:
lame_128.mp3 20.80MHz

And the original, single core version:
lame_128.mp3 38.19 MHz

Its interesting to note MP3 is sort of a worst case scenario for ARM7TDMI since it places a lot of pressure on the load store unit compared to more modern (and efficient) formats like WMA and Vorbis which are much kinder with respect to memory performance demands.

[saratoga]

Have there been any studies with regard to compression formats and power consumption? I.e. a study of which formats conserve battery power the best while still offering good sound quality and compression level.

Mine is the only reasonably good one I've seen. And its imperfect since I have not yet gotten around to completing AAC optimizations in Rockbox, and I have my doubts about how good our MP3 optimizations really are.

Most others seem to suffer from the same problems as the ones linked in this thread: they compare a few formats using poor decoders on just a few hardware devices. This renders their results meaningless for anything but the exact setup used by the authors. That said, if anyone has a comprehensive comparison using the best known decoder for each format, I would love to see it.

Would such figures vary from one device to the next, or are the decompression algorithms well standardized among manufacturers?

They vary a lot from CPU to CPU and even more from decoder to decoder. A great example is the Sandisk results linked earlier. On the same hardware decoding the same flac file, the sandisk firmware gets approximately 9 hours, while rockbox gets approximately 20 hours. The difference is that sandisk uses libflac, while rockbox now uses ffmpeg flac. Previously we also used libflac, but we stopped because it was really, really slow

Variation from CPU to CPU is also important. As I mentioned above ARM7TDMI (which dominated MP3 players from 2000 to 2006 or so and was used in the Ipods, Rio Karma, Sandisk Sansa, and various iRiver players) had a lot of trouble with MP3 due to the filterbank used in most MP3 decoders (or at least all I have seen) which requires a lot of non-sequential memory accesses. The ARM9TDMI improved on the ARM7TDMI's design by allowing a non-sequential memory access up to every clock cycle, which gave a very large boost to MP3 performance:

(Clock needed for realtime on ARM940T)
lame_128.mp3 51.06MHz
vorbis_128.ogg 45.66MHz

First, ignore that more MHz are now needed. The ARM9 cores clock much higher but still use roughly the same speed memory, so the MHz to decode goes up in this test. Second, note that the huge difference on ARM7 is thus reduced to less then 10%. Quite an impressive difference. And funny that only now are MP3 players getting CPUs that are actually well suited for decoding MP3, whereas before they were a lot better at Vorbis!

[knutinh]

I guess that an adhoc formula for power consumption when playing music could be something like:
P = A(bitrate)+ B(codec_complexity)

I then assume that A is a function that depends on the actual playback device and describe how much power is needed to read a number of bytes.

B then say something about how well a given cpu/dsp is suited for turning battery energy into codec "complexity".

PCM should have a complexity of ~0, but a significant bitrate. That is why mobile CD-players do not have infinite battery capacity.


We know that the perceived quality can usually be improved by increasing the bitrate or by increasing the codec complexity (until transparancy is reached). Throwing battery consumption as well into the game introduce an interesting complexity to codec design and choice.

-k

This post has been edited by knutinh: Apr 10 2010, 13:52

[doccolinni]

PCM should have a complexity of ~0, but a significant bitrate. That is why mobile CD-players do not have infinite battery capacity.

Mobile CD players also have to keep a CD rotating, which is very power-consuming.

[saratoga]

I guess that an adhoc formula for power consumption when playing music could be something like:
P = A(bitrate)+ B(codec_complexity)

I then assume that A is a function that depends on the actual playback device and describe how much power is needed to read a number of bytes.

B then say something about how well a given cpu/dsp is suited for turning battery energy into codec "complexity".

PCM should have a complexity of ~0, but a significant bitrate. That is why mobile CD-players do not have infinite battery capacity.


We know that the perceived quality can usually be improved by increasing the bitrate or by increasing the codec complexity (until transparancy is reached). Throwing battery consumption as well into the game introduce an interesting complexity to codec design and choice.

Unless you have a hard drive based player, bitrate doesn't have much impact and that formula doesn't work. For HD players its probably pretty accurate.

For flash players, mostly bitrate only matters because you'll have to spend a bit more time doing bitstream parsing, and because at different bitrates you might have different codec features enabled for some formats.

[CamelD]

Still sort of confused with regard to bit rate and listening quality. Are all formats at the same bit rate equal to each other in terms of listening quality, differing only in file size? Most of the tests seem to assume that quality at a certain bit rate is the same.

Also, how does ATRAC rate in terms of power consumption? It has been present in portable MiniDisc players for a lot longer than most other formats.

This post has been edited by CamelD: Apr 10 2010, 20:26

[saratoga]

Are all formats at the same bit rate equal to each other in terms of listening quality, differing only in file size? Most of the tests seem to ignore this.

Different formats at the same bitrate have the same file size, but may or may not have equivalent quality.

The quality of different formats at different formats is a much harder question, and one that has been studied in great detail elsewhere.

Edit:

Also, how does ATRAC rate in terms of power consumption? It been present in portable (MiniDisc) players a lot longer than most other formats.

Computationally its very similar to MP3, except much slower. I've got tests for our optimized ATRAC3 decoder on ARM, IIRC its something like 1.5x slower then MP3 but I don't have the numbers handy. I don't have numbers for ATRAC1, but its fairly similar to ATRAC3.

This post has been edited by saratoga: Apr 10 2010, 20:28

[Chef]

I was going to consider changing what format I encode to for my PMP, but now I just don't know what to do! OGG is bad on some version of a Sansadisc player I don't have, but what I gather from saratoga's replies are that this doesn't necessarily mean it's bad on my Cowon S9. DAP reviews need to start incorporating this into their testing haha... I don't have to willpower to leave my player alone long enough to let it die out.

Oh well, at least this is a more encouraging answer to 'why aren't I getting even half of 55 hours' than 'because your files are 60 kb/s bigger than the factory testers files.'

[CamelD]

How do I tell which OGG decoder my player has or which decoder is best to use? I have a Samsung YP-S2.

This post has been edited by CamelD: Apr 13 2010, 02:23

[saratoga]

How do I tell which OGG decoder my player has or which decoder is best to use? I have a Samsung YP-S2.

I think everything uses Tremor. Unless you know ARM assembly, theres no way to check.

[CamelD]

How do I tell which OGG decoder my player has or which decoder is best to use? I have a Samsung YP-S2.

Oops, I meant "which format is best to use?"

I think everything uses Tremor. Unless you know ARM assembly, theres no way to check.

OK, thanks.

This post has been edited by CamelD: Apr 16 2010, 00:45

[saratoga]

Oops, I meant "which format is best to use?"

Assuming its not available online or in the documentation, you will have to try it and see.