After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 152688 - [PATCH[mad/typefind] doesn't support completely broken mp3 files
[PATCH[mad/typefind] doesn't support completely broken mp3 files
Product: GStreamer
Classification: Platform
Component: gst-plugins
Other Linux
: Normal normal
: 0.8.8
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 143553 152934 152965 163191 163469 (view as bug list)
Depends on:
Blocks: 138435
Reported: 2004-09-15 06:08 UTC by Keith Lea
Modified: 2005-01-27 10:29 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8

proposed fix (9.01 KB, patch)
2005-01-26 15:58 UTC, Ronald Bultje
none Details | Review

Description Keith Lea 2004-09-15 06:08:13 UTC
There are many files which it appears that GStreamer won't load on my computer.
They are listed at
Comment 1 Ronald Bultje 2004-09-15 07:22:51 UTC
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?
Comment 2 Keith Lea 2004-09-15 15:05:57 UTC
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.
Comment 3 Ronald Bultje 2004-10-01 11:41:27 UTC
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.
Comment 4 Ronald Bultje 2004-10-01 12:00:16 UTC
*** Bug 152934 has been marked as a duplicate of this bug. ***
Comment 5 Ronald Bultje 2004-10-01 12:00:33 UTC
*** Bug 152965 has been marked as a duplicate of this bug. ***
Comment 6 Keith Lea 2004-10-01 17:05:09 UTC
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.
Comment 7 Ronald Bultje 2004-10-02 13:39:25 UTC
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...
Comment 8 Ronald Bultje 2004-10-29 11:50:27 UTC
*** Bug 143553 has been marked as a duplicate of this bug. ***
Comment 9 Ronald Bultje 2005-01-07 10:02:43 UTC
*** Bug 163191 has been marked as a duplicate of this bug. ***
Comment 10 Ronald Bultje 2005-01-09 21:18:25 UTC
*** Bug 163469 has been marked as a duplicate of this bug. ***
Comment 11 Ronald Bultje 2005-01-26 15:58:40 UTC
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.
Comment 12 Ronald Bultje 2005-01-27 10:29:26 UTC