File-based audio playback - compressed vs. uncompressed

[AlexM]

Bob,

Yes, my previous tests were on CD rips to FLAC at 16/44, and played from the Logitech Media Server rather than directly from the SB Touch via USB memory stick.

Over the weekend, I plan to test
1) FLAC vs LPCM @ 16/44 from the SB Touch
2) Hi-res LPCM vs. FLAC at 24/96 from Logitech Media Server
3) Hi-res LPCM vs. FLAC from the SB Touch.

My Hi-res LPCM test files are 24/96 from Vinyl via my CJ PV-15 phono MC preamp, with A/D via EMU 0404 USB.

Regards,
Alex

[AlexM]

One concern I have relates to the symmetry of the encode/decode process with FLAC. There are slightly similar issues with lossy compression, such as MP3 and AAC, but the specifications of those compression/decompression systems are such that errors are allowed, though should be within reasonable limits. There different playback/systems could, in theory, give very slightly different results. Since such systems are designed to be lossy, this should be acceptable, given the applications. Thus if different playback systems are used there could be slight differences on the same source material, within tolerance limits.

For lossless systems the specifications must be such that there is no difference between different playback systems, and the original data should be replicated precisely by the decompressed data following a round trip.

I note that systems such as FLAC contain essentially at least a lossy encoder in the encoder, and a matching lossy decoder within the lossless decoder. Some lossless systems could even have lossy encoders and decoders in the encoder, and also in the decoder. It occurs to me that if these lossy components are not matched, that this will be a possible source of errors. Indeed, the arithmetic used in such internal components could also have an effect. I don't know how well FLAC encoder/decoders have been designed, but if, for example the lossy components use floating point operations, some consideration would have to have been given to accuracy issues. However, the lossy components may have been designed using integer arithmetic, which would presumably ensure consistency across different hardware systems. The point is that for a lossless system there can be no errors, not even small ones. Small errors could arise if internal lossy components are used without sufficient care, and could thus appear at the outputs.

I just don't know enough about how systems like FLAC and Alac have been designed at the implementation level to know how robust these "standards" are. Hopefully they are robust, but I'm not sure how confident we can be of that.

Dave,

You can read about FLAC encoder design at http://flac.sourceforge.net

The site says that all arithmetic operations are Integer to ensure that that they don't create rounding errors in encode/decode, and that only integer sample formats are supported. FLAC has a formal test suite, so it is quite robust, at least if the devices are using the reference implementations of the encoder/decoder. Even if they don't the lossless nature of the encoder/decoder can be verified. The FLAC encoder compresses the signal by approximating a simple polynomial function or using linear predictive coding. The residual error isn't lost or discarded - the residual from the modelling is encoded using a variant of Huffman encoding called Rice codes. Thus, the original values will be reconstructed perfectly by the decoder or not at all. To be doubly sure, the operation of the encoder can be verified by running the decoder in parallel and comparing the input and output with the -v option.

I am paraphrasing and simplifying the process greatly here, and any errors in the description are mine!.

Here is a section from the FAQ that is relevent to the discussion here.

How can I be sure FLAC is lossless?
How much testing has been done on FLAC?

First, FLAC is probably the only lossless compressor that has a published and comprehensive test suite. With the others you rely on the author's personal testing or the longevity of the program. But with FLAC you can download the whole test suite and run it on any version you like, or alter it to test your own data. The test suite checks every function in the API, as well as running many thousands of streams through an encode-decode-verify process, to test every nook and cranny of the system. Even on a fast machine the full test suite takes hours. The full test suite must pass on several platforms before a release is made.

Second, you can always use the -V option with flac (also supported by most GUI frontends) to verify while encoding. With this option, a decoder is run in parallel to the encoder and its output is compared against the original input. If a difference is found flac will stop with an error.

Finally, FLAC is used by many people and has been judged stable enough by many software and hardware makers to be incorporated into their products.

Cheers,
Alex

[AlexM]

P.S. my post above is definately my dullest ever.. sorry .

I do think it is worth understanding something about how FLAC works, if only to end the suspicion that it isn't really lossless!. Your data wasn't harmed in the making of this flac file.

[bobbasrah]

Bob,

Yes, my previous tests were on CD rips to FLAC at 16/44, and played from the Logitech Media Server rather than directly from the SB Touch via USB memory stick.

Over the weekend, I plan to test
1) FLAC vs LPCM @ 16/44 from the SB Touch
2) Hi-res LPCM vs. FLAC at 24/96 from Logitech Media Server
3) Hi-res LPCM vs. FLAC from the SB Touch.

My Hi-res LPCM test files are 24/96 from Vinyl via my CJ PV-15 phono MC preamp, with A/D via EMU 0404 USB.

Regards,
Alex

Sounds good Alex, and results should prove interesting as you will know the test pieces intimately...

It is disappointing that nobody is posting the problem with a different computer/DAC combo, since if it is indeed a universal truth as claimed, the power of the computer/OS/Player could be examined and quantified as a contributory element.

Shame, but for now, investigation of this issue is of necessity restricted to the Squeezebox.

Good luck in the tests

[sq225917]

Thank you Alex....Finally another difference noted....

Not conversant with SBT, but when trying to find out about it, came across a similar note on a review on the Logitech site from last December which contained the following-
"Having said that I noticed that due to incoming jitter from for my nas I could hear a difference in sound quality( same song) between FLAC ( 24b 96KhZ and PCM (24b 96KHz) . With PCM is was better then with Flac. The processing power in the Touch is likely not big enough to do this job right. I converted all my HD Flac music to HD PCM to overcome this problem."
Alex's situation seems similar.

The problem is that unless the guy has double blinded it, we don't know if what he says he hears, he really does, and his speculation about incoming jitter is just that-speculation. Does he provide the jitter measurements, no. Does he even tell you if the signal is coming via spdif, or Ethernet, because ethernet is unaffected by jitter as it's async. There's an awful lot of speculation and precious little proof. That's fine, as this is a subjective forum but one should fall into the trap of presenting subjective findings as anything other than opinion.

[AlexM]

The problem is that unless the guy has double blinded it, we don't know if what he says he hears, he really does, and his speculation about incoming jitter is just that-speculation. Does he provide the jitter measurements, no. Does he even tell you if the signal is coming via spdif, or Ethernet, because ethernet is unaffected by jitter as it's async. There's an awful lot of speculation and precious little proof. That's fine, as this is a subjective forum but one should fall into the trap of presenting subjective findings as anything other than opinion.

+1

A server cannot jitter ethernet packet data as it the stream doesn't contain any timing info. If there is an audible difference experienced, it isn't because of more or less jitter FLAC vs. PCM. I don't think that the CPU on the touch is underpowered as I see CPU utilisation of 12-14% playing 24/88Khz FLAC, including it running a terminal session and TOP!.

I think that in some ways an ethernet connection between PC and DAC is possibly a superior scheme to SPDIF/USB connection in that time domain information must be locally generated by the Player or DAC, with less external influences to cause jitter.

[AlexM]

Correction...

That is 12-14% playing a 24/88 FLAC with server decoding to WAV, and 20-27% with FLAC decoding on the SB Touch.

So there does appear to be more variability in CPU load when using FLAC over WAV, but this doesn't necessarily mean more jitter at the SPDIF output and the CPU isn't too busy.

[bobbasrah]

The problem is that unless the guy has double blinded it, we don't know if what he says he hears, he really does, and his speculation about incoming jitter is just that-speculation. Does he provide the jitter measurements, no. Does he even tell you if the signal is coming via spdif, or Ethernet, because ethernet is unaffected by jitter as it's async. There's an awful lot of speculation and precious little proof. That's fine, as this is a subjective forum but one should fall into the trap of presenting subjective findings as anything other than opinion.

I absolutely and totally agree
Problem is that the same critieria should apply throughout, and the reason for the thread itself is that precise absence of detail and proof which supports the opinion or claim as to the problem in the first place.

[Chops]

I've seen some concerns expressed over the processing power of the SBT, so I thought I'd do a little experiment.

First, my setup is Netgear ReadyNAS Duo with LMS -> SBT (with all Soundcheck mods applied except -k, buffersize 4000us) -> Chord QBD76 (with full (4 sec) buffering, although this doesn't seem to work on hi-res). 100Mbps wired Ethernet.

I tried a variety of music (all classical) of differing bit rates as you'll see below.

I used 'top' to measure CPU activity. Its fairly lightweight, taking only about 2% max CPU. I used 2 sample rates: 20 secs to get a rough average and 2 secs to try to observe peaks.

Please note that these are all observed so please don't take them as definitive. They are the best I could do quickly (I did take a number of samples of each though).

So the results:

• Beethoven Piano Concerto 5 'Emperor' - 1. Allegro - Emil Gilels, Philharmonia Orchestra, EMI Classics

16bit/44.1kHz

FLAC file downloaded to SBT as FLAC - 678kbps VBR

• 20 sec sample - approx 75-80% idle, 5-10% sirq
• 2 sec sample - min idle 71%, max sirq 12%

FLAC file converted to PCM on NAS and then downloaded to SBT as PCM - 678kbps VBR (converted to 1411kbps PCM)

• 20 sec sample - approx 75-80% idle, 10-15% sirq
• 2 sec sample - min idle 67%, max sirq 22%

• Beethoven Piano Concerto 5 'Emperor' - 1. Allegro - Artur Pizaro, Scottish Chamber Orchestra, Linn

24bit/96kHz

FLAC file downloaded to SBT as FLAC - 2467kbps VBR

• 20 sec sample - approx 25-40% idle, 30-50% sirq
• 2 sec sample - min idle 38%, max sirq 60%

PCM file downloaded to SBT as PCM - 4608kbps CBR

• 20 sec sample - approx 10-15% idle, 55-75% sirq
• 2 sec sample - min idle 0%, max sirq 80%

• Pergolesi Concerto Grosso no 12 'La follia' per archi e cembalo, I Musici, Fone Records

24bit/96kHz

FLAC file downloaded to SBT as FLAC - 3024kbps VBR

• 20 sec sample - approx 20-45% idle, 30-50% sirq
• 2 sec sample - min idle 0%, max sirq 95%

PCM file downloaded to SBT as PCM - 4608kbps CBR

• 20 sec sample - approx 5-20% idle, 55-75% sirq
• 2 sec sample - min idle 0%, max sirq 93%

• Mozart Symphony No. 38 in D major (‘Prague’), K.504 - I Adagio - Allegro - Scottish Chamber Orchestra, Linn

24bit/88.1kHz

FLAC file downloaded to SBT as FLAC - 2477kbps VBR

• 20 sec sample - approx 35-45% idle, 30-40% sirq
• 2 sec sample - min idle 21%, max sirq 50%

PCM file downloaded to SBT as PCM - 4233kbps CBR

• 20 sec sample - approx 10-20% idle, 60-70% sirq
• 2 sec sample - min idle 1%, max sirq 76%

One observation. The sirq-net-rx/0 process made up most of the sirq figure.

I don't feel qualified to comment precisely on the above. Broadly, however, the SBT CPU appears to struggle with hi-res PCM, but maybe its still OK. Is SqueezOs real-time embedded Linux and if so, is it designed to cope? Does its own buffering eliminate these problems?

I normally run my setup with FLAC->PCM conversion taking place on the NAS for 16/44.1 files and, through experience, use hi-res PCM files because the NAS struggles with the conversion. It generally sounds pretty good to me, although I haven't compared FLAC vs PCM on the SBT. One small issue is that I get a very small amount of 'crackling' on the Pergolesi track (above), but not on any other hi-res albums that I've noticed.

Chris

[Ali Tait]

If there is any sound difference due to processor use, would this not be shown up by encoding a track at different compression levels and comparing the result?