Subsonic Forum

The current default transcoding creates mp3 files of CBR. That produces 320kbps mp3 files when the "unlimited" bitrate option is ticked. This is noted in the ffmpeg documentation to be wasteful:

Note: Using -b:a 320k is generally considered wasteful because: -q:a 0 through -q:a 3 will normally produce transparent results.

The variable bitrate mp3 files produced using the qscale option adjust the bitrate as a function of the musical content to optimize transparancy; higher bitrates are used in complex sections of a song while a lower bitrate is used for less complex sections of songs like silence. This approach produces a transparent transode with a much smaller file size than CBR mp3 can provide (or better quality for equal size). Because subsonic is a networked player, data usage is something that should be optimized (particularly for the use case of cell phone networks).

I've tried to adjust the transcoding string myself to enable VBR transcoding, but I believe there is some bug in how Subsonic handles VBR transcoding since the output files aren't properly labeled as VBR mp3s even though I can properly transcode flac files without subsonic using the same ffmpeg string.

I would suggest the default transcoding become VBR using qscale. If the client specifies a bitrate limit (e.g. 192kbps), subsonic should transcode with the qscale option that provides approximately 192kbps avg bitrate (in this case v2).

Thank you for consideration!

I'd like built-in VBR transcoding, too. Some older versions of webkit/blink/Chrome (pre version 49) don't handle CBR very well (they don't handle the range: headers correctly) making for some obnoxious hacks on my part in SubFire to get Amazon's FireTV/tablet and older Android browsers to work. If I could get my users there to convert to VBR as a transcoding, the duration stuff is built into the format and it handles things much better.

Example of what older Chrome + CBR does? It actually never gets any duration AND it doesn't get any updates on currentTime. I have to 'hack' it by counting the seconds since the user hit play and comparing that to the duration estimate provided by Subsonic's API in the song entry in order to stop the song and move on to the next one. Hardly a perfect operation.

acroyear wrote:Example of what older Chrome + CBR does? It actually never gets any duration AND it doesn't get any updates on currentTime. I have to 'hack' it by counting the seconds since the user hit play and comparing that to the duration estimate provided by Subsonic's API in the song entry in order to stop the song and move on to the next one. Hardly a perfect operation.

The other part of this, is I think subsonic's duration estimate when transcoding to VBR is not working. It appears to assume it is CBR and picks a random bitrate not necessarily reflective of the actual bitrate. This causes playback bugs when the duration estimate doesn't agree with the actual song duration i.e. playback stops. This isn't true for VBR files that I transcode using other software and load into subsonic however, only VBR files where subsonic 'handles' the transcoding. It's possible my transode string isn't set up right, but it is very similar to the one I use to manually transcode so I don't understand what could be wrong...