Does .ogg-files drain more battery power?

[Lejnoss]

My battery has ran out quite fast since i've started use .ogg instead of .mp3.
Is this the reason?

cpchan edit: Sorry I think I either hit "edit" accidentally instead of "reply" or there was a temporary glitch in the software. Sorry for messing up your post (strange that it quoted properly).

[cpchan]

Originally Posted by Lejnoss

My battery has ran out quite fast since i've started use .ogg instead of .mp3.
Is this the reason?

First please don't use the term ogg since ogg is a container format and can contain a number of codecs even video.

To answer your question, yes Vorbis is more cpu intensive then mp3 (it is a more modern and advanced codec). However, since Vorbis can achieve the same quality as your mp3's at a much lower bitrate, you can lower it to save power. I have great battery life using "-q 3" (-q 6 on my desktop computer). Also for lower bitrates (< -q4) you should be using the AoTUV branch (Monty doesn't have time to integrate the new tunings into Vorbis proper right now). Here is a link to get it:

http://www.rarewares.org/ogg-oggenc.php

Just search for AoTUV on the page. For more info about AoTUV follow the link in my sig.

Charles

[kugel]

I don't think that lower bitrates lead to higher battery life. I think it's it's the opposite: The more compressed the file is (=lower bitrates) the higher CPU time is needed to decompress/decode.

I just know, that WAV is the most battery friendly codec. No compression, and highest bitrate. FLAC also gives a decent batterly time (higher than MP3) even though it has 500kbit/s or more.

Generally, the higher the compression complexity is, the more CPU time is needed. And AFAIK the compression complexity increases with lower bitrates.

But don't quote me on that. I'm really not sure on that one.

[cpchan]

Originally Posted by kugel

I don't think that lower bitrates lead to higher battery life. I think it's it's the opposite: The more compressed the file is (=lower bitrates) the higher CPU time is needed to decompress/decode.

No, not for a lossy codec. Remember how lossy compession works- the lower the bitrate, the more data it throws away dictated by the Psychoacoustics model used. Thus the lower the bitrate, the less data it has to decode. This is the recommendation from Hydrogenaudio and the Xiph mailinglists for years.

Originally Posted by kugel

I just know, that WAV is the most battery friendly codec. No compression, and highest bitrate. FLAC also gives a decent batterly time (higher than MP3) even though it has 500kbit/s or more.

First of all wav is not a codec- it is a container format mainly used for PCM and compressed PCM. Also you cannot compare FLAC to Vorbis or MP3- FLAC is lossless.

Charles

[saratoga]

Originally Posted by cpchan

To answer your question, yes Vorbis is more cpu intensive then mp3 (it is a more modern and advanced codec).

This is what I assumed too, but its actually not true. Tremor (the vorbis codec we use) is extremely efficient on ARM:

http://www.rockbox.org/twiki/bin/vie...anceComparison

Its actually faster then MP3 and my WMA codec. Eventually I want to move some of the Tremor code into the WMA and AAC codecs, in which case WMA will probably become a little faster and AAC suck a lot less, but for now Vorbis is faster then all the lossy codecs except MPC and MP2 I think.

That said, it doesn't have to be this way! I've been hoping someone would take a look at our MP3 codec and look for ways to speed it up. Its already quite efficient, but I'm sure it could be made at least as fast as Vorbis.

Originally Posted by kugel

I don't think that lower bitrates lead to higher battery life. I think it's it's the opposite: The more compressed the file is (=lower bitrates) the higher CPU time is needed to decompress/decode.

This is a pretty sensible thought, but it doesn't work quite like this for most codecs. In general, as you lower the bitrate, the codec simply stores values less precisely, so the total work needed to decompress doesn't increase. In fact, it typically gets faster just because theres less data to fetch into memory, and less data to Huffman decode.

Though for codecs that actually do compress more at lower bitrates like WMA, very low bitrates can use a surprising amount of CPU power. For WMA, this starts at 32kbps and keeps rising as the decoder needs to do more and more work to recover the audio.

[cpchan]

Originally Posted by saratoga

Its actually faster then MP3 and my WMA codec.
That said, it doesn't have to be this way! I've been hoping someone would take a look at our MP3 codec and look for ways to speed it up. Its already quite efficient, but I'm sure it could be made at least as fast as Vorbis.

Interesting. Do you know how much Tremor have changed and optimized in Rockbox as compared to the original code from Xiph?

Though for codecs that actually do compress more at lower bitrates like WMA, very low bitrates can use a surprising amount of CPU power. For WMA, this starts at 32kbps and keeps rising as the decoder needs to do more and more work to recover the audio.

I presume this only applies to WMA Pro and not standard.

Charles

[kugel]

Originally Posted by saratoga

Its actually faster then MP3 and my WMA codec. Eventually I want to move some of the Tremor code into the WMA and AAC codecs, in which case WMA will probably become a little faster and AAC suck a lot less, but for now Vorbis is faster then all the lossy codecs except MPC and MP2 I think.

The table you linked shows me that MP3 is faster than ogg, even on ARM(=PP?) targets (slightly).

€dit: Well, I took a close look now. On iPod and e200 the Vorbis is slightly faster, except for the _96 files.

[saratoga]

Originally Posted by cpchan

Interesting. Do you know how much Tremor have changed and optimized in Rockbox as compared to the original code from Xiph?

A lot of both Tremor and MAD (the Mp3 codec) have been rewritten in assembly for speed, so the code is quite different but the algorithm has changed little or not at all.

Originally Posted by cpchan

I presume this only applies to WMA Pro and not standard.

Just standard as far as I know. No one knows how Pro works, so I can't comment on what it does.

€dit: Well, I took a close look now. On iPod and e200 the Vorbis is slightly faster, except for the _96 files.

I'm mostly thinking of the 192k results, where Vorbis is 17% faster. That works out to about 7MHz fewer needed for Vorbis, a savings of about 2.4 mA when decoding.

[cpchan]

Originally Posted by saratoga

A lot of both Tremor and MAD (the Mp3 codec) have been rewritten in assembly for speed, so the code is quite different but the algorithm has changed little or not at all.

Ah, that explains it.

Just standard as far as I know. No one knows how Pro works, so I can't comment on what it does.

Thanks for the info. I didn't know that WMA (which I don't use) is more CPU intensive at low bitrates.

Charles

[Lejnoss]

Omg, that was a lot of answers!

Ya, so it's Vorbis henceforth!
I use -q6 and I think I use AoTUV branch,
so then I seem to have chosen right at least!
By the way, with "faster" do you mean more battery
efficient?

Thanks for taking you time!

[cpchan]

Originally Posted by Lejnoss

By the way, with "faster" do you mean more battery
efficient?

Yes.

Charles

[saratoga]

I sent out an email to the developers list explaining the state of codec optimization in rockbox:

http://www.rockbox.org/mail/archive/...-06/0003.shtml