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 153004 - [typefind] can't identify mp3 file with one single mpeg frame
[typefind] can't identify mp3 file with one single mpeg frame
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Low normal
: 0.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2004-09-18 15:02 UTC by Stephane Loeuillet
Modified: 2006-02-07 16:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8

mp3 distributed with id3lib (731 bytes, audio/x-mp3)
2004-10-02 14:20 UTC, Stephane Loeuillet
log from typefindfunctions:5 (19.25 KB, text/plain)
2004-12-17 00:04 UTC, Ronald Bultje
crude patch (1.65 KB, patch)
2006-02-06 20:17 UTC, Tim-Philipp Müller
committed Details | Review

Description Stephane Loeuillet 2004-09-18 15:02:53 UTC
the file :
(distributed inside id3lib package)

file /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3
/usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3: MP3, 224 kBits, 44.1 kHz,

gst-typefind /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3
/usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 - No type found
Comment 1 Ronald Bultje 2004-10-02 14:12:41 UTC
Can you provide the file? I don't have id3lib installed.
Comment 2 Stephane Loeuillet 2004-10-02 14:20:02 UTC
Created attachment 32163 [details]
mp3 distributed with id3lib
Comment 3 Stephane Loeuillet 2004-11-24 19:40:28 UTC
retried with current CVS of today :

gst-typefind /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3
ERROR (0x8050ea0 - 305923:39:47.855414000)       scheduler(31786)
in error state
/usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 - No type found

gst-typefind --gst-scheduler=basicgthread
/usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 - No type found

gst-typefind --gst-scheduler=optgthread
Erreur de segmentation

gst-typefind --gst-scheduler=entrygthread
ERROR (0x8050eb0 - 305923:41:53.097819000)    entrygthread(31805)
returning error because of element error
/usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 - No type found

so, it triggers an error in both opt & entry
Comment 4 Ronald Bultje 2004-12-17 00:04:13 UTC
Created attachment 34922 [details]
log from typefindfunctions:5

See this log. Basically, the log claims that the file is full of crap, whith
valid mp3 headers here and there, but nowhere any file that has 3 valid headers
in sequence.
Comment 5 Stephane Loeuillet 2004-12-17 09:58:38 UTC
so, feel free to close this one

i assumed this file was a proper mp3 as it is distributed with id3lib, but
perhaps it contains id3 info without mp3 data in the middle
Comment 6 Ronald Bultje 2004-12-17 10:17:30 UTC
I won't close it yet, because hey, we might be wrong. ;). Let's first compare
how other typefinders detect this file.
Comment 7 Stephane Loeuillet 2004-12-21 11:25:50 UTC
setting to low priority as this mp3 file is quite small/empty/broken
Comment 8 Stephane Loeuillet 2005-01-10 04:34:25 UTC
can't we merge this one with bug #152688 ? ([mad/typefind] doesn't support
completely broken mp3 files)
Comment 9 Ronald Bultje 2005-01-10 09:31:40 UTC
Maybe. The thing is that this specific mp3 is very short and thus needs special
case, so even if we do dup it, we should mark it as special and required testing
when I fix the other bug.
Comment 10 Andy Wingo 2005-07-15 11:07:33 UTC
HEAD reports that the file has no type. Closing the bug as WONTFIX -- the file
is both broken and tiny.
Comment 11 Ronald Bultje 2005-07-15 11:42:08 UTC
Stays open. It's a file.
Comment 12 Andy Wingo 2005-07-15 11:48:28 UTC
madplay only decodes 1 frame on the file, and clips a number of samples. So
what's the solution, lower certainties for typefinding as mp3 if you only have
one or two headers in a row?
Comment 13 Ronald Bultje 2005-07-15 18:55:51 UTC
There's several ways to do it, and I'm sure we can find one that we all find
Comment 14 Jan Schmidt 2006-01-20 11:48:24 UTC
The file contains exactly one mp3 frame, and sadly it's not decodable on its own. It needs 36 bytes from a subsequent frame to actually decode. 

Most mp3s are going to be like that - not decodable unless there's at least 2 or 3 frames. The same isn't true for layer 1 and 2 though. 

To be able decode all files, even if they only have a fraction of a second of auduio, we should probably go the path of lowering the probability when we don't have as many frames to detect type on.

Also, the fact that there is a valid mp3 header at byte 0 should raise the probability. If we have to skip bytes to find the header, it's more likely to be id3 or wav or something else.

I think this is what the current typefind logic is trying to do anyway, it probably just needs massaging.
Comment 15 Andy Wingo 2006-01-27 16:39:38 UTC
Changing to -base because it's a typefinding function.
Comment 16 Tim-Philipp Müller 2006-02-06 20:17:07 UTC
Created attachment 58825 [details] [review]
crude patch

Adds fallback to mpeg audio typefinding that finds mpeg/audio caps with a probability of POSSIBLE-1 if there is a valid mpeg audio frame header at offset 0.
Comment 17 Tim-Philipp Müller 2006-02-07 16:21:09 UTC
 2006-02-07  Tim-Philipp Müller  <tim at centricular dot net>

       * gst/typefind/gsttypefindfunctions.c: (mp3_type_find):
         In case we can't find the required number of consecutive
         mpeg audio frames to positively identify an MPEG audio
         stream, check if there's at least a valid mpeg audio
         frame right at offset 0 and if so suggest mpeg/audio
         caps with a very low probability (#153004).