Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 10 of 10
  1. #1

    Hi-Res FLAC Conversion to Radio

    I'm curious about what's going on with FLAC conversion to a SB Radio, hope someone can clear this up. In playing FLAC 24/96 (or higher), LMS is seemingly converting to 24/48 FLAC (max supported by SB Radio), per this command which I extracted from the transcoder/server logs:

    [21-04-20 12:04:16.9687] Slim::Player::Song:pen (567) Tokenized command: "/usr/share/squeezeboxserver/Bin/x86_64-linux/flac" -dcs --force-raw-format --sign=signed --endian=little -- - | "/usr/share/squeezeboxserver/Bin/x86_64-linux/sox" -q -t raw --encoding signed-integer -b 24 -r 96000 -c 2 -L - -t flac -r 48000 -C 0 -

    This looks good so far, as I have the FLAC->FLAC conversion set to "Native" in File Types, so LMS is correctly keeping FLAC and down-sampling to 48k before delivery to Radio. Good.

    However, when I check the More Info as the 24/96 track is played, I see:

    Bitrate: 2486kbps VBR (Converted to 705kbps FLAC)
    Sample Rate: 96.0 kHz
    Sample Size: 24Bits

    Can this be correct? The 2486 kbps is likely the original 24/96 bit-rate, not the 24/48 converted rate? Also, how is it that a 24/48 FLAC (after conversion) is now a "705 kbps FLAC"? That seems rather low, given that the "-C 0" (compression factor) option in the sox command above is least compression?

    I'm probably just overlooking something obvious, thanks for any clarification!

  2. #2
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,063
    Quote Originally Posted by rootee View Post
    I'm curious about what's going on with FLAC conversion to a SB Radio, hope someone can clear this up. In playing FLAC 24/96 (or higher), LMS is seemingly converting to 24/48 FLAC (max supported by SB Radio), per this command which I extracted from the transcoder/server logs:

    [21-04-20 12:04:16.9687] Slim::Player::Song:pen (567) Tokenized command: "/usr/share/squeezeboxserver/Bin/x86_64-linux/flac" -dcs --force-raw-format --sign=signed --endian=little -- - | "/usr/share/squeezeboxserver/Bin/x86_64-linux/sox" -q -t raw --encoding signed-integer -b 24 -r 96000 -c 2 -L - -t flac -r 48000 -C 0 -

    This looks good so far, as I have the FLAC->FLAC conversion set to "Native" in File Types, so LMS is correctly keeping FLAC and down-sampling to 48k before delivery to Radio. Good.

    However, when I check the More Info as the 24/96 track is played, I see:

    Bitrate: 2486kbps VBR (Converted to 705kbps FLAC)
    Sample Rate: 96.0 kHz
    Sample Size: 24Bits

    Can this be correct? The 2486 kbps is likely the original 24/96 bit-rate, not the 24/48 converted rate? Also, how is it that a 24/48 FLAC (after conversion) is now a "705 kbps FLAC"? That seems rather low, given that the "-C 0" (compression factor) option in the sox command above is least compression?

    I'm probably just overlooking something obvious, thanks for any clarification!
    As this is VBR, bitrate in live conversion is not accurate/relevant


    EnvoyÚ de mon iPad en utilisant Tapatalk
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  3. #3
    Quote Originally Posted by philippe_44 View Post
    As this is VBR, bitrate in live conversion is not accurate/relevant


    EnvoyÚ de mon iPad en utilisant Tapatalk
    Fair enough. But why present it then if not accurate && irrelevant? Where are those irrelevant figures coming from? How is the user supposed to know what sox is converting/delivering to the player, unless you deep-dive the logs?

  4. #4
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,403
    Quote Originally Posted by rootee View Post
    Fair enough. But why present it then if not accurate && irrelevant? Where are those irrelevant figures coming from? How is the user supposed to know what sox is converting/delivering to the player, unless you deep-dive the logs?
    Historical is the reason for presentation. I think more useful when MP3 bit rate limited was in use.
    When a stream is compressed, associated bit rates figures are usually not accurate typically average or a target max bit rate.. When you stream an internet stream which saying 48kbps or 128kbps - it is not accurate it is probably a maximum.

    Only streaming PCM will have a constant accurate bit rate.

    The 704kbps is probably estimated by taking the duration of a segment and segment size after resampling and recompression. Estimation may only be done once (need to look at code to be sure). Real data rate would vary continuously if say music varied between between silence and a major orchestral crescendo .

  5. #5
    Quote Originally Posted by bpa View Post
    Historical is the reason for presentation. I think more useful when MP3 bit rate limited was in use.
    When a stream is compressed, associated bit rates figures are usually not accurate typically average or a target max bit rate.. When you stream an internet stream which saying 48kbps or 128kbps - it is not accurate it is probably a maximum.

    Only streaming PCM will have a constant accurate bit rate.

    The 704kbps is probably estimated by taking the duration of a segment and segment size after resampling and recompression. Estimation may only be done once (need to look at code to be sure). Real data rate would vary continuously if say music varied between between silence and a major orchestral crescendo .
    Interesting. Would it be terribly difficult to make the technical info more relevant/accurate? Perhaps something like...

    Bitrate: <nnnn.n>kbps VBR/CBR/etc.
    Sample Rate: 96.0 kHz (converted to 48 kHz)
    Sample Size: 24Bits

    Where VBR implies estimate/nominal/max/etc., and CBR means it's PCM so kbps is fixed/accurate?

    Thanks for the info!!

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,403
    Quote Originally Posted by rootee View Post
    Interesting. Would it be terribly difficult to make the technical info more relevant/accurate? Perhaps something like...

    Bitrate: <nnnn.n>kbps VBR/CBR/etc.
    Sample Rate: 96.0 kHz (converted to 48 kHz)
    Sample Size: 24Bits

    Where VBR implies estimate/nominal/max/etc., and CBR means it's PCM so kbps is fixed/accurate?
    Is it not already reasonably accurate and as relevant it it needs to be.

    When there are so many bugs and other features to implement is it worth the effort - the audio will be the same no matter what is displayed.

  7. #7
    Idk, when conversions are being made it seems reasonable to display the correct converted-to info.

    Why not then just show 24/192 for any track/stream, I suppose that would make us all feel great about our libraries and equipment!! 😂

  8. #8
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,063
    Quote Originally Posted by rootee View Post
    Why not then just show 24/192 for any track/stream, I suppose that would make us all feel great about our libraries and equipment!! 😂
    I would be scared
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  9. #9
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,403
    Quote Originally Posted by rootee View Post
    Idk, when conversions are being made it seems reasonable to display the correct converted-to info.

    Why not then just show 24/192 for any track/stream, I suppose that would make us all feel great about our libraries and equipment!! ��
    The code is open and there for you to change.

    The current approach shows the source chaarcteristics. The user knows what their system is capable of and LMS converts using lossless to the best of the player's capabilities.
    Last edited by bpa; 2021-04-22 at 13:56.

  10. #10
    Quote Originally Posted by bpa View Post
    The current approach shows the source chaarcteristics. The user knows what their system is capable of and LMS converts using lossless to the best of the player's capabilities.
    Thanks again for the info

Tags for this Thread

Posting Permissions

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