Bugzilla – Bug 3422
Wrong file format information
Last modified: 2008-09-15 14:39:24 UTC
I rip files from internet streams. I have a lot of files from the same stream, all of which are 128kb stereo mp3. They all show up that way whan properties are viewed with windows explorer or other tag readers. I don't know what kind of headers they actually have - I rip them with mplayer dumpstream. One of these shows silly information - File Length: 4,096 Bytes Bitrate: 32kbps CBR Sample Rate: 24.0 kHz It plays "correctly" although the elapsed time is all wrong. I can send you the beginning of this file, which displays the same effects. (I have rebuilt the data base after removing the Cache sub-directory)
Created attachment 1243 [details] Beginning of file which displays this problem
I continue to see this in the latest 6.3 builds. Slim gets the file facts wrong, and thus plays only part of the file. In a recent case, winamp (for example) sees: Size: 86546560 bytes Header found at: 2109 bytes Length: 3606 seconds MPEG 1.0 layer 3 192kbit, 138250 frames 44100Hz Stereo CRCs: No Copyrighted: No Original: Yes Emphasis: None While Slim sees: Title: Haas_06_06_02_14_00_KAMU Artist: No Artist Album: No Album Genre: No Genre File Format: MP3 Duration: 480:48 File Length: 86,546,560 Bytes Bitrate: 24kbps CBR Sample Rate: 12.0 kHz ID3 Tag Version: ID3v2.3.0 A clear and rescan does not make any difference. Nor does removing the Cache directory. So its something about the file. I will save it in case you want it.
Marc - can you upload the entire file to: ftp://electricrain.com/incoming/ ? Thanks.
Uploaded file. I still see same bogus info with the 6-13 build of 6.3 The origin of this is an mplayer -dumpstream of an internet radio station.
Thanks. FWIW, iTunes also sees bogus information.
Just to be clear. I rip this station every weekday, and almost NEVER see this problem. The particular file is anomolous in some way.
Marc - that file has a bogus first frame. Some software (such as Winamp) will read past it. I'm hesitant to change anything in our MP3 reading code for this one file that could have a potentially large performance impact. frame offset: 2056: 24Kbps/12KHz frame offset: 2736: 192Kbps/44.1KHz frame offset: 3363: 192Kbps/44.1KHz frame offset: 3990: 192Kbps/44.1KHz frame offset: 4616: 192Kbps/44.1KHz My suggestion is to find some software that can trim the first frame out of there, or just zero it out in a hex editor up to the next offset.
Fair enough. Sorry you had to spend time on this. I know that ripping with dumpstream is risky, but it sure beats transcoding twice in time and quality.