GNOME Bugzilla – Bug 104854
mp3 typefinding (and typefinding in general) too exact
Last modified: 2004-12-22 21:47:04 UTC
For internet radio, I often get a stream that is right in the middle of an MP3. The current mp3 typefinding code (/foreign-cvs/cvs.sourceforge.net/gst-plugins/gst/mpegaudioparse/gstmp3types.c) is too exact; only looks at the beginning of the buffer. In general, it would be nice if we had a way to pass a 'fuzziness' qualifier to typefinding functions. For now though, I think we would not break anything if we just made the mp3 typefinding function search through more of the buffer for an mp3 frame header. Most programs will already konw the content from the filename extension. By the way, I have a small patch to clean up that file, which I will attach.
Created attachment 13968 [details] [review] minor cleanups
Applied patch 13968 and GST_DEBUG enhancement as gst-plugins/gst/mpegaudioparse/gstmp3types.h 1.11.8.1.
Created attachment 13975 [details] [review] First attempt at checking the whole buffer. Please test.
Delaying until 0.6.x because it is not required for either of the two deliverables (gnome-media and nautilus-media), and there's a significant false-positive risk.
Since all these bugs are listed as needing to be fixed in 0.6.x, they are by definition bugs in 0.6.0
Applied to 0.6.1 CVS.
Thanks to our statistical genious Benjamin (company), we found out that the above has a chance of between 35 and 100% for false positives on a random sequence of 4096 bytes (our typefind buffer size!), which means it's unacceptable. So the last bit will be reverted from 0.6.1.
We actually fixed this some time ago, didn't we? I'm quite sure we search three frames now, which is always enough and works for streams, too.