Yuly, try as I might I cannot reproduce any problems with 24/96kHz encoded FLAC. Maybe it is something specific to the FLAC you have.

Here is the metaflac info for the file I used for testing:
sample_rate: 96000 Hz
channels: 2
bits-per-sample: 24
total samples: 115200000
MD5 signature: dfdab758dd54a8433b78a622b5991280

Would you be willing to attach a FLAC to this bug that you experience the problem with? Maybe I can reproduce the issue with your file.

Here is my metaflac:
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 16 bytes
  maximum framesize: 17150 bytes
  sample_rate: 96000 Hz
  channels: 2
  bits-per-sample: 24
  total samples: 5448545
  MD5 signature: 2c2ed8d8a8c20390d79971c83ea1bb7a

The smallest file I have is 91MBytes. I have tried to cut a smaller one (1 minute of audio, approximately); but on this file I cant hear the distortion. On the original files I do hear it after 30 or so seconds; it sounds like lots of samples are missing; sometimes it slows down too. 
Can I attach a file that big?

Created attachment 1893 [details]
24/96KHz audio track

Comment on attachment 1893 [details]
24/96KHz audio track

looks i was able to attach it after all

Thanks for the file Yuly, I am now able to reproduce the distortion you describe with this file starting at about the 20 second mark. Investigating further.

Richard, it appears that this file has been compressed with FLAC 1.1.3 using the -8 option. If I encode the file with FLAC 1.1.4 using -8 I get the same issue. However if I encode with option -7 or lower I do not get the issue. It seems to me that the SB2/3 is running out of processing power. Is there a way I can check for that?

As a workaround I was going to suggest forcing SlimServer to transcode FLAC to WAV in the file types, but then I ran into Bug 4311.

I have not checked this track myself, but the description does sound like the Squeezebox is running out of processing power when using -8 compression with FLAC. Does disabling replay gain and/or not using a visualizer help as a work around?

Not using any visualizer does help, but only by delaying the issue unfortunately.

Displaying nothing gets me to about the 45 second mark in the song before the audio breaks up. Small VU about 25 and Spectrum Analyzer about 15.

This is most likely a duplicate of Bug 4562. However I am inclined to leave this one open since it refers to the SB2/3 and the other refers to the Transporter.

Yuly as a workaround you can do FLAC to FLAC transcoding. To do this you need to open C:\Program Files\SlimServer\server\convert.conf in a text editor and look for the lines:

flc flc * *
	-

and replace them with:

flc flc * *
	[flac] -dcs --skip=$START$ --until=$END$ -- $FILE$ | [flac] -cs --totally-silent --compression-level-0 -

and then restart SlimServer. You will lose the ability to scan and SlimServer will use more processor resources, but it does seem to get around the problem.

Thanks for the tip; I will try it. 
BTW, I re-coded the album with flac 1.1.4 level 6; the distortion is almost gone - but not completely:(

Would it be possible for Slimserver to somehow detect those high-rate files, and automatically apply flac-to-flac (or flac-to-wav, when the appropriate bug is taken care of) transcoding?

I have been working on decoder speedups which will be in the next release libFLAC, maybe that will help.  this particular problem is probably caused by too many multiply-accumulates (due to higher LPC order).  the current CVS code has fully unrolled loops in FLAC__lpc_restore_signal()/FLAC__lpc_restore_signal_wide() which may be faster.

Great news! I hope this will be encorporated in SB firmware, as soon as it's ready.

And thanks for FLAC, BTW:)

Richard: are we using the new FLAC code yet?

I have just gotten my SB (f/w 81) running and came across what sounds to be exactly this problem.
Any confirmation when the fix will be available?

We will look at this post-7.0

*** Bug 7569 has been marked as a duplicate of this bug. ***

Sean, I noticed that bug 4562 has been fixed for Transporter.  Could that fix also be applied to Squeezebox2/3 and Receiver?

(In reply to comment #18)
> Sean, I noticed that bug 4562 has been fixed for Transporter.  Could that fix
> also be applied to Squeezebox2/3 and Receiver?

Sean pointed out to me that the optimizations done to the Transporter firmware that in turn fixed bug 4562 are hardware specific and would not apply to the Squeezebox2/3 and Receiver.

On the SqueezeBox 3 I receive a similar distortion of recordings just bought at www.linnrecords.com.

The tracks do play fine on WinAmp 5.52 Reference FLAC Decoder v1.0beta6a. 

I will have to find out at Linnrecords what the (new, I have tracks of them that listen fine) FLAC settings are they use.

www.linnrecords.com
Arthur Pizarro - Beethoven Last three Piano Sonatas

Linnrecords has responded to my request with the following information: 

The version of the FLAC encoder is 1.1.4 (we have not upgraded to 1.2.1 since there are some backwards compatibility issues with 24bit files)

The only setting we use for the decoder is the default compression (level 5)

JoKi

Sorry folks, SB3 does not have anywhere near the CPU capacity to properly play back 96KHz flac. Even if the FLAC decoder were able to handle the data rate, we couldn't downsample it. Dropping every other sample as we do now is a terrible solution which transfers all the higher frequency energy into the audible range.

Originally we made it do this because we thought it would be "better than nothing" in the case where an SB3 is synched to a Transporter. Unfortunately it has created the impression that it is supposed to generally work.

I am closing this bug because it is impossible to fix. However, an alternate, acceptable means of playing 96KHz flac is actually possible, by resampling on the server. We have opened a new bug for that, #8327, if you would like to add yourself to it.