GNOME Bugzilla – Bug 656018
crash playing some mp3's
Last modified: 2012-06-21 21:40:33 UTC
I have some mp3's that make apps (banshee, gst123 etc) either segfault or hang when trying to play them. The source flac's play fine. I'll attach a failing mp3. using ubuntu oneiric devel series.
too large, copied it here: http://koti.kapsi.fi/~tjaalton/gnome656018/
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug. You'll also need to add a stack trace; please see http://live.gnome.org/GettingTraces for more information about how to do so. Thanks in advance!
Created attachment 193302 [details] bactrace couldn't get the debugsyms for libgsttag, so it's not complete but hopefully useful anyway.
I can repro this. It looks like it's detected as video for some reason.
yeah, that's why nautilus doesn't show the music icon for these files, but a corrupted "preview" icon.
What encoder created this file ? If it got tagged after encoding, what program modified it ? It looks like either there's lots of zero bytes inserted between the ID3 tag and the MP3 data, or the ID3 tag size was written incorrectly, so GStreamer finds the MP3 data but isn't too sure it's right since it was found in the middle of the file.
Also, would you have a second file, which works, and which was created in the same way ?
This is my workflow for encoding the cd's to mp3: - rip to flac with sound-juicer - find the cover art and add it to the tag with easytag - reencode to mp3 with flac2mp3 http://projects.robinbowes.com/flac2mp3/trac (encoder is lame), which copies the metadata to the mp3, and also keeps it in sync if the flac metadata has changed I added another song from the same album, which has the same timestamp as the broken one so I believe they're both created with the same software versions.
Thanks. That second file exhibits the same issue, but GStreamer reckons it's slightly more likely to be an MP3 file in this case. So there are three different issues: 1 - flac2mp3 probably writes the ID3 data incorrectly 2 - gstreamer's typefind misdetects the not-quite-correct MP3 as H.264 3 - ffmpeg's H.264 decoder crashes when given that MP3 data I have now changed GStreamer to fix 2, which will solve your issue (both these files will now properly be recognized as MP3). It is possible that other files still fail, if they contain more extra filler data. Unfortunately, the more leeway we give to the MP3 typefinder, the more likely it is we will detect something else as MP3 if it looks similar.
Created attachment 193396 [details] [review] typefind: bump probability if all frames we found are similar Similar meaning same layer, same bitrate, and same number of channels This fixes misdetection of (some MP3 files that have zero padding between the ID3 tag and the MP3 stream) as H.264 video.
Could someone file bugs against ffmpeg and ffmpeg2theora for the other two bugs? commit fa3e246866220680e1d3b7950de8cd0079809997 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Mon Aug 8 10:00:40 2011 +0100 typefind: bump probability if all frames we found are similar Similar meaning same layer, same bitrate, and same number of channels This fixes misdetection of (some MP3 files that have zero padding between the ID3 tag and the MP3 stream) as H.264 video. https://bugzilla.gnome.org/show_bug.cgi?id=656018
finally got a chance to build a package with the patch, so confirming now that it fixed the issue
*** Bug 662812 has been marked as a duplicate of this bug. ***