Which bit rate to use when importing MP3 to iTunes using VBR?

On my version of iTunes (7.5) it says, "With VBR enabled, bit rate settings are used for a guaranteed minimum bit rate." This is reminiscent of iTunes' predecessor Soundjam. VBR is what it says, varying bitrate. There could be times where (for some reason - I don't know, maybe some players don't like super low bitrates, or maybe you get artifacts) you don't want the bitrate to drop below a certain value no matter what, but do want the option for it to go higher for a more complex interval of music, so you want to use VBR. Some encoders just give you variable with no base setting option.

Just to be clear, no mp3 setting preserves "full quality". Part of the mp3 encoding is throwing out things it doesn't think you will notice if they are missing. If you want full quality but minimum space then choose Apple Lossless (or encode with FLAC if you use a non-Apple player).

There aren't any hard rules when it comes to lossy encoding. Choose settings, then listen to it and see if it sounds okay to you..

dacdk wrote:

Could there be any reason NOT to choose the lowest bit rate (VBR) setting (i.e. 16kbps) when importing MP3 files into iTunes using variable bit rate (VBR)?? I assume that if I at the same time choose 'highest quality', then the full quality will always be preserved?

16 kbps is barely adequate for spoken word, and will sound extremely raggedy for music.

As Limnos says, you can experiment and see what you like. Or, just use the setting most people use nowadays, which is 256 kbps.

The thing to keep straight is what happens with variable (and the number reported in variable is an average of all the rates actually used) versus constant bitrate (which is a rate of encoding from start to finish regardless of the complexity of a piece).

If it is indeed a minimum rate as part of a general varying bitrate coding then it seems that with choosing "highest quality" probably none of the track would end up actually being encoded at 16k. You're leaving it up to iTunes to decide, with your bitrate setting just being the lowest quality you would want to risk. In reality probably nothing would be encoded at that bitrate even if you left it set, unless you have some pure frequency hum as large sections of the track.

Conversely, it would not make sense to select low quality, then force iTunes to encode at a minimum of 256k. I haven't experimented so I can't provide a guideline as to which quality encodes at which rates but probably low quality would encode at something much lower than 256, so forcing it to do that wouldn't have the desired space saving of choosing a lower quality since you'd be forcing it to always use 256k.

The main disadvantage of setting too high a minimum is it will essentially force a constant bitrate of your minimum in sections that are below the minimum. Let's say you set minimum at 256k and had two 30s really complex pieces of music with 2 minutes of silence in between. The music gets encoded at an average rate of, say 278k. However, you'd be forcing iTunes to encode the silence at 256k, whereas 16k could probably quite adequately handle it, and end up with a larger file than necessary.

If it were me I'd either experiment with some settings (report back here if you do!), or maybe set minimum at 128k (since that is "fm radio quality") that isn't too unreasonable a size penalty if it briefly is higher than necessary for a short section.

Limnos,

When you choose MP3 with VBR, iTunes lets you select a "Quality," which has possible values from "Lowest" to "Highest." It is really just a technical paramter that controls how much the VBR is allowed to vary. Unfortunately, people confuse it with the overall measure of audio quality, and they conclude (as did the OP) that it has something to do with "the full quality will always be preserved," which is not at all correct.

As you correctly advised, one can experiment with different bitrates and see what sounds good. But the common choice nowadays, used for retail tracks at both the iTunes Store and Amazon MP3, is 256.

When you choose MP3 with VBR, iTunes lets you select a "Quality," which has possible values from "Lowest" to "Highest." It is really just a technical paramter that controls how much the VBR is allowed to vary.

I'm still trying to research all this. It appears the LAME encoder (which it also seems iTunes does not use) has quality settings, but these affect which encoding process is used, not bitrate per se. The highest quality one uses a slower model and fancier techniques. On the other hand, IPod & ITunes For Dummies By Tony Bove (as referenced in Google books) says things like if you choose highest quality from VBR iTunes will encode up to 320k which implies quality setting does influence bitrate to some extent.

I guess one salient thing is a comment I read that because iTunes is proprietary we don't really know what is going on behind the scenes, just what the result is. For that reason some prefer using the LAME encoder since it's pretty open as to what is happening. I use XLD (which incorporates LAME) myself.

In a discussion from 2005 people were commenting that iTunes VBR doesn't handle that well at low bitrates, and they would only use it with 192k at least.

Limnos,

The "Quality" setting does have some effect on bitrate. I just encoded the same piece at MP3 192 VBR leaving all settings the same except "Quality," and the bitrate came out as follows:

Using "Quality = Lowest": 200 kbps

Using "Quality = Medium": 207 kbps

Using "Quality = Highest": 231 kbps

This undoubtedly reflects the phenomenon you described earlier, where the VBR encoding uses more bits for the passages with greater audio complexity, and its interpretation of "more" depends on the so-called Quality setting..

Needless to add, using "Quality = Highest" does not assure that "full quality will always be preserved." To preserve full quality, you need a lossless encoder.

You are right about LAME and iTunes. All of the MP3s that I buy commercially from Amazon MP3, Eclassical.com, etc, use LAME encoding. iTunes plays them fine, but uses something else for its own encoding.