PDA

View Full Version : Streaming MP3 - CBR vs. VBR



JJZolx
2005-08-22, 17:42
Is there a reason that when transcoding to MP3 SlimServer only uses CBR bitrates instead of VBR?

seanadams
2005-08-22, 20:02
This is wrong. We should be using VBR with the --abr flag to specify an average bit rate. bug #2006 filed

JJZolx
2005-08-22, 20:16
This is wrong. We should be using VBR with the --abr flag to specify an average bit rate. bug #2006 filed
Yes, I guess ABR makes more sense than VBR, since the point of setting a bitrate is to specify the the network bandwidth used.

http://lame.sourceforge.net/doc/html/modes.html

seanadams
2005-08-22, 20:31
Yes, I guess ABR makes more sense than VBR, since the point of setting a bitrate is to specify the the network bandwidth used.

http://lame.sourceforge.net/doc/html/modes.html

Right - VBR is always better than CBR except in very special "legacy" circumstances. The only time I could imagine CBR being useful is if you have some fixed-rate transmission speed (eg an ISDN line or satellite link) feeding a decoder with a _very_ small buffer (ie just a couple mp3 frames). Also the earliest portable mp3 players would barf on VBR because they didn't know how to calculate the song time or something stupid like that.

note that in terms of the mp3 format, VBR is really the same as CBR. All mp3 frames have a bitrate which is one of the standard CBR rates. A VBR stream just means that the bitrate can be different from one frame to the next.

Encoding with CBR means you're wasting bits when the signal is simple, and depriving yourself of bits when the signal is complex. VBR allows variance so even for the same average bit-rate, you get a much better encoding.

JJZolx
2005-08-22, 21:18
Right - VBR is always better than CBR except in very special "legacy" circumstances. The only time I could imagine CBR being useful is if you have some fixed-rate transmission speed (eg an ISDN line or satellite link) feeding a decoder with a _very_ small buffer (ie just a couple mp3 frames).
I'm not quite sure we're talking about exactly the same thing. See:

http://lame.sourceforge.net/doc/html/modes.html

Unless you're refering to ABR when you say "VBR". :-)

I can't think of any other reason to use 'Bitrate Limiting' in the player settings other than to control the bandwidth used by the stream, as in the example you give. Both CBR and ABR would accomplish this, while VBR would not.

I stream music that is stored as FLAC, transcoded to MP3 over a VPN to my computer at work. In order to keep from eating up a significant portion of our 1.5 Mbps connection at work I limit the bitrate of the stream to 128 kbps.

The advantage to ABR is better audio quality at a fixed streaming rate. My understanding is that VBR can give even better audio quality for a particular file size, but since the target is a quality level (0 to 9) then the file size (stream rate) is unpredictable and depends on the material being encoded.

seanadams
2005-08-22, 21:21
Unless you're refering to ABR when you say "VBR". :-)


I was!

ABR mean "VBR, with this average imposed over a longish period of time."

kdf
2005-08-22, 21:25
by default, the trancoding is output at 320kbps. VRB/CBR/ABR, this is
as good as mp3 gets, so i think the original plan was to keep it cbr
(why not, since it gave more accurate progress time on the display).
Bitrate limited playback, also CBR basically because for some, that
limit might be a true limit. Using average or Variable would mean that
there would be times when this was exceeded. Of course, it could be
said that the users should account for this.

All of this can be done through the convert.conf file, so it is
relatively accessible for users to choose the best for their needs.

now that Sean has opened up bug 2006, it might be good if some
interested parties tried out a few combinations of -b $BITRATE$ and
-abr $BITRATE$ to see if there are any preferred settings that would be
good candidates for the default convert.conf
-kdf

seanadams
2005-08-22, 21:44
by default, the trancoding is output at 320kbps. VRB/CBR/ABR, this is
as good as mp3 gets, so i think the original plan was to keep it cbr
(why not, since it gave more accurate progress time on the display).
Bitrate limited playback, also CBR basically because for some, that
limit might be a true limit. Using average or Variable would mean that
there would be times when this was exceeded. Of course, it could be
said that the users should account for this.

All of this can be done through the convert.conf file, so it is
relatively accessible for users to choose the best for their needs.

now that Sean has opened up bug 2006, it might be good if some
interested parties tried out a few combinations of -b $BITRATE$ and
-abr $BITRATE$ to see if there are any preferred settings that would be
good candidates for the default convert.conf
-kdf

Agreed on these points: 320 CBR should be the same as 320 [AV]BR!

I filed a bug instead of just making the change, because maybe someone has some objection.... feeedback welcome.

BTW I didn't see a spec for lame's period over which the ABR is enforced. I would assume something small, like one second, in which case it should not impact the display of time remaining.