The only reason I have not made a switch to MP3 VBR for my Dell DJ 20 gig is concern over whether or not a VBR mp3 will consume more power than a CBR file, say 128kbps. I searched all over the net for answers to this question, yet returned no results. If anyone has an Ipod or such and knows the answer to this question, I would appreciate any responses. Thanks.

It won't use more battery then CBR of the same average bitrate. Higher bitrate, CBR or VBR, will drain battery faster.

Though the difference is not very large on most players.

I got the feeling, CBR is the better choice.

There is a difference.

In my Rio Karma, plain CBR plays for about 1 hour more.

In my SonyEricsson W800 plain CBR plays for about 1 hour more.

I use LAME V5 and V4 for VBR and 128 or 160 for CBR

That is just my personal experience.

Please don't make useless posts.

Is there some data missing here, or did I miss something?

There's definitely something missing

I remember a test.. I think it was on Misticriver (performed on an iRiver, off course). If I remember correctly, the difference in battery life was negligible, both on a flash and a HD player. I might be wrong, though.

usually with VBR, the file size is a little bigger, which may require more HDD usage on a player with an HDD, on a flash player, it wont make much of a difference.

The more useful comparison would not be which of CBR vs VBR uses less power at the save average bitrate, but at the same quality. (spend the rest of the thread speculating on that ratio, unless you can divine it from one of the listening tests)

That is what I was trying to say. Both units usually run for 10-15 hours. So 1 hour is negligible. And one is flash based and the other one is HD-based.

I think it has more to do with the file size. And I correct?

But... remember the problem with the skipping playback on iPods? That has something to do with bitrate and battery life. Doesn't it?

back in the days when I had an iPod mini I conducted some tests and postet the results somewhere in this forum.

There wasn't any difference in mp3 VBR or CBR. In fact, the bitrate didn't even matter. So if you played a 32kbps CBR file or a 300kbps VBR file, the CPU clock speed was the same. The only difference was when using AAC, which used more CPU power and therefore drained the battery faster, but that wasn't the question

I have completed numerous battery tests on both my 4G 40GB iPod and newer 5G 60GB iPod. Apple rated the 4G at 12 hours while they rate the 5G at 20 hours, both for audio playback. I used randomized playlists for these tests in which all the files were at the same bitrates/settings. I tested the iTunes mpeg-4 AAC encoder (QuickTime 7) and Lame 3.87b2. I made a playlist for 128kbps VBR mpeg-4 AAC, -V 5 --vbr-new, 128kbps CBR mpeg-4 AAC, 128kbps CBR mp3, -V 4 --vbr-new, 160kbps CBR mp3, -V 2 --vbr-new, 192kbps CBR mp3/mpeg-4 AAC.
Here are the results for my 4G iPod:
128kbps CBR mpeg-4 AAC 13.5 hours
128kbps VBR mpeg-4 AAC 13.47 hours
128kbps CBR mp3 13.44 hours
-V 5 --vbr-new 13.4 hours
160kbps CBR mp3 13 hours
-V 2 --vbr-new 12.5 hours
192kbps CBR mp3/mpeg-4 AAC 12.7 hours

Both the 192kbps CBR mpeg-4 AAC and mp3 formats lasted the same time on my 4G.

The following are the results for my 5G iPod:
128kbps CBR mpeg-4 AAC 23 hours
128kbps VBR mpeg-4 AAC 23 hours
128kbps CBR mp3 22.78 hours
-V 5 --vbr-new 23.1 hours
160kbps CBR mp3 22.8 hours
-V 2 --vbr-new 21.6 hours
192kbps CBR mp3/mpeg-4 AAC 21.7 hours

So, from my tests on my two iPods, there really is not a significant difference in battery life when comparing VBR bitrates to their CBR counterparts. I received the longest battery life when using the mpeg-4 AAC format at the 128kbps CBR and VBR bitrates. As for mpeg-4 AAC needing more cpu power, I feal that this is incorrect. If anything, mpeg-4 AAC requires less cpu power on both the iPod and when running a cpu clocking program on my PC when playing back mpeg-4 AAC and mp3's. However, a 300kbps VBR mp3 will require more cpu power than a 32kbps CBR mp3 simply because of the large bitrate differences.

This is why the 4G and 3G iPods sometimes skip when playing back --alt-preset standard (-V 2 --vbr-new) mp3's. The cpu implements power sving techniques. When the bitrate of a song drastically jumps from 128kbps to 256 or 320kbps, the cpu must increase its processing power. The 3G and 4G iPods sometimes have a hard time with this increase and processing power so a slight pause is heard in the track even though it is not in the source mp3. Believe me, I have had a lot of experience with iPods and am a resident helper over at a iPod specific website and its forums.

I can't speak for other DAPs as I haven't had any epxerience with them. I can only state what I have worked with: 4G 40GB iPod, 5G 60GB iPod, and a couple Windows powered PDA's.

That's the kind of test we've been waiting for, nice job!

(I've always thought Jojo talked crap about this anyway, heh)

Very nice test - thank you very much!


Therefore, AAC VBR shouldn't be free of suttering issues on iPod. That's maybe why Apple's VBR is so lymphatic compared to other VBR encoders/format and doesn't offer sudden huge disparities in bitrate.

Great test. 5-7% difference between 128 / 192k and another reason to ditch CBR for good.

I personally haven't had any experience with using VBR mpeg-4 AAC encoders other than the tracks that I downloaded off of the iTunes music store or ripped with iTunes/QuickTime. The Nero VBR mpeg-4 AAC encoder seems to be more VBR than the iTunes VBR option. My 4G didn't have any problems with VBR mpeg-4 AAC tracks but again, I didn't try Nero's VBR mpeg-4 AAC encoder. I imagine that there could be a problem with Nero's VBR mpeg-4 AAC encoder on 4G and 3G iPods if the bitrates fluctuate as in the Lame VBR presets. Then again, mpeg-4 AAC requires less processing power (assume about 20% less when compared to mp3) to decode so this problem may not come up. I will have to try this while I still have my 4G.

The 5G iPod is completely free of these VBR mp3 skipping problems. Even the problematic tracks that I downloaded off of a past thread here were skip free. This is most likely due to Apple using a more powerful processor, better battery saving techniques, and changes in firmware.

I appreciate the thanks and glad that I could help.

Edit: Yes, I think that advancements in recent DAP's make it so that VBR encoding is as viable an option as CBR encoding especially with nominal differences in battery life. High RAM buffer capacities are making players more ideal to play back high bitrate VBR files. The 5G 60GB iPod has 64MB of buffer alone.

Edit: Spelling

To see if strong AAC bitrate variation may cause playback problems on iPod on exceptional case, I mixed two files (simple crossfading) and encode the result with Nero 3.2.0.15 "fast" mode, which is very sensitive with some specific signal (tonal or continuous moments).

The sample is downloadable >>here<<


I made an bitrate graph:




EDIT: if someone could take a look, I don't have any iPod.
EDIT2: the first part is a quiet piano passage and the second correspond to a bagpipe.

Thanks guruboolez, I will have to check that out. Unfortunately I don't have the internet at home and will have to wait until Tuesday when I get back in the office to download it. Still, it is worth trying.

Agreed. There is no significant difference between VBR and CBR. What makes the most sense is turing off the EQ and backlight. Also, it helps to have small playlists.

That's nonsensical.

it depends on the source but I guess with most modern mainstream music audioflex is right.

AAC-LC uses less processing power then MP3? I'd always heard the opposite. At very least I would expect similar requirements given the similarities of the codecs. 20% less seems unreasonable.



The 5G uses the same processor as the Mini Rev2, which incidently had the biggest problem with skipping.

Bigger then what? 128k CBR verses -V 3? Sure. APS verses 320 CBR? No way.

The statement is nonsensical since it depends on what settings are used.

There's also the fact that 128kbps CBR is lower quality than say, 130kbps VBR. So even if the bitrate was slightly higher, you're trading off a lot more than just 2kbps of size.

Are you speculating that Apple needs to significantly alter the iPod hardware and decoding software to make it more reliable for playback of files with large frame size fluctuations? And, hence the current frame size restrictions in iTunes AAC VBR mode are designed to limit possible fluctuationes from very low to very high frames, and so the files that work reliably on a limited (flawed?) decoder?

(I say this as an iPod owner perfectly very pleased by the quality of iTunes AAC VBR.)

bah, don't nitpick
"CBR files are very often of smaler size than a VBR file of the same source, aimed at the same bitrate."*
i.e. '-b 128kbps' < '-V 5'

*)

QUOTE

with most modern mainstream music

ShowsOn: significantly? all they have to do is turn off the variable clockspeed junk that doesn't work. Or find a way to fix it in the firmware.

Digga: often it's not by any significant amount

yes, and whales like plankton. so?

The iPod clock speed problem is not why the Apple's VBR variation is so restricted (I am 95% sure about it).
However, I am guessing that if the VBR variation from their encoder would become more important, then Apple would probably fix the clock speed issue on iPods.

I'm not speculating but drawing an implication from kornchild2002's explanation about MP3 suttering. If MP3 decoding issues are a consequence of sudden huge variation in bitrate, and if AAC playback uses the same amount of power than MP3, therefore AAC should have the same issues than MP3 on similar conditions.
I didn't mentionned "alteration" of the iPod or decoding software, but of limitation of their own encoder: current VBR mode of Apple (both MP3 and AAC actually) isn't very reactive. Many people have compared it to ABR for that reason.

I recall that I uploaded a file here to see if iPod(s) have issues with an AAC encoding offering a huge and sudden increase in bitrate.


Nobody is talking about the encoder's quality here.

Post 185

Ugh, the essence of difference between CBR & VBR is that if you have 2 files of the same perceived quality, VBR one will be smaller than CBR (or if they are of the same size, VBR will be of higher quality).

again, you can't say that IMHO.
if you aim at the same bitrate on a file with VBR (compared to CBR) then with most modern mainstream music VBR will have a bigger size. I'm not talking about quality here. it is out of the question that a well implented VBR method will probably beat CBR in terms of quality.
I'll put a small test together next thursday.

You can't aim at the same bitrate with VBR, unless you're familiar with the material.

I believe rutra80's statement is more valid than yours. I mean, if you aim at a certain bitrate, you should end up at that certain bitrate, otherwise you didn't aim well enough.

I thought the whole idea of VBR is to have better quality at the same (average) bitrate, compared to its CBR equivalent.

please see post 26.
I'm talking of the VBR presets in LAME where you can expect a certain bitrate range. of course it depends on the source how VBR distributes the bitrate and as a result you cannot clearly tell the size before encoding. but all I'm saying is that with most modern mainstream music VBR is more often of higher bitrate than their 'equal' CBR setting.
(i.e. '-b 128kbps' < '-V 5'). yes, it's apples and bananas.
but that's how I understood the OP.

Care to explain more?

Flamewar split to:

http://www.hydrogenaudio.org/forums/index....topic=41621&hl=

I cannot agree if someone says that -V 5 aims at 128kbps. It's meant to target a quality that would usually result in a certain range of sizes (smaller than -V4, larger than -V6), nothing more, nothing less, IMHO.

and I wholeheartly agree here. I didn't say -V 5 = CBR 128. at least I didn't try to.
my point is that supposed average bitrate of the VBR presents have their counterpart in CBR presents.
"-V5 = smaller than -V4, larger than -V6" --> and the average middle would be a CBR bitrate. now, following that line of thought, most modern mainstream music would be above that average bitrate, simply because it's harder to encode than e.g. classical music.
that's all I'm saying, simple really. probably not worth this whole discussion

(on second thought, if the average VBR bitrate results from all genres there possible are, from every timeframe (ideal case)... then this claim of mine gets really moot.)

edit2: argh. I will refrain from posting till my exams are over. it seems I can't think straight right now. sorry for the noise.

Yeah, but that would kill battery life which is a more marketable feature.

Are there problematic 'iPod killer' AAC-VBR files? Or are people just infering from the VBR MP3 issues that non-Apple AAC files could exhibit the same problems?

Do you think the AAC and MP3 decoders in the iPod are fine, and it is just a bad interaction between the power saving feature? Rather than the decoders themselves being flawed? Surely it isn't hard for a competent programmer to write a compliant decoder for such well known file types?

Perhaps the reason there is no true iTunes AAC VBR is simply an encoder quality issue. Maybe Apple's developer(s) did experiment with a full-VBR mode but realised it needed more tuning. So their stop-gap solution was to add the bitrate floor.


Yeah I know, I just wanted to disclose I'm an iPod owner. Not just a troll denigrating iPods, Apple, and iTunes without being a user.

I tried to found such sample. But it's not easy to guess what kind of brutal variation may cause a problem and even more if you don't have any iPod. That's why I created an "artificial" sample and used a VBR encoder I know to be very sensitive with some signal. It should be hard to find more sudden, brutal increase in bitrate (from ~110 kbps to more than ~300 kbps in less than 1/4 second). If iPod don't have any problem to decode this extreme case, the chance of seeing another sample causing any AAC issue related to VBR variation should be very small.

If you're interested to try, see here.

As far as I know, yes, mpeg-4 AAC LC requires less processing power to decode than mp3. However, I believe it requires a bit more power to encode into the AAC-LC format. A 20% estimate was just that, a number off the top of my head. I do know that when playing back mp3's on my computer, when compared to AAC-LC files, my CPU utilizes 35% less power (comparing 160kbps CBR files). When comparing 128kbps VBR files, by CPU also uses 35% less power to play the AAC-LC files. However, my CPU uses 10% more power when encoding to a CBR mpeg-4 AAC file when compared to Lame mp3 and requires 15% more power when encoding to a VBR mpeg-4 AAC file when compared to Lame mp3. My PC specs are as follows:
Pentium 4 2GHz 533MHz FSB (with Intel's speed reduction technology turned off)
2GB DDR2 533MHz RAM
80GB 7200 RPM HD
Running 1 program in the background (CPU clock monitoring program)


The skipping problems with the 5G iPods are FIXED. They might use the same processor (I am not aware of that, will have to look into it) but Apple did fix the problem with either a minor hardware update or firmware update. Either way, VBR mp3 files encoded with Lame aren't going to skip on a 5G iPod.

Guruboolez, I tested your VBR mpeg-4 AAC file. My 4G iPod did not skip during playback and neither did my 5G iPod. I am not sure what this means. I played the file back 15 times on my 4G iPod without any problems. I only tested it twice on my 5G iPod simply because the 5G iPods don't have problems with VBR files. I don't really know what this means though. I would like to hear from some one else with a 3G iPod or 1G/2G iPod mini.

I am thinking that Apple kinda crippled their VBR mpeg-4 AAC encoder for a couple of reasons. First off, Apple likes to use a guaranteed minimum bitrate VBR setting in which the bitrate you choose is the minimum bitrate and it can fluctuate up from there (as is the same for their VBR mp3 encoder). Secondly, I don't believe the mass market of iPod buyers really care if Apple's mpeg-4 AAC encoder has the same VBR performance as Nero's or Lame mp3. Over 14 million iPods were sold over the holiday season, it is my opinion that less than 1/8th of those actually monitor the performance of their file format encoder. For the most part; people open iTunes, put in their CD's, rip them to their computer, then copy the tracks from their computer to their iPods. Most people don't even know that the default iTunes format is to use 128kbps CBR mpeg-4 AAC. I don't think these people really care as long as it works.

So, those are my opinions and "educated" guesses.

It means:
1/ that this file isn't a problem for iPod
2/ that wide but sudden bitrate variation aren't necessary a problem with AAC
3/ that there's still a possibility of discovering AAC decoding issue on iPod but I really can't see how.
Thank you for the test kornchild2002.


It makes sense.


Isn't 128-VBR the new defaulted mode since iTunes 6?

From my experience, iTunes still selects 128kbps CBR mpeg-4 AAC as their default file format and bitrate. I believe that iTunes music store files have long been encoded at 128kbps VBR mpeg-4 AAC but Apple has yet to implement it as their default setting. For example, I downloaded a pre-release track from the iTunes music store. The track is 4 minutes and 2 seconds long. However, the track has a file size of 4.6MB. This same track, ripped through iTunes' default format, comes out to 3.9MB. The file comes out to 4.5MB if I rip it using 128kbps VBR.

I will download the latest version of iTunes and install it tonight.

VBR is still not the default in iTunes, though recent songs I've bought off the iTMS have been VBR (easy to check in QuickTime).

I also tested the AAC sample before this thread was split, and could confirm it didn't skip on the nano. When I transcoded it to LAME 3.97 -V 2 --vbr-new, that didn't skip either (dunno about the bitrate distribution there though.)

Hmm... Just for curiousity, you might want to go back and check older songs that you purchased from the iTunes music store. I have a track that I downloaded in 2004 and it too is 128kbps VBR. I don't think the iPod nanos have the skipping problem though.

Still, it is nice to know that the 5G and iPod nano won't skip with drastic flucutations in VBR encoding using the mpeg-4 AAC format.

The nano skips on LAME VBRs unfortunately. It's rare, and fairly unobtrusive (sounds a bit like when the headphone jack is slightly removed), but it does happen. Odd that files from 2004 are VBR though. They must be encoded with FAAC or something (it has happened before..)

Hi all, glad to have found this thread as it's relevant to a question I've had for a while. I've already settled on some encoder settings that fit my needs in terms of file size and quality for my iPod Photo 30GB - (Lame -V4, iTunes AAC 160 CBR/VBR). I currently have a fairly arbitrary mix of these on it now.

I've owned my iPod for almost a year now and have been particularly dissapointed with it's battery life (I'm currently getting a weak 4-5 hrs. on a full charge). As I will be soon investing my money (in a battery replacement kit) and time (ripping several CDs), I'm very much interested in finding the optimal encoder settings to maximize battery life (higher v. lower bitrate, VBR v. CBR, AAC v. MP3, etc.). For the record I've yet to encounter stutter/skip problems with VBR mp3s.

If I'm correctly understanding kornchild's test results and the rest of this discussion (apart from the VBRs-are-bigger-than-CBRs semantics/banter ), the differences between formats, bitrates, VBR/CBR in terms of battery life is more or less negligible. Should I therefore just pick something and go with it?