Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: I hear a lot about CBR and VBR; what’s wrong with ABR? (Read 55237 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

I hear a lot about CBR and VBR; what’s wrong with ABR?

I have read numerous forums and articles about mp3 cbr and vbr, some swear by cbr others vbr, the debate just goes on and on. I,ve tried cbr 256, vbr 256, cbr 320, cbr 192 cbr etc and I cant hear any difference. My question is why bother with cbr or vbr, why dont people just go with MP3 ABR, would this not be the ideal compromise, or I am missing something, as there does seem to be lack of mp3 abr on offer as downloads from the likes of Napster etc.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #1
You might think of abr as being the worst of both worlds. It is not able to vary its bitrate as much as vbr to adjust to the needs of the material, but it also is not exactly constant bitrate when the limitations of data transmission require it. It is also harder to seek within a file than with cbr, and some players don't do a good job of displaying the actual bitrate of a file in either abr or cbr.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #2
I don't think there has been a public test of ABR vs VBR mp3. VBR has generally considered to be superior.

The latest AAC test did test constrained vs true VBR. They were tied statistically.

I hope the next mp3 public test would check ABR vs VBR.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #3
ABR is for the case where you want to optimize for quality but have somewhat flexible bandwidth constraints. VBR is intended to provide constant quality. CBR is intended to provide constant bitrate. ABR is intended to keep close to some bitrate but squeeze as much quality as you can from that bitrate. You could look at it, as pdq says, as the worst of both worlds, but you could also look at it as the best of both worlds. You keep a nominal bitrate, like with CBR, but you maximize quality by allowing variations in the bitrate, like VBR.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #4
Also ABR / CBR is inferior to VBR in terms of pre-echo control. V5 can outdo ABR 170k in impulse handling. When using higher bitrate  - 224 ~ 320k CBR / ABR converges so yes below that you could be getting the worst of everything. At high bitrate there might be an advantage: predictable size, max hardware compatibility, theoretical safety from aggressive VBR  compression when psymodel is failing.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #5
Also ABR / CBR is inferior to VBR in terms of pre-echo control.
Sure, but don't sell ABR short here, it's designed to outperform CBR.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #6
I have read numerous forums and articles about mp3 cbr and vbr, some swear by cbr others vbr, the debate just goes on and on.

I'd be very, very sceptical when people "swear" by something. Either you have reasons for using certain encoder settings under certain conditions - then you should be able to explain those reasons in accordance with the technical specifications of the encoder - or you just have an unfounded and irrational belief that some settings subjectively sound better to you - then all you can do is to "swear" by them.

Just think about what the concept of variable/constant bitrate means in terms of quality:

VBR - variable bitrate, constant quality
CBR - constant bitrate, variable quality

If you have a file encoded at an average of 160kbps, it is very likely that the VBR file will sound better than the CBR file. So unless you want to use MP3 at its limit where both modes converge (320kbps), VBR is always preferable for quality. CBR mode only makes sense for those scenarios where you absolutely need a constant bitrate. Even for streaming applications, there's often a small deviation in bitrate allowed over a period of time, so the ABR mode was developed as a compromise between the two (average variating bitrate, more constant quality than CBR).

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #7
Also ABR / CBR is inferior to VBR in terms of pre-echo control.
Sure, but don't sell ABR short here, it's designed to outperform CBR.


Yes but CBR is underrated and doesn't fully 'starve' since lame uses a bit reservoir . Its just a little dumb that it encodes digital silence. Also ABR is really VBR without letting psymodel full control over bitrate so if some crazy player doesn't like VBR then its very possible that it doesn't like ABR.  ABR might be the worse of everything in such case. I think it might have a niche at high bitrate 230 ~ 300 k or when going lower than 120 k.. likewise CBR  192 ~ 256 k  is a good option for high quality / good size +  100% compatibility for every software and device ever made.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #8
CBR  192 ~ 256 k  is a good option for high quality / good size +  100% compatibility for every software and device ever made.

Why would you need such compatibility overkill? Probably all recent MP3 players support VBR - why would you need compatibility for dinosaur devices you'll never use again anyway? I have several old MP3 players in my drawer, never used again since I got more recent and better ones. However, even the iRiver players more than 10 years old had full support of VBR already.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #9
If abr were implemented as a smart, i.e. multipass, vbr then it would be much more desirable. It would produce the best possible encoding at the target bitrate.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #10
In the roughly 120-240 kbps bitrate range, probably VBR is the best way to go, as far as no serious VBR weakness of the encoder used is known and no special considerations (like streaming) have to be taken into account. Not having serious weaknesses as does Lame 3.98.4 IMO means the psy model is quite alright, and you get an efficiently encoded mp3 file. This applies to Lame 3.98.4 -V5 to -V0.

When going higher in bitrate you don't have a choice for VBR as long as you go with standard Lame, and the only CBR choices are 256 and 320 kbps here. It's a pretty large gap between the two choices. 256 kbps isn't very attractive because it can hardly be expected to give a seriously better quality than -V0. For ABR this huge gap doesn't exist, and you can go with any average bitrate according to your likings.

ABR shouldn't be seen too much IMO in the face of 'roughly predictable bitrate', because nobody really needs this. Either you need a constant bitrate like for streaming, or you can use a variable bitrate as nearly anybody does, and in this case you can use a full-fledged VBR mechanism.

ABR has its merits in the 256-320 range because of the large CBR gap mentioned. ABR (like CBR) is useful also if you have reason not to totally trust in the VBR audio creation process which totally relies on the psy model.
The audio data creation process of CBR and ABR is basically the same, with a higher amount of audio data rate variability on the ABR side, and letting the user gaplessly choose his bitrate demands.
lame3995o -Q1.7 --lowpass 17

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #11
The main strength I've seen of ABR is the predictable file sizes while retaining somewhat better quality than CBR.  For example, if I want to burn a data CD full of MP3s for my car, I can fairly easily calculate the bitrate to make the music I've selected fit onto one CD.  I can either do multiple encodings with various -V settings until I find one that comes in under the size limit, or I can just use ABR and get it right the first time.

As pdq mentioned, a multi-pass mode would certainly make MP3 ABR a better proposition.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #12
--abr 140 is also good when you want to save space on portables but need predictable size and better than 128k quality.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #13
Its just a little dumb that it encodes digital silence.

There's no getting around that in MP3, but unless you use the -F option, LAME will actually use low-bitrate frames for digital silence, even in CBR mode.
Quote
Also ABR is really VBR without letting psymodel full control over bitrate

The documentation says that ABR is more like CBR in that actual quantization noise is not taken into account; rather, a prediction of the space needed for a frame is made by some other means. So I would look at ABR as more like "CBR with less restrictions on bitrate" rather than "VBR with more". Unless I'm not understanding something.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #14
There's no getting around that in MP3, but unless you use the -F option, LAME will actually use low-bitrate frames for digital silence, even in CBR mode.

Are you sure about that?

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #15
--abr 140 is also good when you want to save space on portables but need predictable size and better than 128k quality.
-V 5 is wonderful for portable use.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #16
--abr 140 is also good when you want to save space on portables but need predictable size and better than 128k quality.
-V 5 is wonderful for portable use.



Yes that is the best way to go.  The ABR 140 is handy when you need exact filesize or when using an older or very fast mp3 encoder (gogo, FHG). I think the current FHG allows something like CBR 140k.


I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #18
The documentation says that ABR is more like CBR in that actual quantization noise is not taken into account; rather, a prediction of the space needed for a frame is made by some other means. So I would look at ABR as more like "CBR with less restrictions on bitrate" rather than "VBR with more". Unless I'm not understanding something.

That's how I understood it too. LAME's ABR mode is very similar to Vorbis' ABR - it works more like an "extended bit reservoir" than a real VBR mode. This makes sense for internet streaming applications, where you usually have enough buffer size to afford this kind of ABR. Many radio streams are in fact (Vorbis) ABR.

I don't think there's any need for a two-pass VBR/ABR mode as proposed here. Why would you need that? To fit an album exactly into the remaining 50361KB on your portable?

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #19
Hope I don't get jumped on for reviving this thread, but the discussion is relevant to a question I had.

How well suited do you think ABR is for online streaming (in lieu of using plain CBR), such as for a radio station's 64, 128, 256 kbps feeds? My thinking is:

- ABR provides potentially higher sound quality at a given bitrate than CBR.

- If there's buffering on the client end (which I would expect in nearly all cases), then the variations in bitrate per frame will be absorbed. Anyone with a marginal connection would have nearly as much of a problem with underruns with CBR as with ABR.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #20
That sounds reasonable, if you're streaming the content directly, without transcoding. Is that what you're doing, though? I use SHOUTcast; it transcodes.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #21
Actually, it is being transcoded from FLAC. Why would that make any difference?

Where I've used this in practice before is in streaming my FLAC library from my home, transcoded to MP3, to my office. At the time, my home internet connection's upstream was only about 512 kbps and I found that because traffic fluctuated quite a bit I was only able to stream reliably at about 192 kbps. Using ABR worked just as reliably as CBR.

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #22
Transcoding from FLAC or any other lossless is fine. By 'transcoding' on these forums, we usually take that as shorthand to mean lossy-to-lossy, which is potentially bad for sound quality. We more often tend to use 'encoding' for encoding lossy from a lossless source, whether compressed (e.g. FLAC) or not (e.g. WAV PCM or AIFF).
Dynamic – the artist formerly known as DickD

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #23
... How well suited do you think ABR is for online streaming (in lieu of using plain CBR), such as for a radio station's 64, 128, 256 kbps feeds? My thinking is:

- ABR provides potentially higher sound quality at a given bitrate than CBR.

- If there's buffering on the client end (which I would expect in nearly all cases), then the variations in bitrate per frame will be absorbed. Anyone with a marginal connection would have nearly as much of a problem with underruns with CBR as with ABR.

An alternative with frame bitrates which are even better controlled is to use -Vx -b n -B N -F, for instance -V5 -b128 -B160 -F for the 128 kbps quality (definitely only 128 and 160 kbps frames), or -V0 -b 256 -B 256 -F for the 256 kbps quality (only 256 kbps frames).
lame3995o -Q1.7 --lowpass 17

I hear a lot about CBR and VBR; what’s wrong with ABR?

Reply #24
An alternative with frame bitrates which are even better controlled is to use -Vx -b n -B N -F, for instance -V5 -b128 -B160 -F for the 128 kbps quality (definitely only 128 and 160 kbps frames), or -V0 -b 256 -B 256 -F for the 256 kbps quality (only 256 kbps frames).


But is there any good reason to limit the minimum bitrate of frames? If the goal is to keep overall bitrate below a certain level, I would think it only increases the overall bitrate unnecessarily. A frame that might be encoded at 32 kbps, for instance, would be forced to 128 kbps (in the first example). We wouldn't be trying to keep the stream at a 'near constant' rate, just trying to cap it.