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]
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.