GNOME Bugzilla – Bug 119159
cannot play certain mp3s with gstreamer backend
Last modified: 2004-12-22 21:47:04 UTC
<hofi> i have quite a few mp3s that won't play with 'could not find media type', they play just fine in every other player around.. <hofi> newest cvs btw. <hadess> hofi: file a bug and attach the file up somewhere so we can reproduce the problem <hadess> hofi: also try it with the xine backend <hofi> ok will try xine backend first <hadess> but file a bug anyway please :) <hofi> will do <hofi> fyi, xine backend worked there ya go, haven't got more info.. stdout stays silent too when it happens. my gnome libraries are at GNOME 2.3.3 <=> garnome 0.25.1.. all of gst is at 0.6.2 testmp3 is <a href="http://www.mysunrise.ch/users/narutaki/rb-testcase.mp3">here</a>
Looks like a GStreamer bug. I think the id3v2 tags on the file are corrupted, though. If I strip them, it works fine.
Try reseting the id3v2 on those mp3s that give the media type error. At this point I don't know what causes this.
The tags aren't corrupted. Does Gstreamer: A) Read tags? B) Read the header and offset past the size? C) Scan for sync? I personally have been having trouble with mp3s that either don't have sync headers or have padding the extends past the tag size. BTW. What tagging software are you using? Artist should be TPE2, not TPE1. (TPE1 is for leads and soloists.)
A) yes B) uh? I don't understand, I'm affraid. If you mean scan for larger headers than the standard buffer size, then yes, but only in 0.6.x CVS. 0.6.2 doesn't have this yet. C) yes, but only since 0.6.2 We read TPE[123], so that should be fine. In general, I've applied a fix for mp3 typefiding (large header mp3s) to CVS, please try current 0.6.x (jhbuild or so) to see if that works for you if you can.
Whats the 6.x CVS branch named? I've done some testing on 0.6.2. Adding a byte of 0x00 before a sync will make it fail, likewise: 49 44 33 03 00 00 00 00 00 05 00 00 00 00 00 works and: 49 44 33 03 00 00 00 00 00 05 00 00 00 00 00 00 fails. Also, I have an mp3 which, due to a corrupted beginning, doesn't have a sync until 25KB in. Removing the data before that sync makes it run perfectly. (I'll attach it if you need it.) 0.6.2 is not searching for sync, or if it is, it isn't doing a good job at finding it. This is responsible for most (if not all) "Could not find media type errors" for mpeg audio.
We search for a sync only in the first 8kB (and in 0.6.2, this is even 4 kB). So if your first 25 kB is bogus, then it won't find it. I'm not exactly sure what the best way to detect such broken mp3s is. Sure, we can increase buffer size, but then, yet a new mp3 will turn up...
(Just clarifying, since I haven't read the docs yet) You take a 8(4)KB buffer from the beginning of a file/stream and use that to determine the media type (similar to gnome-vfs's method for mime-types)? And the issue is, if the stream type isn't found in that buffer, you error?
OK, I just got CVS and that fixed the problems the seek scanning in I did discover another problem though. I have another file; it has a proper sync right after its tag, but the tag has a picture in it so its 14KB long. If gstreamer finds a tag in a stream, it should offset the buffer past the tag before looking for the media type. Remember ID3 tags can be up to 256MB + 20B long. Also, in regards to increasing the buffer size (just an idea): Each media type should have a reference to where in a stream its type can be found, eg: First KB, First 20KB, Whole Stream; and how many bytes make up its type header, 4, 8, 256, etc. Then you would have a simple method for finding the types of media where their first header is corrupted: // Everything in this code block is made up int offset = 0, max_size; do { // get the buffer at an offset of "offset" in the stream the size of // "BUFFER_SIZE" buffer = get_buffer( offset, BUFFER_SIZE ); // Check for media types which can be found after "offset", so if a // media type can only be found in the first 100 bytes of a stream, // and the offset is 101, you won't look for that type. type = check_for_types( offset, buffer ); // stop seaching if the type is found if( type != unknown ) break; // Get the maximum type header size that can be found beyond // "offset". max_size = get_maximum_type_header_size( offset ); // Move the offset to the "BUFFER_SIZE" - "max_size" so if a header // is cut in half by a buffer, it can still fe found. offset += BUFFER_SIZE - max_size; // Loop until the end of the stream. } while( offset + BUFFER_SIZE < stream_size );
This requires a new typefind system. Benjamin (company on IRC) has some ideas on that, too. You should talk to him for details. We acknowledge that our current system isn't perfect. However, we cannot fix that in 0.6.x because of ABI compatibility. If you want to help working on improving it in CVS HEAD, please do so. :). We're mostly online on IRC for discussion.
original reporter here, just wanted to tell you that I don't see this behaviour with my mp3 testcase anymore after upgrading to 0.6.3 although the underlying problem seems to still persists :)
It's the old "your ID3v2 tag is too big" problem. *** This bug has been marked as a duplicate of 94113 ***