Opus playback ends prematurely when transcoding

[domcote]

Folks,

I have a bunch of opus files that stop playing before they actually end. It seems to be reasonably "graceful" - at least none of the UI throw an error and everything stops in the "stopped" state.

My setup:
LMS 8.3 release on Windows 10 (fully patched of course)
Tracks were converted using Foobar 1.6.11 and opusenc 1.3
3 Booms attached

Squeezelite (while transcoding) exhibits the exact same behavior btw. Works as expected when playing natively.

Here is a track in question: https://1drv.ms/u/s!AoQI5_3ipPc6pY1TCCifcMvIkkgg4A?e=wtgGtR

I have a feeling this may be related to #792.
Tracks seem to end prematurely by about the same amount of time they gain by playing too fast - although I couldn't verify this precisely yet.

[mherger]

Could you please try again with the latest 8.3.1 nightly build? There has been an Opus related update.

https://downloads.slimdevices.com/nightly/?ver=8.3

[domcote]

Folks, my bad. I forgot to update this bug after posting here: #792

I installed 8.3.1 - 1672817815 @ Wed Jan 4 as you suggested, but playback still stops prematurely.
Just verified that this occurs both on my Booms and Squeezelite-X.

Here is another opus to test with: https://1drv.ms/u/s!AoQI5_3ipPc6paxmkj2fO1gSZIoQsQ?e=W1wDWz

Track is 6:13 long, but playback ends much earlier than that.

What else can we/I do?

[michaelherger]

@mw9 didn't see this issue over in #792. So I'm wondering whether this was a Windows problem...

[domcote]

Possible. And yet, all other players I tested play opus as expected, windows media player included.
So it must be something with the windows build?

[mw9]

sox alone is used both in the flac and pcm rules. Did you find anything in the LMS log which might throw light ?

Otherwise we might need to devise a test to rule in/out the Windows build of sox, or perhaps a Windows pipeline solely comprising sox.

[domcote]

sox alone is used both in the flac and pcm rules. Did you find anything in the LMS log which might throw light ?

Otherwise we might need to devise a test to rule in/out the Windows build of sox, or perhaps a Windows pipeline solely comprising sox.

If sox on Windows were the problem, shouldn't we be seeing the same issue when Windows folks transcode other formats as well?

I'd be happy to grab some logs. Due to their slightly overwhelming nature... which settings should I use to capture which logs exactly?

[domcote]

I played around with transcoding 48kHz some more, this time with Vorbis --> PCM, to ascertain whether premature ending is a general problem or limited to Opus.

I applied the same fix as I did for Opus, because playback of 48kHz Vorbis is, by default, also too fast when transcoded to PCM. (see #792)

ogg pcm * *
        # IFT:{START=trim %s}
        [sox] -q -t ogg $FILE$ -t raw -c 2 -2 -s  - $START$

This successfully corrects the playback speed so that 48kHz Vorbis plays back correctly.

Here is the kicker: I can't repro the premature end with Vorbis source files. 🤔
Right now, it looks like it's somehow specific to opus.

Does that help in any way?

PS. LMS tells me it is converting to 1411kbps PCM, which is 44.1kHz, not 48kHz afaik. Any way I can get LMS to stream 48kHz Vorbis as 48kHz PCM?

[mw9]

PS. LMS tells me it is converting to 1411kbps PCM, which is 44.1kHz, not 48kHz afaik. Any way I can get LMS to stream 48kHz Vorbis as 48kHz PCM?

How do you know that your Vorbis file actually is 48kHz ?

[domcote]

PS. LMS tells me it is converting to 1411kbps PCM, which is 44.1kHz, not 48kHz afaik. Any way I can get LMS to stream 48kHz Vorbis as 48kHz PCM?

How do you know that your Vorbis file actually is 48kHz ?

Because I bought it as 48kHz FLAC, LMS says it is 48KHz and so does Foobar2000.

But irrelevant and back to the topic at hand - I got excited too quickly. Some 44.1kHz Vorbis files will end prematurely when transcoded to PCM using above rule.

Here's the thing: Opus files can end dozens of seconds too early (they are always 48kHz), Vorbis files (at 44.1 kHz) will end a few seconds early.

An example: https://1drv.ms/u/s!AoQI5_3ipPc6pbFpdec5EBu6149x0g?e=BR17on
It ends, clearly audible, about 3-4 seconds too early - every time.

So given that both opus and vorbis show the same issue, but to a different extent - I'd guess something is wrong with one of the many layers involved in playback guesstimating the actual length of a VBR track.

Or why else would different natively VBR formats cause varying premature playback endings?

Folks, I realize I might be a fringe case, as I could be one of the few folks using lossy HQ VBR codecs that are not MP3 - trying to transcode. (reasons for that are beyond the scope of this bug).
So I'm happy to support tracing this in any way I can, but I'll need clear guidance, as I'm not a dev.

[mw9]

But irrelevant and back to the topic at hand - I got excited too quickly. Some 44.1kHz Vorbis files will end prematurely when transcoded to PCM using above rule.

Here's the thing: Opus files can end dozens of seconds too early (they are always 48kHz), Vorbis files (at 44.1 kHz) will end a few seconds early.

An example: https://1drv.ms/u/s!AoQI5_3ipPc6pbFpdec5EBu6149x0g?e=BR17on It ends, clearly audible, about 3-4 seconds too early - every time.

I hear no difference whether this file is played back as native ogg, transcoded to flac, or transcoded to pcm. The track plays here for its duration of 6 minutes 13 seconds just the same in each case. This on a linux system. MacOS looks to be the same, I only checked the pcm transcode.

Nor did I find any difference last time: #792 (comment)

I cannot test on Windows. Perhaps the problem lies there. You might get more luck on the forum, if you can find someone else who can replicate the issue.

Note: I shall not listen to this track again. The lyric is not "family friendly".

PS. LMS tells me it is converting to 1411kbps PCM, which is 44.1kHz, not 48kHz afaik. Any way I can get LMS to stream 48kHz Vorbis as 48kHz PCM?

There's a buglet somewhere in LMS. For some reason, $track->samplesize is not set. Without this parameter, LMS just ends up displaying the default 1411kbps, instead of calculating the correct value.

It happens here: https://github.com/Logitech/slimserver/blob/public/8.4/Slim/Menu/TrackInfo.pm#L1025