Transcoding FLAC->Ogg?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Phil Leigh
    Senior Member
    • Apr 2005
    • 9991

    #16
    Originally posted by RadBadMark
    Thanks Phil, I think I know why the workaround with the MAC doesn't work in my case. From the 7.6 changelog "Transcoding is now supported when requesting an HTTP download (/music/[id]/download[.extension])." I'm guessing the "id" (which is the MAC/IP) is optional, and maybe Squeezecommander doesn't supply this info in the request. Just a guess though so I'll ask flattermann the dev about it.

    Regardless, I should still be able to enable the rule as flc-ogg-*-* so any device can use the transcode, and without screwing up the native flc-flc streaming. This would be preferable as I would rather not have to dive into custom-conv.conf everytime I need to download a transcoded track to a new device. Seems to work fine when specifying mp3 or wav as the output type, I'd like the same for ogg if possible!

    Anyone know why adding a universal flc-ogg rule breaks the flc-flc native streaming (..or maybe it's just my system?), or is this a legitimate bug?
    if you have 2 rules:

    flc flc * *
    and
    flc ogg * *

    which one is supposed to be executed?
    You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal...
    Touch(wired/W7)+Teddy Pardo PSU - Audiolense 3.3/2.0+INGUZ DRC - MF M1 DAC - Linn 5103 - full Aktiv 5.1 system (6x LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Pekin Tuner, Townsend Supertweeters,VdH Toslink,Kimber 8TC Speaker & Chord Signature Plus Interconnect cables
    Stax4070+SRM7/II phones
    Kitchen Boom, Outdoors: SB Radio, Harmony One remote for everything.

    Comment

    • RadBadMark
      Junior Member
      • May 2011
      • 19

      #17
      If it's a flac file, flc-flc native should be selected, unless told to do otherwise (either by player capability, or download request) - just like flc-mp3 and flc-pcm behave.

      Another way of looking at it, why am I able to enable
      flc flc * *
      flc mp3 * *
      flc pcm * *

      all at the same time and streaming, downloading all work fine? With this I can stream to all my squeezeboxes in flac for native decode, and also request an http download of that same flac file in either flac, mp3 or wav. This is the correct behaviour as I understand from my (very) limited knowledge, and adding a flc ogg * * rule appears to break this!

      Comment

      • flattermann
        Senior Member
        • Oct 2009
        • 774

        #18
        Originally posted by RadBadMark
        From the 7.6 changelog "Transcoding is now supported when requesting an HTTP download (/music/[id]/download[.extension])." I'm guessing the "id" (which is the MAC/IP) is optional, and maybe Squeezecommander doesn't supply this info in the request. Just a guess though so I'll ask flattermann the dev about it.
        This id is the track id, not the MAC/IP.

        I don't think that the SBS can evaluate the MAC for http downloads, because this information is only send to the SBS for streaming connections (i.e. real players).

        And the SBS cannot obtain the MAC from an IP on his own, because that will not work in a routed setup, e.g. using a LAN server with a WLAN android device the SBS would see the router MAC only.

        Sent from my Galaxy Tab using Tapatalk.
        Christian

        Home of SqueezeCommander - The SqueezeBox Remote Control App for Android

        Comment

        • Phil Leigh
          Senior Member
          • Apr 2005
          • 9991

          #19
          Originally posted by RadBadMark
          If it's a flac file, flc-flc native should be selected, unless told to do otherwise (either by player capability, or download request) - just like flc-mp3 and flc-pcm behave.

          Another way of looking at it, why am I able to enable
          flc flc * *
          flc mp3 * *
          flc pcm * *

          all at the same time and streaming, downloading all work fine? With this I can stream to all my squeezeboxes in flac for native decode, and also request an http download of that same flac file in either flac, mp3 or wav. This is the correct behaviour as I understand from my (very) limited knowledge, and adding a flc ogg * * rule appears to break this!
          That isn't the way it works. flac flac * * will ALWAYS be selected in your example above when playing a flac file. If flc flc * * is disabled, flacs will stream as MP3's; if flc mp3 * * is then also disabled then flacs will stream as PCM.
          Last edited by Phil Leigh; 2011-05-10, 09:36.
          You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal...
          Touch(wired/W7)+Teddy Pardo PSU - Audiolense 3.3/2.0+INGUZ DRC - MF M1 DAC - Linn 5103 - full Aktiv 5.1 system (6x LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Pekin Tuner, Townsend Supertweeters,VdH Toslink,Kimber 8TC Speaker & Chord Signature Plus Interconnect cables
          Stax4070+SRM7/II phones
          Kitchen Boom, Outdoors: SB Radio, Harmony One remote for everything.

          Comment

          • RadBadMark
            Junior Member
            • May 2011
            • 19

            #20
            Originally posted by Phil Leigh
            That isn't the way it works. flac flac * * will ALWAYS be selected in your example above when playing a flac file. If flc flc * * is disabled, flacs will stream as MP3's; if flc mp3 * * is then also disabled then flacs will stream as PCM.

            That is the way it works, I've been using it, try it and see! If it didn't, what would be the point of the new feature "Transcoding is now supported when requesting an HTTP download (/music/[id]/download[.extension])" in 7.6?

            You are correct that flc-flc-*-* *should* always be selected when playing a flac file on a capable squeezebox, that's EXACTLY what I do want - and that's the issue, when I add a rule for flc-ogg (to add the ability to http download server transcoded flc-ogg files), the native flc-flc rule is ignored when trying to playback flac files on the squeezebox.

            I think we're both expecting it to work in the same way regarding file playback, but maybe I havn't been too clear about my use of http download for on the fly transcoding?

            Comment

            • Phil Leigh
              Senior Member
              • Apr 2005
              • 9991

              #21
              Originally posted by RadBadMark
              That is the way it works, I've been using it, try it and see! If it didn't, what would be the point of the new feature "Transcoding is now supported when requesting an HTTP download (/music/[id]/download[.extension])" in 7.6?

              You are correct that flc-flc-*-* *should* always be selected when playing a flac file on a capable squeezebox, that's EXACTLY what I do want - and that's the issue, when I add a rule for flc-ogg (to add the ability to http download server transcoded flc-ogg files), the native flc-flc rule is ignored when trying to playback flac files on the squeezebox.

              I think we're both expecting it to work in the same way regarding file playback, but maybe I havn't been too clear about my use of http download for on the fly transcoding?
              Ah... I see... apologies, I thought you were talking about playing a file via SBS. I'll try this "HTTP download" approach and see what happens.
              You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal...
              Touch(wired/W7)+Teddy Pardo PSU - Audiolense 3.3/2.0+INGUZ DRC - MF M1 DAC - Linn 5103 - full Aktiv 5.1 system (6x LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Pekin Tuner, Townsend Supertweeters,VdH Toslink,Kimber 8TC Speaker & Chord Signature Plus Interconnect cables
              Stax4070+SRM7/II phones
              Kitchen Boom, Outdoors: SB Radio, Harmony One remote for everything.

              Comment

              • Phil Leigh
                Senior Member
                • Apr 2005
                • 9991

                #22
                I've played with this a lot more...

                It seems to go back to what I said earlier; when playing flac files from your library via SBS, if you have 2 active filetype rules:
                flc flc * *
                and
                flc ogg * *

                then one has to consistently win. As things stand, the ogg rule wins every time. I'm not sure why, but it does.

                If you were using real SB players (or at least something with a MAC address) you could make the whole system do exactly what you want.

                How would I test the "HTTP downloading" aspect?
                You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal...
                Touch(wired/W7)+Teddy Pardo PSU - Audiolense 3.3/2.0+INGUZ DRC - MF M1 DAC - Linn 5103 - full Aktiv 5.1 system (6x LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Pekin Tuner, Townsend Supertweeters,VdH Toslink,Kimber 8TC Speaker & Chord Signature Plus Interconnect cables
                Stax4070+SRM7/II phones
                Kitchen Boom, Outdoors: SB Radio, Harmony One remote for everything.

                Comment

                • RadBadMark
                  Junior Member
                  • May 2011
                  • 19

                  #23
                  The native rule should always win (assuming the player has native capability and the native rule is not disabled) and if you look at the log the flc-flc rule is checked for first, but then something goes wrong and the rule seems to get ignored as the server moves on to checking flc-ogg. At least now I know the problems not specific to my system

                  To test the http download

                  http://[Server IP]:[port]/music/[id]/download[.extension]

                  id is the id of the track you want to download, you can find it by looking at the download link of individual tracks in the web interface. extension is the file extension you want, transcoded or otherwise.

                  e.g

                  Comment

                  • Phil Leigh
                    Senior Member
                    • Apr 2005
                    • 9991

                    #24
                    Originally posted by RadBadMark
                    The native rule should always win (assuming the player has native capability and the native rule is not disabled) and if you look at the log the flc-flc rule is checked for first, but then something goes wrong and the rule seems to get ignored as the server moves on to checking flc-ogg. At least now I know the problems not specific to my system

                    To test the http download

                    http://[Server IP]:[port]/music/[id]/download[.extension]

                    id is the id of the track you want to download, you can find it by looking at the download link of individual tracks in the web interface. extension is the file extension you want, transcoded or otherwise.

                    e.g
                    http://192.168.1.6:9000/music/11046/download.mp3
                    When you say the native rule "should" always win - do you mean that is how it is actually coded or is that how you think it should work?
                    You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal...
                    Touch(wired/W7)+Teddy Pardo PSU - Audiolense 3.3/2.0+INGUZ DRC - MF M1 DAC - Linn 5103 - full Aktiv 5.1 system (6x LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Pekin Tuner, Townsend Supertweeters,VdH Toslink,Kimber 8TC Speaker & Chord Signature Plus Interconnect cables
                    Stax4070+SRM7/II phones
                    Kitchen Boom, Outdoors: SB Radio, Harmony One remote for everything.

                    Comment

                    • JJZolx
                      Senior Member
                      • Apr 2005
                      • 11597

                      #25
                      Originally posted by Phil Leigh
                      When you say the native rule "should" always win - do you mean that is how it is actually coded or is that how you think it should work?
                      That's how it should work, in addition to favoring lossless streaming for a lossless codec. That's how it's always been explained in these forums by the developers. When Flac-Flac and Flac-Mp3 are both enabled there are no issues, as long as the player plays Flac natively, that's what is streamed.

                      It's a bug. The problem appears to be that when you toss it another rule, SBS all of a sudden requires the ability to seek to a start time offset.

                      Comment

                      • RadBadMark
                        Junior Member
                        • May 2011
                        • 19

                        #26
                        Hmmmmm, I've had a quick scan through the code, and rightly or wrongly it looks like this is the way it's been coded, capabilities in order of preference for the squeezebox classic are

                        wma ogg flc aif pcm mp3 (from slim/player/Squeezebox2.pm)

                        I'm not too hot on Perl but it does look like despite mentioning "Checking to see if flc-flc-*-* is enabled" in the log, the server doesn't actually give priority to this, it looks at the above (per player) order of preference instead and checks this against the audio type rather than the other way around.

                        If this is the case, what's not immediately obvious is why the flc-flc native rule isn't picked up when the ogg-flc rule fails as a consequence of me not providing a start time option. As JJZolx mentions, the server suddenly demands the start time option for the native rule too, so that now fails in a similar way...

                        Comment

                        • awy
                          Senior Member
                          • Sep 2006
                          • 794

                          #27
                          You are all thinking about this logically, rather than how it actually works.

                          Each player type defines a set of formats that it supports. For the majority this is:
                          Code:
                          wma ogg flc aif pcm mp3
                          The point is that this is a priority order. There is a built-in assumption that convert.conf will not contain a trancoding rule that might transcode a lower-priority format to a higher-priority one.

                          Comment

                          • JJZolx
                            Senior Member
                            • Apr 2005
                            • 11597

                            #28
                            Originally posted by awy
                            You are all thinking about this logically, rather than how it actually works.

                            Each player type defines a set of formats that it supports. For the majority this is:
                            Code:
                            wma ogg flc aif pcm mp3
                            The point is that this is a priority order. There is a built-in assumption that convert.conf will not contain a trancoding rule that might transcode a lower-priority format to a higher-priority one.
                            Why would wma and ogg have a higher priority than Flac?

                            Comment

                            • wt0
                              Senior Member
                              • Jul 2008
                              • 769

                              #29
                              Originally posted by JJZolx
                              Why would wma and ogg have a higher priority than Flac?
                              My guess is that since there are no default rules for converting anything to wma or ogg, these two formats are set to higher priority so that if you need to use a player on a lower bandwidth connection then you'll just have to add a flc->wma or flc->ogg rule for that player to make it work without having to disable the flc->flc rule.
                              --------------
                              Squeezebox apps for Android and Windows UWP, http://www.angrygoatapps.com

                              Comment

                              Working...