Bugzilla – Bug 2527
Some MP3s do not play (hang at start)
Last modified: 2008-12-18 11:38:58 UTC
The MP3s in question play on xmms and on SoftSqueeze, but they do not play on a real SB2 with wired ethernet. The song title appears, but no audio is generated, and the elapsed time does not advance. In random play mode, the next song in the playlist (if playable) will eventually start to play, but the title of the bad one is left, at least for a while. I am on firmware v. 26. I will attach one of the files that show this problem.
Created attachment 1003 [details] This MP3 file will not play on the hardware SB2
have you tried this with fw27 and the latest 6.2.1 nightly build? If not, please do so.
I just verified that the problem still exists in the latest nightly: 6.2.1 / fw27. -Joe
Joe: What tool did you use to encode this MP3? I've never seen a file refuse to play this way. Also, how many files do you have that exhibit this behavior?
It seems that all the files from my Pink Floyd "Meddle" album rips do this - so this could be because of some particular settings when they were encoded (they were encoded a while back, so I do not remember). I have not found others in my library that do it, but I have not tested every file. But since these don't work on SB2 but work on other MP3 players, it must be tripping on some SB2-specific bug. I cannot see anything special about the tags or other attributes of the MP3s. I selected the file I attached because it was the smallest MP3 on the album. -Joe
Subject: Re: Some MP3s do not play (hang at start) Ok, thanks. I cannot get this to play on SLIMP3, Squeezebox1 or Squeezebox2/3. (They each have _very_ different MP3 decoders.) QuickTime and Audion also wouldn't play it, but iTunes, VLC and RealPlayer would. The only thing that that I noticed (not having torn apart the bitstream) was that iTunes indicated "Volume: +11.9dB", which I've never seen, but didn't have a value for the "Sound Check" gain. This is going to require a bit more detailed analysis of the bitstream to find out what's happening.
I have anaylsed the attached mp3 file using mp3check (http://jo.ath.cx/soft/mp3check/mp3check.html). This file was not correctly encoded, as the header crc values are invalid (all zero's). By disabling the header crc check in the firmware the file does play correctly. Looking around the web it looks like several mp3 players do not check the header crc is valid when playing a file. I will disable this check in the next firmware release so similar files will play ok.
This bug is fixed in firmware 56. It is currently undergoing internal testing. You will be notified again when it is made part of a nightly release.
I apologize; I've been slow in adding this notification to some of the bugs. Please ignore it if you've already tried the new firmware. This bug fix is now available in the nightly Slimserver release. The release is available from: http://www.slimdevices.com/dev_nightly.html If you prefer to wait for the next official release, you will be notified when it occurs. You'll need to install the new version of Slimserver, and then force your Squeezebox to upgrade its firmware by holding down the 'Brightness' button on the remote control until the firmware upgrade process begins. If you are still experiencing this problem after upgrading your affected players to the new firmware, please reopen the bug.