Bugzilla – Bug 2175
SlimServer fails to play selected mp3 files.
Last modified: 2009-09-08 09:23:49 UTC
(Full details at URL provided) Configurations include both Slimserver running on a Windows server, and a ReadyNAS 600, with verions 6.1.1 on either, with the music in question both local and on networked locations. Of couse, not having a SB2 yet I'm using the latest version of softsqueeze. What happens is some songs simply refuse to play through the Slimserver. This includes songs within a single album, some track work fine, others just refuse to play (it's not like they "play" but there is silence which is what I've been able to see occuring in my searches of the forums). I've tried clearing and re-indexing the collection, but no change. Of course these .mp3's all play fine through WinAmp and WMP9/10 and Musicmatch, so.... I'm real confused. Link to sample problem MP3: http:\\www.openwar.com\01%20-%20Not%20Gonna%20Get%20Us.mp3 I can provide others upon request. Platform/Servers tested: ReadyNAS 600 and Windows Server 2003 Clients: Windows XP Pro (SoftSqueeze 2.0b11). SB2 on order, can do further testing when it arrives.
Created attachment 846 [details] Testcase #1 mp3
This comes back from MP3::Info: Couldn't find MP3 header (perhaps set $MP3::Info::try_harder and retry) Oddly, I can see the header with a hex editor. MP3::Info is getting something of a header, but seems to be failing a sanity check on a seek offset. also fails with 6.2 betas, so I'll mark that as the version.
ah, seems it IS finding the header, but the initial mp3 validation fails becuase mode = 0 and mode_extension=2. the test for is_mp3 fails if ($h->{mode_extension} != 0 && $h->{mode} != 1). Commenting this case out of MP3::Info::_is_mp3 seems to allow the file to return at least what looks like valid data. In theory, mode_extension is supposed to be only applicable when mode is 1 (Joint Stereo). This file comes up as Stereo (mode 0). The other applications must just ignore the mode_extension in this case, whereas MP3::Info considers it a corruption. re: http://www.mp3-tech.org/programmer/frame_header.html does your ripper have settings for Joint Stereo vs Stereo, or the Intensity- or MS- Stereo extensions? Dan, do you know if this check was there just because of spec or some known failure mode?
I think that this test is overly aggressive and probably not necessary. I recommend removing that line from Info.pm.
just to be sure we're talking about the same place, this is in the CPAN MP3::Info, not Slim::Music::Info.
lines 1102-3 in CPAN/MP3/Info.pm: || ($h->{mode_extension} != 0 && $h->{mode} != 1)
cool, thanks I know we have an inside guy for CPAN, but i do still always think twice before jumping on changes to those modules :) I'll try out this test case, and the downloaded file with the change to make sure playback isnt affected. I can make the change tonight if no one else gets to it sooner.
Dan handles the patches back to CPAN. This fix (I think) is safe for us, not sure if they'll accept it. Dan?
Audigrabber (http://www.audiograbber.com-us.net/) is what I use for ripping with the LameMP3 codec (http://jthz.com/~lame/) which does have settings for mono/joint stereo/stereo/dual stereo encoding. I use the same settings for ripping all of my CD's.
I should have also mentioned that I use "Stereo" not "Joint Stereo", so the fact that it's reporting as mode 0 (Stereo) is correct.
I expect that if audiograbber is writing the extension setting regardless, then any tracks you rip wiith the joint stereo setting will play fine. I've tried to look up any info as to what other systems might do as far as possibly ignoring the extension when the mode is not joint stereo, but I've not had any luck. Obviously software players like winamp and wmp are clearly letting it slide since those play the supplied file just fine. If slimserver is changed to ignore this condition, then the files play fine as well.
committed a fix a change 4417. Dan, I'll leave this up to you whether it is worth forwarding back to the author or leaving as customised.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.