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.
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 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.
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.
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.
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 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).
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.
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.
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.
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.
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.
--abr 140 is also good when you want to save space on portables but need predictable size and better than 128k quality.
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.
Also ABR is really VBR without letting psymodel full control over bitrate
The documentation (http://lame.sourceforge.net/abr.php) 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.
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?
--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.
--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.
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?
Whoops, no, I take it back. *embarrassed*
It's only in VBR mode that it does that.
I even helped document that feature. :/
The documentation (http://lame.sourceforge.net/abr.php) 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?
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.
That sounds reasonable, if you're streaming the content directly, without transcoding. Is that what you're doing, though? I use SHOUTcast; it transcodes.
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.
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).
... 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).
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.
Probably you're right, and streaming works well without the -F switch. For silence or near-silence, this would be favorable. Using -F and a -b setting close to the desired average bitrate has the welcome tendency of keeping bit reservoir larger however, which partially makes up for the restrictions of the -B switch in terms of quality.
streaming my FLAC library from my home, transcoded to MP3, to my office.
What I meant was, depending on how this streaming is being accomplished, ABR might not make a difference.
The streaming software or gear that you're using is either
- taking the files "raw" and pumping them through the network—that is, if one file is 320 kbps CBR and the next is ~160 kbps VBR, that's exactly what's going out over the network, so on the receiving end you see the bitrate changing; or
- transcoding the files as it reads them—that is, no matter what format they are on disk, they get decoded and re-encoded with consistent parameters (that you configured in the streaming software) so what goes out over the network doesn't fluctuate.
If it's #2, then it doesn't matter whether you are making the files be ABR or CBR on disk before they're streamed.
What I meant was, depending on how this streaming is being accomplished, ABR might not make a difference.
The streaming software or gear that you're using is either
1. taking the files "raw" and pumping them through the network—that is, if one file is 320 kbps CBR and the next is ~160 kbps VBR, that's exactly what's going out over the network, so on the receiving end you see the bitrate changing
I didn't propose a scenario where we're streaming from files stored at random MP3 bitrates/encodings and trying to rate-limit it, but I suppose I also didn't specifically say we're not. Assume that the source is always lossless.
Take the case of a radio station that offers feeds in 96 kbps, 128 kbps and 256 kbps. To feed 'raw' files, as you say, they would rip and store their CDs as lossless files (perhaps FLAC) and then transcode to MP3 using the chosen encoding method, keeping files at each of the desired bitrates.
2. transcoding the files as it reads them—that is, no matter what format they are on disk, they get decoded and re-encoded with consistent parameters (that you configured in the streaming software) so what goes out over the network doesn't fluctuate.
Or do that, if there are sufficient computing resources. I see no difference at the client end. In either case you have complete control over the type of encoding, parameters, etc.
If it's #2, then it doesn't matter whether you are making the files be ABR or CBR on disk before they're streamed.
I'm still not quite following what you mean, unless you're thinking that the stream might be transcoded from MP3 files of some type.
The popular streaming toolkits tend to be designed to transcode, not serve files 'raw'. By 'raw' I mean the streaming software does nothing to the audio data; it just takes the file and streams it, which may involve breaking it into chunks for the streaming protocol, but doesn't involve transcoding. However there are some that do serve files raw.
AFAIK, and maybe I'm wrong, but the streaming solutions that do transcode don't offer LAME's ABR mode as an option for that transcoding. So I was assuming, perhaps incorrectly, that you were talking about using something like SHOUTcast to stream ABR-encoded files, and that you weren't aware that those files were going to be transcoded to CBR as they're fed to the network. In other words, if you're first encoding to ABR/CBR, then transcoding that to something else in the broadcasting software, then obviously what you did in the original files doesn't matter; all that matters is what's going out over the wire.
If, however, your streaming software is indeed where you're making the choice to use ABR, then you would expect the choice to matter. Same if you are creating ABR files that are streamed 'raw'.