Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 36
  1. #21
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by bpa View Post
    need to double check the flac DECODE output is PCM. There are force options to force raw (i.e. PCM) so I doubt myself now.
    It seems to be a WAV, specifically: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz, on a test I made.

    I downloaded a minute or so of streamed ogg/flac into a file, and 'catted' it into the LMS pipeline to see what would happen. sox did not fare well with the WAV, as observed earlier, but fared OK with the AIFF.

    In both cases, flac warned:
    don't have accurate sample count available for WAVE/AIFF header
    which probably bears upon matters. Why sox handled the AIFF but not the WAV remains unknown to me.

    I suspect that re-running the procedure over a 'pre-converted' ogg formatted file, no doubt with 'fuller' headers, would produce different results.

    WAV example:

    Code:
    root@LMS-Server:/etc# cat 'test.ogg'|/usr/share/squeezeboxserver/Bin/arm-linux/flac --ogg -dc  -- -|/usr/share/squeezeboxserver/Bin/arm-linux/sox -S -t wav - -t flac -C 0 -r 22050 - |cat >test.flac
    
    FLAC SAYS
    flac 1.3.2
    Copyright (C) 2000-2009  Josh Coalson, 2011-2016  Xiph.Org Foundation
    flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
    welcome to redistribute it under certain conditions.  Type `flac' for details.
    
    -: WARNING, don't have accurate sample count available for WAVE header.
                 Generated WAVE file will have a data chunk size of 0.  Try
                 decoding directly to a file instead.
    
    SOX SAYS
    Input File     : '-' (wav)
    Channels       : 2
    Sample Rate    : 44100
    Precision      : 16-bit
    Sample Encoding: 16-bit Signed Integer PCM
    
    In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0    
    Done.
    TERMINATED ALMOST IMMEDIATELY
    CHECK ON FILE:
    root@LMS-Server:/etc# file test.flac
    test.flac: FLAC audio bitstream data, 16 bit, stereo, 22.05 kHz, length unknown
    IT'S ONLY 114 BYTES LONG.
    AIFF example:
    Code:
    root@LMS-Server:/etc# cat 'test.ogg'|/usr/share/squeezeboxserver/Bin/arm-linux/flac --ogg -dc --force-aiff-format  -- -|/usr/share/squeezeboxserver/Bin/arm-linux/sox -S -t aiff - -t flac -C 0 -r 22050 - |cat >test.flac
    
    FLAC SAYS
    flac 1.3.2
    Copyright (C) 2000-2009  Josh Coalson, 2011-2016  Xiph.Org Foundation
    flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
    welcome to redistribute it under certain conditions.  Type `flac' for details.
    
    -: WARNING, don't have accurate sample count available for AIFF header.
                 Generated AIFF file will have a data chunk size of 0.  Try
                 decoding directly to a file instead.
    
    SOX SAYS
    Input File     : '-' (aiff)
    Channels       : 2
    Sample Rate    : 44100
    Precision      : 16-bit
    Sample Encoding: 16-bit Signed Integer PCM
    
    In:0.00% 00:01:39.85 [00:00:00.00] Out:2.20M [!=====|====WARNING, cannot check MD5 signature since it was unset in the STREAMINFO
    done         
    In:0.00% 00:01:40.31 [00:00:00.00] Out:2.21M [  ====|====- ] Hd:0.2 Clip:13   
    /usr/share/squeezeboxserver/Bin/arm-linux/sox WARN dither: dither clipped 13 samples; decrease volume?
    Done.
    SEEMED TO RUN TO COMPLETION
    CHECK ON FILE:
    root@LMS-Server:/etc# file test.flac
    test.flac: FLAC audio bitstream data, 16 bit, stereo, 22.05 kHz, length unknown
    So there we are.

    RAW format looks more complicated to use (--force-raw-format), and may require communication of sample rates, etc., to sox. I'm not sure that that would be available.
    There is also --force-rf64-format and --force-wave64-format, which mean nothing to me.
    Last edited by mrw; 2020-02-04 at 17:50. Reason: AIFF example, not FLAC

  2. #22
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by D1eter View Post
    I have tried again and after some reading and experimentation I found I have to use

    [flac] --ogg -dcs -- $FILE$ | [sox] -q --ignore-length -t wav - -t flac -C 0 $RESAMPLE$ -

    This is because flac sets chunksize in the wav header to 0 (meaning unknown) causing sox to stop exactly there (i.e. immediately) unless --ignore-length is used. Now I can play the stream on all my Squeezeboxen again.
    Excellent ! You have clearly gained more understanding of sox than I have in the last few hours...

  3. #23
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,430

    SB Radio no longer plays 24/96 OGF stream

    > Should this remain a custom conversion rule or can it become standard?

    I'd be happy to use this as the standard - if I knew it was working
    correctly! Would you have a good collection of OGF streams you can test
    with?

    --

    Michael

  4. #24
    Quote Originally Posted by mherger View Post
    > Should this remain a custom conversion rule or can it become standard?

    I'd be happy to use this as the standard - if I knew it was working
    correctly! Would you have a good collection of OGF streams you can test
    with?
    I'm afraid I don't. I only know one such stream and only because I create it myself. I'd also like to know if sox can convert ogg/flac to flac directly but I didn't get around to test that yet.

    In addition, one glitch remains: When I play the stream on the Touch and then turn on a Radio that is synchronised with the Touch there should be a brief pause and the stream should restart playing in sync on both. This does not work consistently. Sometimes it does, sometimes the Radio displays an error message (file not found or something close). In case of the error pressing play on the Radio does start the synchronised stream. I have yet to do a systematic investigation of all possible combinations turning on/off synchronised players to get a clearer picture.

  5. #25
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by D1eter View Post
    I'm afraid I don't. I only know one such stream and only because I create it myself.
    The only online sources I have found are here:

    https://community.auralic.com/t/loss...o-ogg-flac/852
    https://www.hiresaudio.online/cd-qua...nternet-radio/

    I have used http://rod.frequence3.net/frequence3.flac.m3u once or twice for testing.

    They all seem to be regular 44100/48000 sample rate streams.

    In addition, one glitch remains: When I play the stream on the Touch and then turn on a Radio that is synchronised with the Touch there should be a brief pause and the stream should restart playing in sync on both. This does not work consistently.
    I suspect that this stems from joining a 48kHz Radio into a pre-existing group operating at 96kHz. That, of necessity I think, requires the whole group to be restarted at the 48kHz sample rate. I wonder what would happen if you play the stream on the Radio, and then turn on the Touch.

    I've never had much success with a group that mixes 96kHz and 48kHz players when playing 96kHz flac files, too much rebuffering. That may stem from my having a somewhat underpowered server. So, I simply don't use 96kHz sample rate streams, I wouldn't hear the difference anyway.


    As a supplementary trick, you could choose to countermand the Radio's stricture that it will only accept a 48kHz stream by adding a custom conversion rule something like:

    Code:
    ogf flc baby *
    	# IFRD:{RESAMPLE=-r %d}
    	[flac] --ogg -dcs -- $FILE$ | [flac] -cs --ignore-chunk-sizes --totally-silent --compression-level-0 -
    This rule will only apply to a Radio, and will, I think, take precedence over any existing rule. The Radio will then operate "just as it used to", and receive a 96kHz sample rate stream. It uses the original conversion rule, but fools LMS into thinking that the required down sampling is taken care of.

    I fed an 88.2kHz sample rate stream to my Radio to remind myself of what issue I had previously observed. It is this: the sound effects have somewhat "tinky" sound to them, although the stream seems to play fine.

    I note that the Radio's ALSA subsystem down samples the stream to 48kHz, not the 44.1kHz that one might expect, and that may well contribute to to the "tinkiness".



    As regards updating LMS: if it should be found that the proposed new rule is not as reliable for the normal use case (presumably 44.1kHz/48kHz streams), then one could, perhaps, use the existing flc -> flc trick, and formulate the new rule as follows:

    Code:
    ogf flc transcode *
            # IFRD:{RESAMPLE=-r %d}
            [flac] --ogg -dcs -- $FILE$ | [sox] -q --ignore-length -t wav - -t flac -C 0 $RESAMPLE$ -
    If my understanding is correct, that rule would only come into effect when resampling is actually required. But I haven't validated that, it would need testing.

    I would be surprised if the replacement of:

    [flac] -cs --ignore-chunk-sizes --totally-silent --compression-level-0 -

    with:

    [sox] -q --ignore-length -t wav - -t flac -C 0 $RESAMPLE$ -

    does introduce unreliability, but I am frequently surprised.
    Last edited by mrw; 2020-02-05 at 11:50.

  6. #26
    First for the easy part: Neither the sox bundled with LMS nor the one that comes with Raspbian can decode ogg/flac.

    Quote Originally Posted by mrw View Post
    I've never had much success with a group that mixes 96kHz and 48kHz players when playing 96kHz flac files, too much rebuffering.
    I suspect the problem in my case is not mixing 96kHz with 48kHz players but rather that the Touch (or the Controller) can play this stream direct while the Radio (and, strangley, the Receiver) always need the server to decode the stream. Before our new custom rule all got fed the 96kHz stream but this was still a major difference between them.

    Quote Originally Posted by mrw View Post
    As a supplementary trick, you could choose to countermand the Radio's stricture that it will only accept a 48kHz stream by adding a custom conversion rule something like:

    Code:
    ogf flc baby *
    	# IFRD:{RESAMPLE=-r %d}
    	[flac] --ogg -dcs -- $FILE$ | [flac] -cs --ignore-chunk-sizes --totally-silent --compression-level-0 -
    This rule will only apply to a Radio, and will, I think, take precedence over any existing rule. The Radio will then operate "just as it used to", and receive a 96kHz sample rate stream. It uses the original conversion rule, but fools LMS into thinking that the required down sampling is taken care of.
    I agree that this should force the old behaviour though the the problem with the Radio needing the server to decode while the Touch can play direct remains the same.

    Quote Originally Posted by mrw View Post
    I fed an 88.2kHz sample rate stream to my Radio to remind myself of what issue I had previously observed. It is this: the sound effects have somewhat "tinky" sound to them, although the stream seems to play fine.

    I note that the Radio's ALSA subsystem down samples the stream to 48kHz, not the 44.1kHz that one might expect, and that may well contribute to to the "tinkiness".
    I don't have 88.2kHz material. What does the custom rule do with that? Downsample to 48kHz (rather than 44.1kHz)? That's not as easy to get right as 96->48.

    Quote Originally Posted by mrw View Post
    As regards updating LMS: if it should be found that the proposed new rule is not as reliable for the normal use case (presumably 44.1kHz/48kHz streams), then one could, perhaps, use the existing flc -> flc trick, and formulate the new rule as follows:

    Code:
    ogf flc transcode *
            # IFRD:{RESAMPLE=-r %d}
            [flac] --ogg -dcs -- $FILE$ | [sox] -q --ignore-length -t wav - -t flac -C 0 $RESAMPLE$ -
    If my understanding is correct, that rule would only come into effect when resampling is actually required. But I haven't validated that, it would need testing.
    Interesting point. The custom rule should not be used unless resampling is required. I'll need to do some more testing...

  7. #27
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by D1eter View Post
    I don't have 88.2kHz material. What does the custom rule do with that? Downsample to 48kHz (rather than 44.1kHz)? That's not as easy to get right as 96->48.
    LMS (with a resampling rule) is smart enough to down sample to 44.1kHz. It looks for multiples of 11025, or 12000, or something like that.

  8. #28
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by D1eter View Post
    Interesting point. The custom rule should not be used unless resampling is required. I'll need to do some more testing...
    Iĺd say: only if the new rule, using sox, actually does create a problem for streams that donĺt need resampling. Otherwise it simply adds unnecessary complication.

  9. #29
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by D1eter View Post
    I agree that this should force the old behaviour though the the problem with the Radio needing the server to decode while the Touch can play direct remains the same.
    True. But perhaps less of a problem than requiring the sync group to adopt a new sample rate.

  10. #30
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    527
    Quote Originally Posted by D1eter View Post
    I suspect the problem in my case is not mixing 96kHz with 48kHz players but rather that the Touch (or the Controller) can play this stream direct while the Radio (and, strangley, the Receiver) always need the server to decode the stream.
    The Touch and the Controller both run Squeezeplay v7.8, which has native support for decoding an ogg/flac stream.

    The Radio runs Squeezeplay v7.7, which does not. I doubt that any of the previous line-up, e.g. Receiver, has it either.

Posting Permissions

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