Transcoding FLAC->Ogg?

[Phil Leigh]

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.

[Phil Leigh]

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?

[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

[Phil Leigh]

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?

[JJZolx]

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.

[RadBadMark]

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...

[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:

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.

[JJZolx]

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:

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?

[wt0]

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.