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 656018 - crash playing some mp3's
crash playing some mp3's
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.35
Other Linux
: High critical
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 662812 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-08-05 09:19 UTC by Timo Aaltonen
Modified: 2012-06-21 21:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
bactrace (6.11 KB, text/plain)
2011-08-05 10:43 UTC, Timo Aaltonen
  Details
typefind: bump probability if all frames we found are similar (1.92 KB, patch)
2011-08-08 09:30 UTC, Vincent Penquerc'h
committed Details | Review

Description Timo Aaltonen 2011-08-05 09:19:26 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.
Comment 1 Timo Aaltonen 2011-08-05 09:25:54 UTC
too large, copied it here:

http://koti.kapsi.fi/~tjaalton/gnome656018/
Comment 2 Sebastian Dröge (slomo) 2011-08-05 09:29:11 UTC
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!
Comment 3 Timo Aaltonen 2011-08-05 10:43:12 UTC
Created attachment 193302 [details]
bactrace

couldn't get the debugsyms for libgsttag, so it's not complete but hopefully useful anyway.
Comment 4 Vincent Penquerc'h 2011-08-05 12:10:47 UTC
I can repro this. It looks like it's detected as video for some reason.
Comment 5 Timo Aaltonen 2011-08-05 12:20:58 UTC
yeah, that's why nautilus doesn't show the music icon for these files, but a corrupted "preview" icon.
Comment 6 Vincent Penquerc'h 2011-08-05 13:41:25 UTC
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.
Comment 7 Vincent Penquerc'h 2011-08-05 13:42:53 UTC
Also, would you have a second file, which works, and which was created in the same way ?
Comment 8 Timo Aaltonen 2011-08-07 14:19:57 UTC
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.
Comment 9 Vincent Penquerc'h 2011-08-08 09:28:14 UTC
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.
Comment 10 Vincent Penquerc'h 2011-08-08 09:30:02 UTC
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.
Comment 11 Sebastian Dröge (slomo) 2011-08-10 09:20:44 UTC
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
Comment 12 Timo Aaltonen 2011-09-15 08:17:41 UTC
finally got a chance to build a package with the patch, so confirming now that it fixed the issue
Comment 13 Jonathan Matthew 2011-10-29 02:14:09 UTC
*** Bug 662812 has been marked as a duplicate of this bug. ***