Bugzilla – Bug 17953
Wrong transcoding settings to MP3 in default install
Last modified: 2014-11-07 15:17:05 UTC
Unless I'm mistaken, there is a problem with the standard settings that LMS used to transcode when streaming to a bitrate limited player. This is the string that's used, for instance, to transcode from FLAC: [lame] --silent -q $QUALITY$ $RESAMPLE$ -v $BITRATE$ Now, the quality setting is the one we set under each player settings (0 to 9, 9 being the default that uses a fast psychoacoustic model, good for high bitrates). The problem comes with the -v switch that is used. That is equivalent to use -V 4, which yelds a bitrate of about 165kbps (it varies, considering the -v settings are VBR). This makes completely worthless the $BITRATE thing, considering it translates to {BITRATE=-B %B}. So, supposing I set a player to Quality 9 (the default that the interface tells us sounds very good at high bitrates) and limit it to 320kbps... what do I get? In case of a FLAC to be transcoded I think that the normal expectation would be to expect a 320kbps MP3 to be streamed. But if I'm not mistaken, that's not the case. Because the transcoding line would read like this: lame.exe --silent -q 9 -v -B 320 This encodes a V4 variable bit rate MP3, which has an upper bitrate limit of 320kbps. But V4 is never going to hit that limit, sitting conveniently in its usual 165kbps range. So even though LMS is telling the player that it's sending it a 320kbps MP3, I really don't see how that could be the case. By explicitly stating this, LAME documentation discourages using the -B switch together with the -V switch (-v is just a placeholder for -V 4). I've discussed this here: http://forums.slimdevices.com/showthread.php?94642-Wrong-transcoding-settings-to-MP3-in-default-install I think the best way to go would be to go back to a --abr switch, in conjunction with the bitrate limit one sets through the server interface.
The only changes needed to fix this are the following two global replaces in convert.conf: BITRATE=-B %B --> BITRATE=--abr %B -v $BITRATE$ --> $BITRATE$
What exact transcoding string would you get if you set the bitrate limiting to "no limit"?
(In reply to comment #2) > What exact transcoding string would you get if you set the bitrate limiting > to "no limit"? If I understand correctly, under the default settings "no limit" means that no transcoding to MP3 is done (except perhaps for players < Squeezebox 2). Formats that play natively are streamed as-is. Formats that do not play natively are normally transcoded and streamed as FLAC. If, in the File Format Conversion settings, you disable native or FLAC streaming for a given format and force MP3 streaming, and a player is set to "no limit", you currently get just the plain "-v", which would be -V4, or VBR at level 4, but with no upper bitrate limit for individual frames. With the suggested changes, you get no encoding method specified on the command line, so you'd end up with LAME's default of CBR (constant bitrate) encoding at 128 kbps. In either case, you wouldn't get MP3 streamed at anything near the best possible quality level. But this strikes me as an unusual setup. If you wanted to force MP3 streaming at the best possible quality level, you would just set bitrate limiting to 320 kbps. In which case you'll get much better quality and approximately twice the bitrate at "--abr 320" (same as CBR 320) than with the current "-v -B 320". An alternative, which would give you the marginally better ABR 128 kbps instead of CBR at 128 in the above scenario, would be to hard-code the --abr into the rule, like -v is now. Those changes would be: BITRATE=-B %B --> BITRATE=%B -v $BITRATE$ --> --abr $BITRATE$ If you were really worried about it, you might try to pass "320" whenever "no limit" is set, but I'm guessing that might be tricky in the code.
> If, in the File Format Conversion settings, you disable native or FLAC > streaming for a given format and force MP3 streaming, and a player is set to > "no limit", you currently get just the plain "-v", which would be -V4, or > VBR at level 4, but with no upper bitrate limit for individual frames. With > the suggested changes, you get no encoding method specified on the command > line, so you'd end up with LAME's default of CBR (constant bitrate) encoding > at 128 kbps. That's what I thought would happen, and what might be the reason somebody at some point added the -v flag. I wonder if this is a left-over from mp3 only SliMP3 times...
MP3 transcoding had originally used straight CBR, then was later changed to use ABR, which should give a little better sound quality by allowing individual frames to use higher and lower bitrates, while still maintain the targeted streaming rate. I'm not sure what the developer was thinking by changing this to -v (VBR 4), but it makes no sense. If someone sets a player's bitrate limiting to 320 kbps, for example, then they'll get nothing better than VBR 4, which is approximately 160 kbps, plus or minus maybe 30 kpbs.
Ok, let's give this a try in 7.9. Commit a4c4741ca699082b27b92bedbca6c5922af28127