PDA

View Full Version : Settings | Advanced | File Types & Settings | Player | Audio?



AndrewFG
2008-11-23, 07:27
How does Settings | Advanced | File Types work?
And does Settings | Player | Audio have any impact on it?

If I understand it correctly, SqueezeCenter can convert any given input file type on the fly to three or four different other stream formats before sending it to the player concerned ??

If so, what are the parameters of e.g. client PC, O/S, SqeezeCenter, LAN type, LAN speed, player type etc. that determine which actual stream format is sent?

All of my music files are in Apple MP4 (file extension .M4A) and 99% of them are are encoded using Apple Lossless. Is this what you call "alac"? The File Types page allows conversion of Apple Lossless to FLAC, MP3 or WAV. I suppose the best stream type for my files is FLAC? Or is it WAV? And are there any circumstances why I would want SqueezeCenter to convert to any other format than the best? Is it safer to disable all but the best formats?

Presently my players are a Transporter and a Duet. Perhaps, in future -- when the feature finally becomes available -- I may also play music over SoftSqueeze/SqueezePlay or the audio outputs on the Duet controller...

This leads to my next question: does Settings | Player | Audio have any impact on how Settings | Advanced | File Types works? Do any of the player specific crossfade, clock, bitrate limiting, LAME quality level, volume adjustment, replay gain, settings have any impact on the stream format that SqueezeCenter sends? And what happens when I have two (different type) players synchronized to the same music?

Finally are there any plans for Transporter and Duet to handle Apple Lossless natively in firmware, and thus eliminate all this trancoding entirely?

Phil Leigh
2008-11-23, 08:25
Andrew - that's a mega-question!
I'll make a start:
1) Slim can't support Apple natively because Apple is a proprietory format - sorry but AFAIK that will never happen, thanks to Apple.
2) Your player settings are independent of each other - even when synced.
3) You should set ALAC to stream as FLAC for minimum impact on your network.
4) Some features (eg replaygain) don't work if streaming WAV instead of FLAC/MP3
5) if you specific "no limit" in the limit bitrate box, then it will stream FLAC or WAV - not sure how it chooses which if both are enabled. If you set limiting, it will stream as MP3 instead (unless youhave disabled this option in file settings)

6) LAME quality level is about degree of compression vs. CPU load not sound quality - leave it set on 9
7) not sure if crossfade works with WAV? - maybe FLAC/MP3 only
8) some people need to stream as MP3 for marginal wi-fi setups or for streaming across the net.

JJZolx
2008-11-23, 08:41
How does Settings | Advanced | File Types work?
And does Settings | Player | Audio have any impact on it?

They're related. First comes the File Types settings, which is universal and mostly tells SqueezeCenter what it is permitted to do as far as streaming and transcoding are concerned. Its only practical function, as I see it, is to permit the user to disable streaming in some particular format. Since Flac is normally the default format use, then this in turn means it's only really useful for forcing streaming in WAV.


If so, what are the parameters of e.g. client PC, O/S, SqeezeCenter, LAN type, LAN speed, player type etc. that determine which actual stream format is sent?

OS (and the software expected to be installed on that OS) determines which conversions might be found on the File Types page.

The actual streaming format is determined by that, the player type, and the bitrate limiting setting on the player's Audio setting page.

With lossless file formats, newer (Squeezebox2 and later) players will normally use Flac for streaming. Older players, which aren't capable of decoding Flac in their firmware, will be sent a WAV stream.


All of my music files are in Apple MP4 (file extension .M4A) and 99% of them are are encoded using Apple Lossless. Is this what you call "alac"?

Yes and no. Apple Lossless is often referred to as ALAC. But on the File Types page, at least on my Windows system, the file format is shown as "Apple Lossless" and the decoder "alac" refers to the alac.exe program that is used to decode the format.


The File Types page allows conversion of Apple Lossless to FLAC, MP3 or WAV. I suppose the best stream type for my files is FLAC? Or is it WAV?

You shouldn't have to worry about it, as the best format will automaticlaly be chosen. But see the next answer, below.


And are there any circumstances why I would want SqueezeCenter to convert to any other format than the best?

Two that I can think of. One practical, the other fairly controversial and argued in other threads.

If you have wireless network issues, you might want to set bitrate limiting just to get wireless streaming to work. This is particular the case for older players that must be streamed WAV over a slower 802.11b network and that have small buffers, making dropouts much more common than with newer players.

The other reason is debatable, but I'll mention it, and hope the thread doesn't go off on a tangent. Some audiophiles claim that WAV sounds better than Flac (and some claim Flac sounds better than WAV, so it goes both ways). This shouldn't be the case, as Flac is lossless and will decode to exactly the same bits and bytes. Theories on why this might be the case generally speculate that the greater CPU activity needed to decode the Flac stream has a negative audible effect. Conversely, speculation as to why Flac might sound better than WAV is that the CPU and network electronics actually do less work handling the lower network traffic.

They sound exactly the same to me.


Is it safer to disable all but the best formats?

Can't hurt anything, but it's no "safer".

Disabling, say, Mp3 streaming for ALAC, won't accomplish anything if you don't have bitrate limiting set. I stream from my home SqueezeCenter to my work computer running Squeezeslave, with a library in Flac. The only practical way to do that is to set bitrate limiting and stream in Mp3. But that only affects that one player, and the others are streamed in Flac.


This leads to my next question: does Settings | Player | Audio have any impact on how Settings | Advanced | File Types works?

Do any of the player specific crossfade, clock, bitrate limiting, LAME quality level, volume adjustment, replay gain, settings have any impact on the stream format that SqueezeCenter sends?

Just bitrate limiting. Setting it to anything other than 'No Limit' will mean transcoding to Mp3.


And what happens when I have two (different type) players synchronized to the same music?

You won't have to worry about it unless you have a pre-SB2 player synched to a newer one. All the newer players have the same decoding capabilities in their firmware.

JJZolx
2008-11-23, 08:55
6) LAME quality level is about degree of compression vs. CPU load not sound quality - leave it set on 9

That's incorrect. It isn't a compression level, but a separate quality level. This is a LAME setting, so it's only used when bitrate limiting is set. It would be nice if related options like this in the SC server settings could be grayed out or hidden when another makes it moot.

According to the LAME documentaion:


Noise shaping & psycho acoustic algorithms:
-q <arg> <arg> = 0...9. Default -q 5
-q 0: Highest quality, very slow
-q 9: Poor quality, but fast
-h Same as -q 2. Recommended.
-f Same as -q 7. Fast, ok quality


By default it's set at -q 9 in SC, I suppose, just to be safe, but I see very little difference in CPU usage on the server when set to -q 2. Using -q 0 on my server does show a bit more CPU.

Anyway... only relevant when bitrate limiting is forcing transcoding to Mp3. Most people only use this for remote streaming to a player off of their home network.

AndrewFG
2008-11-23, 09:22
The other reason is debatable, but I'll mention it, and hope the thread doesn't go off on a tangent. Some audiophiles claim that WAV sounds better than Flac (and some claim Flac sounds better than WAV, so it goes both ways). This shouldn't be the case, as Flac is lossless and will decode to exactly the same bits and bytes. Theories on why this might be the case generally speculate that the greater CPU activity needed to decode the Flac stream has a negative audible effect. Conversely, speculation as to why Flac might sound better than WAV is that the CPU and network electronics actually do less work handling the lower network traffic.

They sound exactly the same to me.

I notice that on Settings | Advanced | File Types | Apple Lossless, the dropdown selection box for FLAC offers "alac/flac" whereas the dropdown for WAV offers "alac".

Does this mean that when Apple Lossless is transcoded to FLAC it goes through first an ALAC processor and then a FLAC processor? Whereas when it is transcoded to WAV it only goes through the ALAC processor?

If so, then I would naturally assume that the simpler solution (via WAV) would be better. Any comments??

Also what happens at the player end? Is WAV transcoded to FLAC or vice versa? I may be a bit simple in the head (or I perhaps I am just an audiophile) but I would imagine that whichever end-to-end path has the fewer overall transcoding steps, would ultimately be the one that sounds better??

Phil Leigh
2008-11-23, 09:29
I notice that on Settings | Advanced | File Types | Apple Lossless, the dropdown selection box for FLAC offers "alac/flac" whereas the dropdown for WAV offers "alac".

Does this mean that when Apple Lossless is transcoded to FLAC it goes through first an ALAC processor and then a FLAC processor? Whereas when it is transcoded to WAV it only goes through the ALAC processor?

If so, then I would naturally assume that the simpler solution (via WAV) would be better. Any comments??

Also what happens at the player end? Is WAV transcoded to FLAC or vice versa? I may be a bit simple in the head (or I perhaps I am just an audiophile) but I would imagine that whichever end-to-end path has the fewer overall transcoding steps, would ultimately be the one that sounds better??

From a sound quality point of view, lossless is lossless and it doesn't matter how long the code path length is, the sound remains the same...

Phil Leigh
2008-11-23, 09:32
That's incorrect. It isn't a compression level, but a separate quality level. This is a LAME setting, so it's only used when bitrate limiting is set. It would be nice if related options like this in the SC server settings could be grayed out or hidden when another makes it moot.

According to the LAME documentaion:


Noise shaping & psycho acoustic algorithms:
-q <arg> <arg> = 0...9. Default -q 5
-q 0: Highest quality, very slow
-q 9: Poor quality, but fast
-h Same as -q 2. Recommended.
-f Same as -q 7. Fast, ok quality


By default it's set at -q 9 in SC, I suppose, just to be safe, but I see very little difference in CPU usage on the server when set to -q 2. Using -q 0 on my server does show a bit more CPU.

Anyway... only relevant when bitrate limiting is forcing transcoding to Mp3. Most people only use this for remote streaming to a player off of their home network.


I stand corrected! - I can't hear any obvious differences between the settings on a casual check.

JJZolx
2008-11-23, 09:39
I notice that on Settings | Advanced | File Types | Apple Lossless, the dropdown selection box for FLAC offers "alac/flac" whereas the dropdown for WAV offers "alac".

Does this mean that when Apple Lossless is transcoded to FLAC it goes through first an ALAC processor and then a FLAC processor? Whereas when it is transcoded to WAV it only goes through the ALAC processor?

Yes.


If so, then I would naturally assume that the simpler solution (via WAV) would be better. Any comments??

Better how? If you get no interruptions in playback then one is as good as the other. If you had a really really really slow server, then _maybe_ only decoding to WAV would be better.


Also what happens at the player end? Is WAV transcoded to FLAC or vice versa? I may be a bit simple in the head (or I perhaps I am just an audiophile) but I would imagine that whichever end-to-end path has the fewer overall transcoding steps, would ultimately be the one that sounds better??

At the player end Flac is decoded to WAV/PCM.

The trancoding doesn't alter the bits at all - nothing is lost. In any case, it can't hurt to try it streamed as WAV instead of Flac. If you connect using wired ethernet it will make very little difference in reliability due to bandwidth issues. If you use wireless and get dropouts, go back to streaming in Flac.

AndrewFG
2008-11-23, 09:54
From a sound quality point of view, lossless is lossless and it doesn't matter how long the code path length is, the sound remains the same...

Indeed lossless is lossless. No dispute on this truism.

But on the other hand if you ask the sound processing to jump through hoops on the journey from A to B then the more hoops you add, the higher the chances that something WILL get lost.

{ I hope you guys are not designers for nuclear power stations. Personally I prefer the main coolant feed to the reactor to be as short as possible, rather than making a detour round my back yard. }

Phil Leigh
2008-11-23, 10:14
Indeed lossless is lossless. No dispute on this truism.

But on the other hand if you ask the sound processing to jump through hoops on the journey from A to B then the more hoops you add, the higher the chances that something WILL get lost.

{ I hope you guys are not designers for nuclear power stations. Personally I prefer the main coolant feed to the reactor to be as short as possible, rather than making a detour round my back yard. }


I am a designer of VERY large scale computer systems, and I'm more than happy to state that lossless audio computer software doesn't behave like analogue electronics! :o). There is no direct equivalent of transfer loss or generation loss.

There is no "sound processing", just lossless audio data processing. This has been definitely proven many, many times. If you compare the bits from the CD to what comes out - no matter what lossless chain is in the way - the bits are the same.

Given an accurate rip and lossless data transmission to the DAC, the audiophile paranoia really starts at the DAC and everything beyond. everything upstream of the Squeezebox is irrelevant to sound quality, given the above caveats.

AndrewFG
2008-11-23, 11:04
I am a designer of VERY large scale computer systems, and I'm more than happy to state that lossless audio computer software doesn't behave like analogue electronics! :o). There is no direct equivalent of transfer loss or generation loss.

There is no "sound processing", just lossless audio data processing. This has been definitely proven many, many times. If you compare the bits from the CD to what comes out - no matter what lossless chain is in the way - the bits are the same.


Don't get me wrong. I don't dispute that lossless is lossless. The word "lossless" is a definition of meaning and it simply CANNOT be disputed...

I am not talking about theory, I am talking about practice. I am simply stating that, in real world systems, as you insert more "processing stuff" onto a lossless chain, you will eventually reach a level where things start to go pear shaped, and eventually the chain fails. e.g. the CPU can't handle the processing load, and has to drop or reschedule stuff in order to keep up; or the network has to drop packets.

Even with your VERY large scale computer systems, I bet that it is eventually quite possible to add enough overhead to the system, to bring it down. C'mon you know this yourself :-)

And when things like this do happen, the lossless chain becomes transformed into something that starts to look an awful lot like "lossy", where the only question is whether it becomes a total loss (the system freezes or crashes), a partial loss (dropped bits or packets), or a time loss (the data gets through eventually, but not in real time).

Phil Leigh
2008-11-23, 22:29
Don't get me wrong. I don't dispute that lossless is lossless. The word "lossless" is a definition of meaning and it simply CANNOT be disputed...

I am not talking about theory, I am talking about practice. I am simply stating that, in real world systems, as you insert more "processing stuff" onto a lossless chain, you will eventually reach a level where things start to go pear shaped, and eventually the chain fails. e.g. the CPU can't handle the processing load, and has to drop or reschedule stuff in order to keep up; or the network has to drop packets.

Even with your VERY large scale computer systems, I bet that it is eventually quite possible to add enough overhead to the system, to bring it down. C'mon you know this yourself :-)

And when things like this do happen, the lossless chain becomes transformed into something that starts to look an awful lot like "lossy", where the only question is whether it becomes a total loss (the system freezes or crashes), a partial loss (dropped bits or packets), or a time loss (the data gets through eventually, but not in real time).


Andrew,

We are talking about two different things. I'm talking about "lossless" in the sense that no data is discarded or altered in the software chain so that what is presented to the DAC is what was in the original source. This has been proven in practice (not theory) by using HDCD or DTS material which simply won't work properly if the bits are altered.

Yes, the software stack might be so deep that the CPU struggles and the systems slows to an unusable crawl. I say that's not lossy - it's broken. The music will eventually stutter and stop.

The ethernet protocols ensure network retransmission of lost/corrupt packets containing many bytes (individual bits themselves can't be "dropped" as that is not a unit that the computer deals in at an access/transport level). The buffer in the SB is quite big and will cater for a lot of packet retransmission for wi-fi purposes - again though, if the buffer empties prematurely or fails to fill this is broken, not "lossy".

Finally, there is nothing "real-time" about any of this (unlike a CD player). The entire process is asynchronous. Timing issues can only begin to arise downstream of the SB (e.g jitter).

I replied to your OP because I thought you were concerned that the software path length might affect "sound quality" and I've tried to explain that it doesn't. That is completely different to saying that running too much software on the server PC might bring the system to it's knees performance-wise.
Regards
Phil

pfarrell
2008-11-23, 22:54
Phil Leigh wrote:
> Yes, the software stack might be so deep that the CPU struggles and the
> systems slows to an unusable crawl. I say that's not lossy - it's
> broken. The music will eventually stutter and stop.

Flac was designed to be asymmetric on the processing load for
compression and decompression. You compress a given tune once, and play
it back lots of times, so flac takes a lot longer to compress, and is
fast to expand. It can be expanded real time on slow processors, such as
the one in a SB2


> Finally, there is nothing "real-time" about any of this (unlike a CD
> player). The entire process is asynchronous. Timing issues can only
> begin to arise downstream of the SB (e.g jitter).

That is why the gods made buffers.

And the reality and impact of jitter is still open to argument. For
them, go to the audiophiles section.


> That is completely different to saying that
> running too much software on the server PC might bring the system to
> it's knees performance-wise.

And if one checks the third party and unix forums, you will find that
nearly any PC made in this century is fast enough to be a SqueezeCenter
server.



--
Pat Farrell
http://www.pfarrell.com/

MrSinatra
2008-11-24, 05:52
I stand corrected! - I can't hear any obvious differences between the settings on a casual check.

just a data point:

when i rip to mp3 in EAC, i use -q 1

my computer encodes that fast enough. when i use -q 0 i see a really large slowdown in encoding speed, so i don't do it.

similarly, when i had bitrate limiting in effect for people on the net who were listening to my mp3s via my SC install, (been a while), i don't think i got good results with > -q 5

i might be off on the number, but the point is that i found SC to be somewhat sensitive to the quality level one set. (just my impression, i'm not sure if each session used the same settings)

i want to second jims excellent suggestion that it would be better to group and grey out related options that are dependent on other options.

MrSinatra
2008-11-24, 05:58
i forgot to mention, (duh)...

i also seem to recall that i could hear a difference of the -q 9 level vs higher ones via SC. now, i may be conflating things, but generally the rule as i recall seemed to be:

anything that went higher from 5 might stutter as the load on the server increased, and it also couldn't serve it then fast enough, whereas anything at 9, (and maybe 7 / 8) just didn't sound very nice. something of a distant memory and subjective.

nearly all my files are CBR 256 mp3s (-q 1 jstereo) to begin with, so that might explain the results a bit as well.

AndrewFG
2008-11-24, 12:25
Flac was designed to be asymmetric on the processing load for
compression and decompression. You compress a given tune once, and play
it back lots of times, so flac takes a lot longer to compress, and is
fast to expand. It can be expanded real time on slow processors, such as
the one in a SB2


Hmmm. Just a side comment: my OP was concerning the processing of Apple Lossless files, and it seems that the processing chain is as follows:

alac->wav->flac->transport->flac->wav->music

So even though the Transporter benefits from the asymetric flac->wav the PC has the hit wav->flac every time...