Bugzilla – Bug 4562
96/24 flac issue with the transporter
Last modified: 2009-09-08 09:18:42 UTC
Hi, while moving more and more 96/24 music into my online music library i found an album with tracks - after beeing converted to flac - the transporter has problems playing. symptom: dropouts/stutter, eventually the transporter crashes/reboots (happened at least 3 times)... observations: - bandwidth should be no problem as the uncompressed wav file plays fine. - 96khz flac without tags plays much better (*) - 48khz (downsampled) flac with & without tags plays fine - 96khz flac with & without tags plays fine with fb2k - frequency analyzer shows high volume above 25khz - same problem on the analog or digital output (*) my guess: removing the artist and album tag frees some cpu cycles on the transporter previously used for scrolling...disabling the VU-meter seems to improve the situation even more. One more thing supporting my CPU guess: flac files encoded with -0 have better results compared to those compressed with -8. Thanks to flac 1.1.3 reencoding without loosing any tags works like a charm. Is there a way to get the cpu utilization from the tr/sb? Something like top? ;-) SlimServer Version: 6.5.1trunk (a few days old), no transcoding Transporter firmware: 24, VU-meter, album + title scrolling I'll email support@slimdevices.com how to download one of these flacs. Any idea what's so special about this track? regards, Markus P.S: I really love playing all those other 96/24 files - thanks for this feature!
Created attachment 1730 [details] 96/24 file sent in by bug reporter
Just tried the latest firmware 26 with the same results. Has anybody verified this behavior? Any hints I can follow to narrow down this problem? thanks!
*** Bug 4610 has been marked as a duplicate of this bug. ***
Ross, could you try to reproduce, pls
I was able to reproduce the stuttering without a problem, but I didn't see any crashing. Firmware 27 SlimServer 6.5.1 on Ubuntu 6.06.
confirmed: no crashes anymore (but still stuttering) Firmware 27 SlimServer 6.5.2_svn on Debian 3.1
Richard I'm going to assign this one to you. Let me know if there is anything I can do to help.
After a few months I'd like to ask if there's any hope for progress? ;-) Is https://bugs-archive.lyrion.org/show_bug.cgi?id=4886#c12 a possible solution? regards, Markus
If possible it would be ideal to look at this bug before the SC 7.0 release. I wonder if transcoding to WAV would be a workaround?
thanks for bringing this one back! I'd really appreciate it as i transcode to flac-compress-level-0 at the moment. therefore support for seeking is not available - and a few flac files have playback problems nevertheless. and while you are it: any chance for full & native 88.2/24bit support? (#4712) :-)
Sean: do your recent changes fix this?
have not tested this case yet. If it is fundamentally a cPU overload condition then it should be rsolved in the new branch as I've freed up a ton of cycles. However, this case probably warrants further investigation if it also causes a crash. Maxing out the CPU should not trigger a crash...
Fixed in trunk 17060 / firmware 40
confirmed! thanks a lot
Sorry if I'm posting this in the wrong place, but: I have a 24/96 FLAC file that my Transporter is having problems with; I get noise and pops shortly after playing. The FLAC is encoded at level 8; encoded at level 4, the track plays fine, and it plays fine decompressed to WAV. I just don't want to have to reencode my FLAC library... I would provide a sample of the file, but it's quite large, and I've tried twice now to break it into smaller chunks and the smaller chunks don't have the problem. I suppose I could burn the track to CD and send it in for analysis :)
(In reply to comment #15) > Sorry if I'm posting this in the wrong place, but: > > I have a 24/96 FLAC file that my Transporter is having problems with; I get > noise and pops shortly after playing. David, are you running firmware V.40? This bug is believed to be fixed in V.40 so if you are still seeing problems after upgrading, I will need to get a sample file from you.
Seems to be fixed, thanks!
Changing fixed target to 7.1 as FW 40 will be released then, not in 7.0.1
I've added some comments in #4886 realizing that the same problem seems to be addressed here. This problem seems to be resolved for the squeezebox v3. Now that there is a resolution for Transporter will this issue likely also be addressed for the SqueezeBox? In this specific case the tracks are not created by me but by record company Linn Records therefor I cannot influence the way these tracks where created.
These optimizations would not be applicable to SB3, and SB3 does not support 24/96 anyway. The only reasonable solution would be to add support in Squeezecenter for a correct downsampling algorithm.
Thanks Sean, I was not aware of these limitations on the SqueezeBox. It is not stated in the documentation, website, nor FAQ. The custhelp system simply states: "Yes, the Squeezebox (v2 and 3) and the Transporter include built-in support for FLAC audio in the firmware. For older models of Slim Devices players, FLAC is still supported by either decoding to raw PCM or re-encoding as MP3." What would you suggest me to do? Jo
Johannes, the supported sample rates are listed on each of the products' web pages. Squeezebox can play 24/44.1 and 24/48, and Transporter can additionally play 24/88.2 and 24/96. http://www.slimdevices.com/pi_squeezebox.html
OK, I rest my case. What confused me is that on my SqueezeBox 3 a 24/88.2 FLAC stream plays without a problem. (!) Maybe the text should be extended with 24/44.1 24/48 and 24/88.2 only.
*** Bug 8615 has been marked as a duplicate of this bug. ***
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.