Constant Bitrate

In CBR (Constant Bitrate) encoding, the bitrate is kept constant across the entire file: the same number of bits is allocated to encode each second of audio, and internally, frames of audio data occur at regular, predictable intervals, so the overall file size for a given duration of audio is predictable. CBR is therefore the "opposite" of VBR.

That said, in some formats there may be some variability in the number of bits that contain actual audio information from frame to frame. This concept manifests in the bit reservoir of MP3s. In a CBR MP3, even though the frames are of a fixed size, the audio data is not necessarily distributed consistently between them; audio for one frame might use fewer bits than the frame has, so that frame 'adds' the spare bits to a 'reservoir' that can supplement the bits allocated to the next frame. Thus, the effective bitrate is allowed to vary somewhat in a CBR MP3, even though there is a fixed number of frames for the duration of audio. The bitrate of a single frame can be up to 320 kbps, but the frame that immediately follows that one would have to use fewer bits, whereas in VBR, there would be no such restriction. Consequently, the amount of variability across the entire MP3 is not as great as that afforded by VBR, but it is not insignificant; a CBR encoder that does not efficiently use the reservoir will likely produce a lower quality file than one that does.

Unlike in VBR, the perceived quality of decoded audio will tend vary across a CBR file. This is because CBR encoding is similar to the ABR form of VBR encoding in that it is normally based only on a target bitrate and analysis of the input audio; there's usually no attempt to use the absolute lowest possible bitrate at which a particular output quality level would be maintained. Technically, CBR implementations always do incorporate a prediction of output quality, but it is based on fixed algorithms rather than trial-and-error testing of actual results as is done in VBR.

Who should use CBR

• CBR is useful for people who are concerned about maintaining maximum compatibility, especially with certain streaming applications and some hardware-based decoders that don't reliably support VBR.
• CBR is also useful for people who desire the ability to obtain accurate estimates of the bitrate or approximate duration of a file's decoded audio without scanning and partially decoding the entire file.

Advocates of VBR, especially on the hydrogenaudio forums, are often very vocally anti-CBR, and often say that no one should ever use CBR, when given the choice. Some reasonably argue that the point of using a compression algorithm, especially in a lossy codec like MP3, is to conserve as many bits as possible while maintaining a certain quality level, so CBR's tendency to use more bits than is necessary in simple passages and to use too few for complex passages is wasteful and bound to produce worse results (in the complex passages, at least) than VBR. The fact that CBR implementations rarely take actual, rather than predicted, output quality into account is pointed to as another reason to avoid CBR.

However, these arguments need to be carefully qualified in order to be meaningful, and it would be incorrect to infer that there are inherent quality differences between CBR and VBR.

In general, however, for most types of input, assuming identical input, identical encoding methods, and sensible targets for VBR quality and bitrate bounds, VBR will almost always produce equal or better perceived-quality results than CBR for files of the same size or average bitrate, and this has been demonstrated in numerous double-blind listening tests. For example, using the same encoder, a 128 kbps CBR MP3 will almost never sound better than a VBR MP3 that averages 128 kbps, because in VBR, the simple parts of audio can be better compressed than in CBR, thereby allowing more bits to be available for the complex parts. On the other hand, since the simpler parts of the file sound better in the CBR version and the complex parts will sound be better in the VBR version, comparing even similar-bitrate files can be a very subjective experience.

CBR can exceed the quality of VBR if the comparison is not constrained to an average bitrate, or if the VBR encoding method does not take into account actual output quality. For example, a 256 kbps CBR MP3 containing moderately complex audio is likely to sound noticeably better, overall, than a similarly-encoded VBR one that averages 128 kbps, even though the VBR one may use up to 320 kbps in some frames. And even when VBR does measure output quality, there is a margin of error, especially when relying on perceptual psychoacoustic models, so the encoder (even the much-revered LAME) can accidentally overcompress some segments, depending on the characteristics of the audio, the quality and bitrate constraints imposed, and the capabilities of the particular encoder. At high bitrates, the quality difference between typical CBR and VBR files approaches zero, so, for some users, CBR is perfectly acceptable, especially if maximum conservation of space is not a concern.

At low average bitrates, the quality difference between CBR and VBR is more pronounced, given the same input, so VBR is often more desirable for applications that need a great deal of compression.

If input need not be the same, then VBR also makes it possible to keep the same approximate quality level as CBR but increase the frequency range of the input, which is often considered an increase in perceived quality even though there may be just as much quantization noise. For example, a ~96 kbps VBR file could use a 12.5 kHz lowpass filter on the input and have about the same percentage of noise as a 96 kbps CBR file with an 11.5 kHz filter. Depending on the listener's sensitivity to noise in the additional upper 1 kHz, a higher overall quality level would likely be perceived due to the mere presence of those upper frequencies (assuming they contain audio that the listener wants to hear).