PDA

View Full Version : Changes to Bitrate Limiting for a player



JJZolx
2006-01-23, 20:43
When do they take effect? Immediately? Between tracks? After reconnecting to the player? After restarting the server?

kdf
2006-01-23, 21:05
JJZolx wrote:
> When do they take effect? Immediately? Between tracks? After
> reconnecting to the player? After restarting the server?
>
>
>
as each new track is opened, the command is chosen. so, if you change
bitrate, it takes effect on teh next song or you can restart the current
song and have it change then.
-k

oreillymj
2006-01-24, 01:37
I had bit-rate limiting on a player I was using to test streaming across my my broadband connection. Since the upload speed is only 265kbs, I was testing with limiting set to 192kbs.

However it seems that the commands sent to Lame were getting it to encode using VBR and the kbs being displayed in Winamp were often higher than 192.

Another strange thing is that Lame was running at all. All of my music is ripped at 192kbs CBR.

Surely LAME should only be invoked to re-encode on the fly if the bitrate limiting setting is below the bitrate the MP3 file was ripped at.

JJZolx
2006-01-24, 01:59
I had bit-rate limiting on a player I was using to test streaming across my my broadband connection. Since the upload speed is only 265kbs, I was testing with limiting set to 192kbs.

However it seems that the commands sent to Lame were getting it to encode using VBR and the kbs being displayed in Winamp were often higher than 192.
SlimServer switched from using CBR to using ABR to maximize the sound quality at a given streaming rate. ABR is a type of VBR, but with the bitrate targeted to a fairly constant average level. This should have the effect of increasing quality while still keeping the bitrate across the network link at a fixed level.


Another strange thing is that Lame was running at all. All of my music is ripped at 192kbs CBR.

Surely LAME should only be invoked to re-encode on the fly if the bitrate limiting setting is below the bitrate the MP3 file was ripped at.
Hmmm... Yeah, but I think this is the only scenario where you can get away with _not_ having to use LAME to re-encode - only when the file is encoded using CBR and when the bitrate is at an equal or lower value than the bitrate limiting. Perhaps this scenario wasn't taken into consideration in the logic, or perhaps SlimServer doesn't store whether or not the file was encoded using CBR. For a file encoded using VBR you can't really say what the bitrate is always going to be, so you pretty much have to re-encode.