FLAC replay through a Squeezebox

Hi Jochen,

I have noticed the same thing with my Sonos.

I rip using EAC which allows the level of Flac compression to be easily adjusted. After experimentation I find the least Flac compression (level 0) which results in larger files sound a lot better and very similar to wav. There are definately CPU issues decoding Flac on these types of devices.

I now keep both Flac and wav versions of all rips. I generally play wavs on the Sonos and Flacs on PCs around the house.

Graham

quote:

Decoding FLAC is too demanding on Squeezeboxes CPU and in order to keep pace with the music it discards unimportant data, producing a lossy output. WAV on the other hand means minimal decoding for the CPU, so this works fine.

I doubt its discarding data - more processing overhead so more demands on the PSU and possibly more EMI inside the device resulting in more jitter on the output.

James

quote:

Originally posted by james n:
I doubt its discarding data - more processing overhead so more demands on the PSU and possibly more EMI inside the device resulting in more jitter on the output.

James

You are probably right: processing load affecting jitter sounds like a better explanation, may it be caused by EMI or through some other mechanism. Regarding the price of a Squeezebox one should not expect too much.

For me the options currently are:
- Stay with the Squeezebox and feed it with WAV
- Stay with the Mac Mini
- Demo another digital streamer


Thanks
Jochen

I've had both solutions. Orginal SB, SB duet and controller and now Mac mini. I prefer the Mac solution - iTunes is more flexible than Squeezecentre (for me anyway) and controlling iTunes via the remote app on an iPod touch / iPhone is much nicer than via the controller.

James

quote:

Originally posted by james n:
I've had both solutions. Orginal SB, SB duet and controller and now Mac mini. I prefer the Mac solution - iTunes is more flexible than Squeezecentre (for me anyway) and controlling iTunes via the remote app on an iPod touch / iPhone is much nicer than via the controller.

James

Perhaps I'll give iTunes/Remote a try. Usually I don't like iTunes because it has no support for FLAC.

There is also an iPhone app for the SqueezeCenter: iPeng. IMO it does the basic things and is much more readable than the Squeezebox display at the other side of the room.


KR
Jochen

One thing to check is that your SqueezeCenter is not configure to transcode FLAC to MP3. Just a thought.

quote:

Originally posted by JYOW:
One thing to check is that your SqueezeCenter is not configure to transcode FLAC to MP3. Just a thought.

Transcoding to MP3 is disabled, I checked that. And the Mac Mini sounds great with the same stream, so it can't be MP3. I think the hardware makes the difference.

Jochen

As a quick test try re-ripping a few tracks with flac level 0, which is least compression.

This will make it easier for the Squeezebox to decode in real-time. Worked with Sonos so should help.

Graham

Decoding FLAC is not the problem here.

The whole beauty of FLAC is that it is among the fastest and easiest codecs to unpack. It was developed with this in mind. FLAC puts all of the effort into the encoding process.

Encoding though is another thing. Compressing to FLAC is extremely resource intensive. Even on the fastest computers it will bog things down a bit.

Ripping to FLAC in EAC is criticized for not being as fast as a shit burst mode rip in iTunes. This encoding stress is one of the culprits.

quote:

Originally posted by Graham Russell:


I now keep both Flac and wav versions of all rips. I generally play wavs on the Sonos and Flacs on PCs around the house.

Graham

Why is this Graham? Why not just use the WAVs for everything? Why use the FLACs at all? Especially considering you think they sound better.

thx
-p

quote:

Originally posted by pcstockton:
Decoding FLAC is not the problem here.

The whole beauty of FLAC is that it is among the fastest and easiest codecs to unpack. It was developed with this in mind. FLAC puts all of the effort into the encoding process.

Encoding though is another thing. Compressing to FLAC is extremely resource intensive. Even on the fastest computers it will bog things down a bit.

Ripping to FLAC in EAC is criticized for not being as fast as a shit burst mode rip in iTunes. This encoding stress is one of the culprits.

PC I get what you're saying but there are no streaming constraints on encoding even though more difficult. It should not factor into the playback after it becomes a file. My guess is level 0 encoding is simply throwing away 0s in the packets without any other bit rearranging or worying about getting every last one, making it very easy to rebuild. I can see this helping.

I'm pretty sure the sonics on playback are not a PS issue but has more to do with buffers and processing. From what I've read, it takes 6 or 7 times as long to encode at level 8 vs level 0 yet you only save less than 3 or 4% of file size. Seems a poor trade. Graham's observations make a lot of sense to me and perhaps he keeps both type files for the same reason you FLAC, attached tags.

It is also important to note that while the higher compression rate takes more processor time to encode, there is NO difference in the processor time it takes to decode FLAC files of different compression rates. The higher compression settings are a one-time expense for smaller file sizes.

From Josh,

A good oversimplification is that during compression, many different algorithms are tested to try to model the data. The higher the compression level, the longer it searches for a good algorithm--usually resulting in a more efficient modeling of the data (hence a smaller file size). When the compressed file is written, that algorithm is written into the file as well--to decode, simply apply the algorithm. All the algorithms, regardless of compression level, are stable and relatively computationally cheap; all the work is done upfront during encoding trying to find that ideal algorithm.

That is FLAC.

That's interesting. But to take that long, it sounds as though it may be changing on the fly like VBR which could effect things on playback. If not it would start slow and then fly. I really don't know and understand what you're saying but I always go with observation over theory and try to sort out why as opposed to denying it could happen.

quote:

Originally posted by Graham Russell:
As a quick test try re-ripping a few tracks with flac level 0, which is least compression.

This will make it easier for the Squeezebox to decode in real-time. Worked with Sonos so should help.

Graham

My FLACs have level 5 compression. Following your suggestion I encoded some classical music files as WAV, FLAC level 0 and level 5. All randomly through the Squeezebox into the SuperNAIT DAC.

I did not do a strict blind listening test. My impression was that in most cases, when the music sounded more open and relaxed, it was either WAV or sometimes FLAC level 0, almost never level 5. On the other hand, when the music lacked openness it was often FLAC level 5 and sometimes level 0 or even WAV. There might be a trend, but it is not statistically valid.

However, when listening the same music through the Mac mini it made clearly more fun than the Squeezebox, regardless of the format.

I'm still puzzled if/how this can be. Are not all digital sources created equal?

I think I will listen to the Mac Mini from now on, until perhaps Santa Claus has a Linn DS for me.


Kind regards,
Jochen

quote:

Originally posted by jfritzen:
Are not all digital sources created equal?

the EXACT same process occurs for decoding (playing), given any level of FLAC compression. As was stated above, the ONLY difference between higher compression and not, is the time it takes to find the best algorithm in the encoding (ripping) process. Upon playbakc they are all handled the same. The played doing the decoding does not know what level it is. It simply applies the algorithm and decodes the FLAC.

you simply cannot hear a difference between levels of FLAC. impossible. To do so would be by sheer chance.

Are you telling me you were NEVER ONCE wrong on guessing the levels or WAV files? Not once? I doubt it, unless you only performed the test 3 times.

Try this.... Try to guess randomly which of the three files are playing (WAV, FLAC0, FLAC5), write down you results.

Then do it with your preamp on mute. Write down your answers.

I would bet you are correct about the same amount whether you listen to the music or not.

People tend to only remember positive results of experiments and not the false ones.

quote:

Originally posted by pcstockton:
you simply cannot hear a difference between levels of FLAC. impossible. To do so would be by sheer chance.

This may be the theory but it is not the case with Sonos and perhaps Squeezebox too.

I have done extensive listening tests and there is a clear audible difference between compression level 5 and level 0.

On a PC with more processing power I can't hear any difference between compression levels.

I wish this was not a problem with Sonos but there are obviously hardware issues which affect real-time decoding and playback.

quote:

Originally posted by Graham Russell:
there is a clear audible difference between compression level 5 and level 0.

I simply do not buy it.

Oh well, to each their own fantasies.

Are you people not understanding that there is NO DIFFERENCE in how any FLAC file is DEcoded, regardless of compression level? Do you understand how FLAC works? This is decidedly not like a VBR MP3. The only similarity between the two is that they are smaller than a constant bit rate codec (CBR, WAV).

Every decoding of a FLAC file is done the exact same way, applying an algorithm to the data. This algorithm is no more no less intensive or "different" given the compression rate.

In the end though it really doesn't matter. Take the flat earth principle, or any other tenet for that matter, to its most extreme logical conclusion and you find utter nonsense.

-Patrick

I really don't care how flac works. There is clearly a processing issue decoding different compression levels on Sonos.

quote:

Originally posted by js:
That's interesting. But to take that long, it sounds as though it may be changing on the fly like VBR which could effect things on playback. If not it would start slow and then fly. I really don't know and do understand what you're saying but I always go with observation over theory and try to sort out why as opposed to denying it could happen.

There, fixed it so no misunderstanding.

I'm perfectly willing to believe Graham regardless of theory. VBR also has the exact same algorithm on playback as CBR but I always opt for CBR. No one can tell you what you can't hear.

quote:

Originally posted by pcstockton:
Are you telling me you were NEVER ONCE wrong on guessing the levels or WAV files? Not once?

No, I said the opposite: I was wrong about the file type sometimes. I think there might be just a trend towards WAV sounding better than high level FLAC on the Squeezebox.

However, the difference between FLAC on Mini and Squeezebox was quite clear IMO, and I don't have an explanation for this.

quote:

Originally posted by pcstockton:
Are you people not understanding that there is NO DIFFERENCE in how any FLAC file is DEcoded, regardless of compression level? Do you understand how FLAC works? This is decidedly not like a VBR MP3. The only similarity between the two is that they are smaller than a constant bit rate codec (CBR, WAV).

Hi Patrick,

I agree that FLACs are bit perfect. Using MD5 checksums on a Mac command line:

# Taking checksum of a WAV file
bash-3.2$ md5 "Die Fledermaus.wav"
MD5 (Die Fledermaus.wav) = 3c635f44cdc9445e58c580bf5e384ecc
# Encoding and decoding a level 5 FLAC, taking checksum
bash-3.2$ flac -cs -5 "Die Fledermaus.wav" | flac -dcs - | md5
Die Fledermaus.wav: WARNING, cannot write back seekpoints when encoding to stdout
3c635f44cdc9445e58c580bf5e384ecc

Both checksums match as they should. But are FLAC decoders perfectly uniform regarding the timing?

As far as I understand it, a FLAC encoder takes a bunch of samples, fits a curve to the samples, encodes the difference (the residuals) and puts everything into a frame or subframe, followed by the next bunch of samples. The number of fitting parameters determines the order of the fitting. When I specify 'level 5' this means a maximum order of 8, but each subframe has its own order. One can analyze a FLAC with 'flac -a' and create a histogram how the subframes are distributed:

bash-3.2$ flac -cs -5 "Die Fledermaus.wav" | flac -acs - | awk '/subframe/ {print $4}' | sort | uniq -c
Die Fledermaus.wav: WARNING, cannot write back seekpoints when encoding to stdout
2 order=1
308 order=2
1109 order=3
496 order=4
948 order=5
1096 order=6
1554 order=7
4149 order=8

There is a considerable number of frames with order=8 but also with order=3. Its reasonable to assume that larger orders should take longer time during decode, having to do more arithmetic. Decoding FLAC is fast, but some subframes could even be faster to decode than others. This depends on the music data and the maximum order.

So, I would not claim that there is no difference in how any FLAC file is decoded. Can this lead to audible jitter? I really can't tell.

Don't get me wrong: I like FLAC, because it is an open, compact, lossless and versatile format. Otherwise I would not have committed myself to rip all my CDs to FLAC.


Kind regards,
Jochen

Great post. Thanks. Any idea how much that differs with level 0? Will the maximum order be reduced to 3?

Seems to me that if there's even a possibility of level 0 sounding better on playback regardless of reason, it should be used. The encoding time is reduced by a factor of at least 2 and the space lost is only about 3%. A file reduced to 65% size becomes 67%. That's neglegable storage in today's world.

I agree with pcstockton for the simple reason that he is stating the facts, there is nothing to discuss really, there is no difference what so ever, and if you think that you hear any difference it is only in the head.

If jfritzen's model is correct and there may be 5 less orders to decompress on playback at level 0 than at level 5 then even though it's the same algorythim, it will only need to use instructions for 3 orders of decompression instead of 8. It may or may not be audible in various setups but it's not the same even with the same decoder. A fact though correct may not be the entire story. More facts may be needed to get a full picture.

quote:

Originally posted by js:
If jfritzen's model is correct...

Do you mean, "if its comprehensible? What the hell was all that supposed to mean?

Anyway.... Its neither here nor there. I personally cannot hear the difference, and to be honest, I cant even remember how I have EAC set-up to compress.

I dont know how you could ever relax and listen when the level of FLAC compression is audible to you. Seriously.... Doesn't every single barometric pressure change affect your listening then? I can imagine it now, when my neighbor stands out side on their porch, i can hear a decrease in system performance.

If you think you can hear the difference between levels of FLAC compression, can you hear the difference between a V0 and a 320? That should be an easy one. Of course you would hear the difference between a new NAPSC and an older one. And you would also be able to hear the exact and precise effects of jitter in any system. When it occurs you would open your mouth and a print-out with graphs and formulae would pop out.

whatever........