opus

[philippe_44]

> I mean not doing a plugin to add this codec support, but have LMS
> recognize it in the HELO message and then send opus encoded (codec ‘u’
> maybe) file to players in strms command (modifying the squeezebox.pm). I
> think I can do this part but I’m less familiar with the transcoding
> rules and I don’t know what would need to be added there.

And you'd think I was familiar with it?... :-D

I think the player can somehow return a list of capabilities which would
be parsed in Slimproto.pm (line 950ff). That list can define additional
codecs supported by the player.

--

Michael

[philippe_44]

opus

Hi - Is there a benefit/interest/motivation to have opus supported by squeezelite?

[philippe_44]

Just responding to myself

I saw that opus is already supported at least to be transcoded, so I added it in YouTube 0.90

[mherger]

opus

It's a relatively recent addition (Oct '18). Just in case somebody
complained about it not working.

--

Michael

[philippe_44]

It's a relatively recent addition (Oct '18). Just in case somebody
complained about it not working.

--

Michael

I won't It was a pleasant surprise.

Do you think it's difficult to add a new codec (eg 'ops') to the baseline of LMS? I think I can 'easily' add the support in squeezelite. I looked at it a bit more after my 1st post and the interface of opus seems very simple, and building/finding static and shared/dll. Opus seems to be gaining popularity

[mherger]

opus

> Do you think it's difficult to add a new codec (eg 'ops') to the
> baseline of LMS?

What do you mean by "baseline of LMS"?

--

Michael

[philippe_44]

> Do you think it's difficult to add a new codec (eg 'ops') to the
> baseline of LMS?

What do you mean by "baseline of LMS"?

--

Michael

I mean not doing a plugin to add this codec support, but have LMS recognize it in the HELO message and then send opus encoded (codec ‘u’ maybe) file to players in strms command (modifying the squeezebox.pm). I think I can do this part but I’m less familiar with the transcoding rules and I don’t know what would need to be added there.

[philippe_44]

It's now working fine with nightly 07/31 using squeezelite, my bridges and the esp32 version - thanks!

[philippe_44]

I think there is an error in the system's convert.conf. It says

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

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

But the sample rate sent by LMS in the slimproto header is still 48kHz, which BTW is normally the fixed opus sample rate (according to spec, all decoded opus file should be 48k, unless overwritten by user).

Is there a reason why the sox rules force 44100 and if there is, then we should change what LMS sends in slimproto (and I'm not sure where that change should be made)

(note that in flac's rule there is no such sampling rate forcing)

[ralphy]

The opus rules in convert.conf were likely modeled after the ogg rules. This was part of PR#133

However, slimproto will always send the original sample rate for pcm conversion rules. This is true for ogg and wma as well.

[philippe_44]

The opus rules in convert.conf were likely modeled after the ogg rules. This was part of PR#133

However, slimproto will always send the original sample rate for pcm conversion rules. This is true for ogg and wma as well.

Wouldn’t still it better to let the sample rate be whatever it is (which should be 99% of times 48kHz) instead of forcing 44.1kHz which will be 99% of the time incorrect? I know that Opus, unless forced, always outputs at 48kHz and the sample rate it reports is the original sample rate, but almost all content I’ve seen is originally 48kHz

[ralphy]

Wouldn’t still it better to let the sample rate be whatever it is (which should be 99% of times 48kHz) instead of forcing 44.1kHz which will be 99% of the time incorrect? I know that Opus, unless forced, always outputs at 48kHz and the sample rate it reports is the original sample rate, but almost all content I’ve seen is originally 48kHz

Even opusenc resamples 44.1 flac files to 48 opus, so changing the convert.conf rules to 48000 does seem to be the way to go.
There is a reason why LMS always assumes PCM is 44100/16 when not reading from a 'real' local WAV/AIF file, but I've been unable to confirm that anywhere on the forum or the slimserver commit logs.
I've found several posts between you and Marco (C3PO plugin author) discussing it however. I guess wading through the LMS code is the only way to confirm it. However, it may be a carry over from the original slimp3 hardware player in which the DAC only supported 44.1.

[philippe_44]

opus

Even opusenc resamples 44.1 flac files to 48 opus, so changing the convert.conf rules to 48000 does seem to be the way to go.
There is a reason why LMS always assumes PCM is 44100/16 when not reading from a 'real' local WAV/AIF file, but I've been unable to confirm that anywhere on the forum or the slimserver commit logs.
I've found several posts between you and Marco (C3PO plugin author) discussing it however. I guess wading through the LMS code is the only way to confirm it. However, it may be a carry over from the original slimp3 hardware player in which the DAC only supported 44.1.

I’m not sure I’m following. What I’ve observed is that when LMS transcodes an opus to pcm, the slimproto header says it is a 48kHz file (not a 44.1) and this is because LMS is capable of getting metadata from the opus file/stream, so at this point everything could be good and all players would play correctly.

The problem is that the ops to pcm rule forces resampling at 44.1 and LMS is not made aware of that and this what imho is wrong. The ops to flc rule rightfully does not do that.

I think the simple change is to remove resampling from the ops to pcm.

There would still be a problem with opus files whose original source rate was not 48kHz. Depending on what Sox does, there are two options

1/ if sox uses the native opus decoded rate (48kHz) then we can force the LMS opus metadata reading to be 48kHz, regardless of headers, this will always be correct

2/ if sox resamples the output of opus decode to match the original file rate (or if we want to force it to do that) then we should not do anything special in the sox to pcm rule as LMS will get the same sample rate info from the header

In both case, I think forcing sox rule to resample at 44.1 and letting LMS use the rate found in header is always wrong

[edit]: sorry, I wrongly read ´changing the convert.conf rule does NOT seem the way to go’, hence my response