Constant Bitrate - Revision history

59.145.190.70: take out double negation

2014-07-20T08:20:30Z

take out double negation

← Older revision		Revision as of 08:20, 20 July 2014
Line 9:		Line 9:
	*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.		*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.		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 generaly take predicted, rather than actual 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.		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.

Mjb: +See also: MP3packer

2008-01-19T10:23:50Z

+See also: MP3packer

← Older revision		Revision as of 10:23, 19 January 2008
Line 21:		Line 21:
	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).		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).

			==See also==
			* [[MP3packer]], a lossless CBR-VBR converter and optimizer for MP3s

	[[Category:Technical]]		[[Category:Technical]]

Speckmade: CBR moved to Constant Bitrate

2007-06-13T16:03:01Z

CBR moved to Constant Bitrate

← Older revision	Revision as of 16:03, 13 June 2007
(No difference)

Pepoluan: remove link to frame

2006-10-11T16:58:42Z

remove link to frame

← Older revision		Revision as of 16:58, 11 October 2006
Line 1:		Line 1:
	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, ~~[[frame]]s~~ 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]].		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 [[MP3]]s. 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.		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 [[MP3]]s. 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.

Pepoluan at 08:04, 2 September 2006

2006-09-02T08:04:17Z

← Older revision		Revision as of 08:04, 2 September 2006
Line 20:		Line 20:

	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).		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).


			[[Category:Technical]]

Mjb: whoops, 'short' and 'long' frames are something else entirely

2006-07-24T06:36:28Z

whoops, 'short' and 'long' frames are something else entirely

← Older revision		Revision as of 06:36, 24 July 2006
Line 1:		Line 1:
	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, [[frame]]s 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]].		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, [[frame]]s 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 [[MP3]]s. In a CBR MP3, even though the frames are of a fixed size, the audio data is not necessarily distributed consistently between them; one frame ~~can be "short" because it doesn't~~ use ~~all of its~~ bits~~, and~~ the ~~next~~ frame ~~can be "long" because it uses the previous short~~ frame's spare bits. So 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 amount of variability 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.		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 [[MP3]]s. 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.		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.

Mjb: expanded and rewrote

2006-05-17T00:44:54Z

expanded and rewrote

← Older revision		Revision as of 00:44, 17 May 2006
Line 1:		Line 1:
	In CBR (Constant Bitrate) ~~coding~~, the [[bitrate]] ~~will be the same for~~ the ~~whole~~ file~~. It means that each part of your file will be using~~ the same number of bits ~~(if~~ [[~~bit reservoir~~]] ~~is not considered). The musical passage being a difficult one to encode or an easy one~~, ~~the encoder will use the same bitrate~~, so the ~~quality~~ of ~~your file~~ is ~~variable~~. ~~Complex parts will be of a lower quality than the easiest ones. The main advantage~~ is ~~that~~ the ~~final files size won't change and can be accurately predicted~~.		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, [[frame]]s 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]].

	~~Very often~~ CBR doesn't ~~still mean exactly constant~~ bitrate. ~~For example~~ [[~~MP3~~]] ~~uses~~ so ~~called bit reservoir~~ to ~~give small amount~~ of ~~additional~~ bits for use when ~~needed~~. ~~Still~~ CBR ~~mode~~ is ~~very close~~ to ~~constant bitrate~~.		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 [[MP3]]s. In a CBR MP3, even though the frames are of a fixed size, the audio data is not necessarily distributed consistently between them; one frame can be "short" because it doesn't use all of its bits, and the next frame can be "long" because it uses the previous short frame's spare bits. So 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 amount of variability 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).

Rjamorim at 16:19, 13 July 2005

2005-07-13T16:19:46Z

← Older revision		Revision as of 16:19, 13 July 2005
Line 1:		Line 1:
	In CBR coding, the [[bitrate]] will be the same for the whole file. It means that each part of your file will be using the same number of bits (if [[bit reservoir]] is not considered). The musical passage being a difficult one to encode or an easy one, the encoder will use the same bitrate, so the quality of your file is variable. Complex parts will be of a lower quality than the easiest ones. The main advantage is that the final files size won't change and can be accurately predicted.		In CBR (Constant Bitrate) coding, the [[bitrate]] will be the same for the whole file. It means that each part of your file will be using the same number of bits (if [[bit reservoir]] is not considered). The musical passage being a difficult one to encode or an easy one, the encoder will use the same bitrate, so the quality of your file is variable. Complex parts will be of a lower quality than the easiest ones. The main advantage is that the final files size won't change and can be accurately predicted.

	Very often CBR doesn't still mean exactly constant bitrate. For example [[MP3]] uses so called bit reservoir to give small amount of additional bits for use when needed. Still CBR mode is very close to constant bitrate.		Very often CBR doesn't still mean exactly constant bitrate. For example [[MP3]] uses so called bit reservoir to give small amount of additional bits for use when needed. Still CBR mode is very close to constant bitrate.

Rjamorim: delinkage

2005-07-02T18:56:07Z

delinkage

← Older revision		Revision as of 18:56, 2 July 2005
Line 1:		Line 1:
	In CBR coding, the [[bitrate]] will be the same for the whole file. It means that each part of your file will be using the same number of bits (if [[bit reservoir]] is not considered). The musical passage being a difficult one to encode or an easy one, the encoder will use the same [[bitrate]], so the quality of your file is variable. Complex parts will be of a lower quality than the easiest ones. The main advantage is that the final files size won't change and can be accurately predicted.		In CBR coding, the [[bitrate]] will be the same for the whole file. It means that each part of your file will be using the same number of bits (if [[bit reservoir]] is not considered). The musical passage being a difficult one to encode or an easy one, the encoder will use the same bitrate, so the quality of your file is variable. Complex parts will be of a lower quality than the easiest ones. The main advantage is that the final files size won't change and can be accurately predicted.

	Very often CBR doesn't still mean exactly constant [[bitrate]]. For example [[MP3]] uses so called [[bit reservoir]] to give small amount of additional bits for use when needed. Still CBR mode is very close to constant bitrate.		Very often CBR doesn't still mean exactly constant bitrate. For example [[MP3]] uses so called bit reservoir to give small amount of additional bits for use when needed. Still CBR mode is very close to constant bitrate.

Jan at 11:45, 22 March 2005

2005-03-22T11:45:10Z

New page

In CBR coding, the [[bitrate]] will be the same for the whole file. It means that each part of your file will be using the same number of bits (if [[bit reservoir]] is not considered). The musical passage being a difficult one to encode or an easy one, the encoder will use the same [[bitrate]], so the quality of your file is variable. Complex parts will be of a lower quality than the easiest ones. The main advantage is that the final files size won't change and can be accurately predicted.

Very often CBR doesn't still mean exactly constant [[bitrate]]. For example [[MP3]] uses so called [[bit reservoir]] to give small amount of additional bits for use when needed. Still CBR mode is very close to constant bitrate.