Opus playback is too fast when transcoded to PCM

[domcote]

Hey Folks,

I run LMS 8.3 release on Windows, with 3 Booms connected.

I set LMS up to transcode to PCM to save CPU cycles. It turns out, tracks play too fast - and are pitched too high. Like analog records or tapes played back too fast. Also, I can't jump anywhere in the song. I immediately get a "can't open file... audio files only" error.

The effects go away when I transcode to FLAC.

Squeezelite shows the same behavior btw. - so I'd reckon something is broken in sox/transcoding?

Any ideas what's going on? And how can I help troubleshoot?

Here is one of the tracks exhibiting this: https://1drv.ms/u/s!AoQI5_3ipPc6pY1KxxwoBM4Q32lwpg?e=ztRzkK

Tracks are converted to opus using Foobar 2000 1.6.11 and opusenc 1.3, which seems to be the latest reference encoder.

I have a feeling this may be related to https://github.com/Logitech/slimserver/issues/793.

[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

[mw9]

I think the problem here is an incorrect transcoding rule:

ops pcm * *
    [sox] -q -t opus $FILE$ -t raw -r 44100 -c 2 -2 -s -

https://github.com/Logitech/slimserver/blob/public/8.4/convert.conf#L215

There was a forum discussion about this, it is stuck in my “pending” tray. I’ll try and find and resurrect it.

One solution may simply be to remove the “fixed” resampling specification, which is simply inappropriate, and does cause “too fast” playback. Opus always specifies a sample rate of 48000.

From memory there may be one or two other rules that are similarly incorrect.

Most people will not be using the pcm transcoding rule, as flac is generally the better option.

[mw9]

@domcote

I have resurrected the forum thread on the issue.

Here was my conclusion: https://forums.slimdevices.com/showthread.php?116516-Opus-playback-speed-too-fast-high-pitched&p=1057454&viewfull=1#post1057454

Can you verify that this does, indeed, successfully resolve the issue ?

[philippe44]

You're very likely correct. In fact I added macros to convert.conf for a similar reason a couple of years ago but did not check all rules. See https://github.com/Logitech/slimserver/commit/1ad3340f49d4c74b971515e6d3c7e65494bdf881. You can, if you want, have access to the original sample rate which can be handy when dealing with raw data.

[domcote]

@domcote

I have resurrected the forum thread on the issue.

Here was my conclusion: https://forums.slimdevices.com/showthread.php?116516-Opus-playback-speed-too-fast-high-pitched&p=1057454&viewfull=1#post1057454

Can you verify that this does, indeed, successfully resolve the issue ?

Team, THANKS for not forgetting this. I'll try to find some time in the next few days and report back. 👍

[domcote]

Folks, sorry it took me so long, but I only now purchased some new music I want to add to my library. Thing is, LMS 8.2.0 won't even pick this .opus file up: https://1drv.ms/u/s!AoQI5_3ipPc6paxmkj2fO1gSZIoQsQ?e=8m1Hcv Scanner log says it "found" the file, but that is only reference I can find to it anywhere (but I'm probably not looking in the right places). In any case, LMS doesn't show this file after scanning it. Foobar2000 plays and shows all metadata, even Windows media player plays it (although without metadata display).

I got it using Foobar2000 1.6.14 and the most recent opusenc.exe and otherwise standard/default settings in Foobar2000 while converting from a source AIFF.

So while my issue is OT here, I can't continue testing until LMS is able to scan opus reliably. Thanks for your help

[mherger]

Please try LMS 8.3.1.

[domcote]

My apologies - another case of RTFM not followed...

After upgrading to 8.3.1. AND rescanning my library from scratch, LMS picked above track up.

Unfortunately, there seems to be no change: Converting to PCM --> playback still too fast and high-pitched PLUS premature end (1:28 to go) Converting to FLAC --> premature end (1:28 to go)

What can I try next?

[mw9]

What can I try next?

You could follow up my post of 1 December:

@domcote

I have resurrected the forum thread on the issue.

Here was my conclusion: https://forums.slimdevices.com/showthread.php?116516-Opus-playback-speed-too-fast-high-pitched&p=1057454&viewfull=1#post1057454

Can you verify that this does, indeed, successfully resolve the issue ?

[domcote]

@mw9 So unless I made some mistake, I copied your suggested code

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

To my convert.conf, restarted LMS and forced transcoding to PCM.

RESULT: Playback speed is now OK, but playback still ends prematurely.

[mw9]

RESULT: Playback speed is now OK, but playback still ends prematurely.

So, with this change, both PCM and FLAC end prematurely, although PCM playback speed is now ok. That’s a step forward.

Could you share a track that exhibits this behaviour ?

You shared one earlier, but the link is now dead.

[domcote]

The last track I shared yesterday is still online as far as I can see. It also ends about 1:20+ early, so should be easy to repro with it.

[mw9]

@domcote Apologies, I missed yesterday's shared track ! I have now downloaded and played it back.

I am not seeing an issue. The track plays here for its duration of 6 minutes 13 seconds. Both using FLAC and PCM playback. (Clarification: with the above revised rule for PCM, not the system default).

This is on a Linux based system (pCP) rendering to a Squeezebox Radio, and to a Squeezeplay instance.

I cannot test on Windows, which I see that you are using.

[domcote]

Darn. Is something else wrong with the file folks? Container or metadata broken? I can repro playing back to Booms and to Squeezelite-X, so it seems to be a server/windows issue. I can't repro on other players, such as Foobar2000, VLC and Windows Media Player.

[mw9]

The file looks fine here. Xiph.org's opusinfo has no problem, and LMS track info data looks as expected. You could check your own LMS track info to confirm.

Does anything show up in the LMS log that suggests premature end of playback, or a duration other than 6 minutes 13 seconds ? I'm not sure what the appropriate log setting would be to get at this, but it might be a good place to start.

[michaelherger]

@domcote I might have missed the info, but what OS are you running LMS on?

[michaelherger]

Oh, I think we can consider this one fixed, but have to look in to the "premature end" issue #793?

[mw9]

I’ll put a PR together to modify the rule appropriately. We have a working example above.

But it occurs to me that a SliMP3 does not support a 48kHz sample rate, so may need to check that this edge case is supported.

[domcote]

@domcote I might have missed the info, but what OS are you running LMS on?

Sorry @michaelherger I really need to turn on my github notifications...

I run Windows 10, naturally patched to the latest release build.

Does that help in any way?

[ChrisKolan]

I can confirm faster playback of OGG files which are sampled at 48 kHz. I cast music to ONKYO AVR with DLNA plugin. More info: Server

Version: 8.3.1 - 1676361197 @ Fri Feb 17 06:43:16 CET 2023 Hostname: alpine Server IP Address: 192.168.178.79 Operating system: Debian (Docker) - EN - utf8 Platform Architecture: x86_64-linux Perl Version: 5.32.1 - x86_64-linux-gnu-thread-multi Audio::Scan: 1.06 IO::Socket::SSL: 2.069 Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)

Players

TX-NR626 Model: UPnPBridge Type: squeezelite Firmware: 0

Plugins UPnP/DLNA bridge 2.2.2

[GeldHades27355]

Team, I installed LMS 8.5.0 recently. Native Ogg/Vorbis playback on my Booms is seriously broken since. (see https://github.com/LMS-Community/slimserver/issues/1040)

As a work-around, I enabled transcoding to PCM. I can still confirm that playback of PCM transcoded 48KHz Vorbis files is too fast, as also reported by @ChrisKolan.

My setup is very different from his tho, so it doesn't appear to be an OS or player issue after all: Logitech Media Server Version: 8.5.0 - 1710422688 @ Thu Mar 14 14:59:32 WEST 2024 Hostname: Medion IP: 192.168.178.35 HTTP Port: 9000 OS: Windows 10 (64-bit) - EN - cp1252 (fully up-to-date) Platform: 8664 Database Version: SQLite Total Players Recognized: 2

Perl and Module Versions Perl Version: 5.32.1 - MSWin32-x64-multi-thread Audio::Scan: 1.08 DBD::SQLite: 1.66 (sqlite 3.32.3) IO::Socket::SSL: 2.069 Mozilla::CA: 20200520 Net::SSLeay: 1.90 - OpenSSL 1.1.1i 8 Dec 2020

Players are 3x Boom, on FW V57

Now that I have no other option than transcoding to PCM, can I help get this fixed?

[philippe44]

What conversion rules do you have? Any other plugins that touches convert.conf? Also, see my answer on the other thread, it can be something that became inactive in 8.5.x as in my system, the faulty files where faulty as well on a vanilla 8.3.0

[GeldHades27355]

Everything is default. Only thing I changed was to ensure Vorbis transcodes to PCM via GUI.

It was faulty on 8.3.1. too - but I never updated since. I just assumed it was addressed in 8.5.0 - but it doesn't look like it.

Edit: I did a complete uninstall and fresh install to ensure nothing was carried over.

[philippe44]

Try to do one of the following on the ogg pcm or ogg aif lines of convert.conf

1- remove the -r 44100 option 2- replace it by -r %d 3- replace it by -r $SAMPLERATE$

[philippe44]

I think what happens is that LMS has the proper target sample rate and sends it to the player in the http headers (remember that pcm is not s self-described format) but that rules does force a transcoding to 44.1 for no good reason. The idea is that we should set all theses opus and vorbis rules to use whether LMS has decided to use as sample rate for the player, hence the %d which is probably the proper fix