GNOME Bugzilla – Bug 152688
[PATCH[mad/typefind] doesn't support completely broken mp3 files
Last modified: 2005-01-27 10:29:26 UTC
There are many files which it appears that GStreamer won't load on my computer. They are listed at http://gee.cs.oswego.edu/~keith/keep/badsongs/
I just tried the file from Garbage. The MPEG version reported is '1' (which is illegal; 0 = MPEG-2.5, 1 = reserved, 2 = MPEG-2, 3 = MPEG-1), and the layer reported is '4' (which is illegal as well, this can range from 1 to 3). So we might be dealing with some updated MP3 extension here. My first thought was that it might be some AAC-enabled file, but faad doesn't like the file either: ERROR (0x9247ee0 - 304231:17:48.730384000) default( 4673) gstfaad.c(563):gst_faad_chain:<faad0> Failed to decode buffer: Channel coupling not yet implemented ERROR: from element /pipeline0/faad0: Could not decode stream. ffdec_mp3 and mad (hardcoded in a pipeline) will both somewhat play the stream, but with lots of hickups and beeps. With what encoder were those files encoded? Are there any (Linux-based) applications that do eat those?
My disk was corrupted, and I recovered the files from raw FAT32 data. XMMS plays all of them, and mplayer plays all but Free Fallin by Tom Petty.
How does it play them? I tried with mad (which is a damn good decoder) and got little more than crackling noise with a bit of sound here and there. I don't call that a valid file at all, and don't see it as wrong behaviour that it fails to play them.
*** Bug 152934 has been marked as a duplicate of this bug. ***
*** Bug 152965 has been marked as a duplicate of this bug. ***
If you don't think it's wrong behavior to fail to play them, then I can re-file this as an RFE. I think it will be frustrating to users when Windows (Winamp, WMP) plays files that Linux (Rhythmbox, Totem) won't play, and I think it needs to be fixed.
No, not necessarily "right". I'm basically throwing bugs together because they do the same thing, and I'm trying to give you an idea why we fail. I'm not saying that it's right to fail, however. Our goal is not to make a media engine that checks all files for standard compliance and only play those that work. We want to play any file out there. However, it will take some effort before all those "broken" files play. I thought about this problem yesterday, and came up with the following ideas: * instead of searching for valid mp3 frames after the id3 header, search in the middle of the stream. * search for valid mp3 frames at random points in the stream (2-3 positions, e.g. start, halfway, end) * ... But like I said, this will not be fixed right away...
*** Bug 143553 has been marked as a duplicate of this bug. ***
*** Bug 163191 has been marked as a duplicate of this bug. ***
*** Bug 163469 has been marked as a duplicate of this bug. ***
Created attachment 36557 [details] [review] proposed fix This patch adds a 'id3demuxbin'. It is a bin which consists of id3demux ! typefind. All typefind code can be removed from id3demux (didn't do that yet, it's more like a proof-of-concept), and id3demux will support all typefinding functions in exitance, even the ones needing to support broken mp3s such as all the ones in this bug report. I've tested three, and they all started working with this patch.
Applied.