6.01b, player durations incorrect on transcoded files

[carnifex]

subsonic 6.01b, as a war on tomcat 8.5 with jdk8_74 on unraid 6, running in a docker container (using the default tomcat8 image so debian jessie), listening through web interface so the standard html5 player
transcoding done with avconv, avconv -i %s -b %bk -q 0 -loglevel error -f mp3 -

the duration in the playlist is correct, eg 4:39. when played, it's saying 5:22
[4/7/16 11:23:14 AM UTC] DEBUG StreamController GET /subsonic/stream?player=5&id=81220&auth=xxxxx, Range: bytes=0-
[4/7/16 11:23:14 AM UTC] INFO StreamController Content-Length: 11160000
[4/7/16 11:23:14 AM UTC] INFO StreamController Content-Range: 0-11159999/11160000

this causes skips and pauses from about 50% through the actual duration of the song, then a complete pause at 75-80% or so. skipping to the next song works fine
haven't experienced this before today, happens with any flac that's transcoded. doesn't happen with playing mp3s natively

looks like a bug in the player as mobile listening through dsub is totally fine

[acroyear]

As I've noted before (from my year of experience with SubFire), the HTML5 Audio tag can be inconsistent on how it determines duration. With a stream feed, technically it doesn't have it. It has to guess. The presumption of the feed is that you're playing 'radio', in which case it doesn't ever actually end.

Some browsers don't bother at all: they just set it to NaN or Infinity, don't fire "ended" events, and good luck to you (Chrome on Android from v 40 to v 50). Others will at least try to look at the Content-Length/Range header. If it is a variable-bitrate mp3, there's more metadata in the format and the audio tag can make an internal determination of the duration and work with it that way.

However, that Content-Length header itself is a guess. It is bytes, not seconds or time. As such, the audio tag still needs to guess what its actual duration is, based on the bitrate headers it received in the mp3 itself and that Content-Length header.

Now throw in that the transcoder itself does not *really* know how long the file is. It just streams bits in and streams them out. So here, the server is also having to guess what the mp3 file size would be based on the original flac size.

Law of averages (and experience) means these numbers are usually right 95-99% of the time. In your case, the flac->mp3 "guess" is what is wrong, perhaps due to a significant amount of silence in the track?

Mobile apps that are based on downloads (incl any based on the official Android app) also 'guess', but the guess algorithms are based on the library available. It isn't necessarily relying on any of the headers to make that determination: it just works with the file content it has received.

The duration in the playlist comes from analyzing the file at scan time, when the ID3 is loaded. In the case of FLAC, the exact duration can be determined because uncompressed it is lossless: uncompressed, all 5 minute FLAC files are exactly the same size no matter what their content is, and FLAC's compression (same as the 'zip' algorithm, more or less) is generally right at 50%, maybe a little better.

mp3 duration is not in any way an exact science. They never made the format that way in the first place, because it wasn't really supposed to be a file format on its own, but a layer spec for the audio, matched with the video spec in the mp4, then wrapped in a full container layer (the m4v) that actually had the real duration numbers in it for players to rely on.

Annoyingly, ogg didn't really improve on this design flaw.
Yeah, it is something of a fundamental flaw with the mp3 file signature.

[carnifex]

there probably is some solution, and its something that subsonic will almost certainly want to fix before 6 is out of beta, since it basically renders flac files unlistenable

but there is a workaround thats quite nice and seems to work fine

Code: Select all

apt-get install -y flac lame && ln -s /usr/bin/flac /var/subsonic/transcode/flac && ln -s /usr/bin/lame /var/subsonic/transcode/lame

then have 2 step transcoding,

Code: Select all

flac --silent --decode --stdout %s
lame --silent -h -b %b -

found here https://github.com/tsquillario/Jamstash ... t-45254726


edit: no, it doesn't work fine. the durations are correct and the songs can finish (so better than single step), but there's still very often a pause half way through playing flacs, presumably for the same reason. back to 5.3 for now then