hi everyone i'm a newbie of this forum, and i've been reading a lot about audio management.
i rip my CDs using iTunes + QuickTime since I have an iPod in hand. My settings are AAC @ 256kbps, but I didn't tick the VBR ripping option.
However, when I play those AAC files with foobar2000, the bitrates flucatuates.

Some people say that iTunes 256kbps doesn't mean 256kbps and actually perfomes like ABR, however I can see from foobar that the tracks I play usually goes from lower than 10kbps to as high as 400kbps. That does not look like ABR, and what's with the 400kps? Is it even possible for AAC to reach this level? or is it simply a foobar bug?

i currently live in China so there is no iTunes Store for my country, but I will be in university soon in Australia and from that time I think I will start buying from iTunes Store. So my other question is: Does iTunes Store AAC files use ACTUAL 256kbps AAC or the kind of thing you get with AAC ripped from your own CD using iTunes 256AAC setting?

This is completely normal. The iTunes AAC "CBR" setting does perform like ABR. Note that I said like and not just like. This means that the bitrate will fluctuate even when a CBR setting is chosen. Silence is encoded with a really low bitrate and iTunes AAC can go all the way up to 320kbps or higher. 400kbps is possible with AAC, the Nero AAC encoder can even use a high bitrate.

I have found that iTunes Plus files (the iTunes Store still sells some 128kbps DRMed files) actually use higher overall average bitrates than the iTunes 256kbps "CBR" setting. A 3 minute file will come out to 5.6MB when using iTunes and it will come out to 6MB when purchased from the iTunes Store. I don't know if this always holds true but I have examined every iTunes Plus track against my own 256kbps CBR rips of the same track. The iTunes Plus track always uses a higher overall average bitrate.

For AAC there is really no advantage for using CBR. Apple probably uses "256kbit/s AAC Plus" only because the concept is easier to understand and looks more uniformly. Nothing beats VBR at quality per byte. Kornchild's findings support that Apple might share this view. VBR can be better than strict 256kbit/s CBR.

Right now I'm working on an Plugin for iTunes (Mac only) to expose Quicktime True VBR encoding from within the application. I might share this later on.

thank u for u guys, that makes sense to me.
here is another question:

What if I tick the box "use VBR" in iTunes ripping setting? what's the difference?

That's "constrained" VBR. It does two things, both rather cosmetic than for better quality:

1. It applies a minimum bitrate, so setting "192kbit/s VBR" won't give you 105kbit/s files, even if it can't use the extra bytes (e. g. silence).

2. Bitrate fluctuation is limited somewhat.

Quicktime has an additional "true" VBR mode, which can use a very low complexity encoder in its highest quality setting. It will use as much bytes as make sense for the highest achievable quality, but no more. For acoustically simple tracks you can get only ~100kbit/s and for complex material over 200. Averaged over your whole collection the results will be best.

The constrained VBR setting does allow for a greater variability in the bitrate, I don't think this is cosmetic but rather helps the quality. Enabling VBR encoding in iTunes (which uses a constrained VBR setting) will, as previously pointed out, set a minimum bitrate. For example, using a bitrate of 256kbps and enabling VBR, the minimum bitrate will be set to 256kbps. iTunes can encode using a lower bitrate though as silence will still be encoded down at 10/32kbps (whichever bitrate iTunes/QuickTime AAC uses for silence). I have a 20 minute track with about 9 minutes of music and 10 minutes of silence. The file size comes out to 18.5MB when encoding using the 256kbps "VBR" setting in iTunes. Additionally, the encoder is given more lax settings for increasing the bitrate. This same track takes up 17.4MB when encoded at the 256kbps "CBR" setting in iTunes.

Granted, these settings aren't as variable as the true VBR setting but they still should provide increased audible results. I have tested the iTunes AAC encoder at 128kbps CBR and VBR. The 128kbps VBR files were harder to ABX than the CBR ones. In fact, 128kbps VBR files often had overall average bitrates at around 144kbps while the CBR ones were stuck down at about 130kbps.

You got me wrong or I wasn't as clear as needed. Of course checking VBR enables a real VBR mode in iTunes. The differences I listed were against true VBR, not against ABR/CBR.

what makes me wonder the most is that I have this totally acoustic album (Sophie Zelmani - The Ocean And Me) but it was ripped at bitrates up to 408kbps. however with a decent beat trance album (ATB - Trilogy) there is nothing as high as over 320kbps

The iTunes AAC encoder used bitrates that it deemed necessary. There really shouldn't be a reason to question why the iTunes AAC encoder decided to use a high bitrate for a song in one genre while it used a different bitrate for a song in a totally different genre. The iTunes AAC encoder thought the acoustic album needed the higher bitrate (it was more complex) than the trance album (which it thought was more simplistic).



I guess I was confused about this part of your post:


That would imply that the VBR constrained mode simply produces better "looking" files instead of increasing the sound quality when compared against the "CBR" setting (I thought you were comparing constrained VBR to CBR). I can see what you are saying in comparison with true VBR as the constrained setting gives people a predictable file size instead of drastically adjusting the bitrate for a known quality. I initially thought that you were saying that ticking the VBR option wouldn't really do anything compared to encoding with the "CBR" setting. Now I see what you were talking about. So sorry for any confusion as I didn't realize you were comparing VBR constrained to true VBR.

It is too bad that iTunes does not offer true VBR AAC encoding (ie use the true VBR QuickTime setting). That is one of my reasons for sticking with Nero AAC.