GNOME Bugzilla – Bug 153004
[typefind] can't identify mp3 file with one single mpeg frame
Last modified: 2006-02-07 16:21:09 UTC
the file : /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 (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, Stereo 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
Can you provide the file? I don't have id3lib installed.
Created attachment 32163 [details] mp3 distributed with id3lib
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) gstoptimalscheduler.c(2622):gst_opt_scheduler_iterate:<GstOptScheduler@0x81ea470> 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 /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 - No type found gst-typefind --gst-scheduler=optgthread /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 Erreur de segmentation gst-typefind --gst-scheduler=entrygthread /usr/share/doc/id3lib-3.8.3-r3/examples/crc53865.mp3 ERROR (0x8050eb0 - 305923:41:53.097819000) entrygthread(31805) entryscheduler.c(1076):gst_entry_scheduler_iterate:<GstEntryGThreadScheduler@0x81e9fc8> 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
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.
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
I won't close it yet, because hey, we might be wrong. ;). Let's first compare how other typefinders detect this file.
setting to low priority as this mp3 file is quite small/empty/broken
can't we merge this one with bug #152688 ? ([mad/typefind] doesn't support completely broken mp3 files)
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.
HEAD reports that the file has no type. Closing the bug as WONTFIX -- the file is both broken and tiny.
Stays open. It's a file.
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?
There's several ways to do it, and I'm sure we can find one that we all find acceptable.
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.
Changing to -base because it's a typefinding function.
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.
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).