Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: opus

  1. #11
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,131
    Quote Originally Posted by ralphy View Post
    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
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  2. #12
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,232
    Quote Originally Posted by philippe_44 View Post
    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.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  3. #13
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,131

    opus

    Quote Originally Posted by ralphy View Post
    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
    Last edited by philippe_44; 2019-08-11 at 13:27.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •