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 55462 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

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

Reply #25
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.
lame3995o -Q1.7 --lowpass 17

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

Reply #26
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.

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

Reply #27
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.

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

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

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

Reply #28
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'.