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 348075 - [typefind] fails to typefind mp3 content after ID3v2 tag
[typefind] fails to typefind mp3 content after ID3v2 tag
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.3
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-20 02:34 UTC by Michael Schreifels
Modified: 2006-07-23 10:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Result of: head -c 100k /home/michael/music/Queensrÿche/Rage for Order (1986)/02 - I Dream in Infrared.mp3 > cut.mp3 (100.00 KB, audio/mpeg)
2006-07-20 02:43 UTC, Michael Schreifels
Details

Description Michael Schreifels 2006-07-20 02:34:27 UTC
Steps to reproduce:
1. Consider I have a file: /home/michael/music/Queensrÿche/Rage for Order (1986)/02 - I Dream in Infrared.mp3 that is (evidently) tagged appropriately with the artist name, title, year, etc. (tagged by MusicBrainz Picard 0.7.0)

2. I use Rhthmbox with GStreamer, as well as Totem. I tried opening up the file in both applications and it returned a GStreamer error "Could not determine the type of stream". Please note that other MP3's played fine. I also ran this:

michael@michael-c:~$ gst-launch playbin uri=file:///home/michael/music/Queensrÿche/Rage for Order (1986)/02 - I Dream in Infrared.mp3
Setting pipeline to PAUSED ...

(gst-launch-0.10:10876): GStreamer-CRITICAL **: gst_pad_activate_pull: assertion `old == GST_ACTIVATE_NONE' failed
Pipeline is PREROLLING ...
ERROR: from element /playbin0/decoder/id3demux0: Could not determine type of stream.
Additional debug info:
gstid3demux.c(883): gst_id3demux_sink_activate (): /playbin0/decoder/id3demux0:
Could not detect type for contents within an ID3 tag
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

3. I was, at this point, being helped by "doctau" of irc.gnome.org #rhythmbox, who told me to file this report. He told me to run: "gst-launch filesrc location=file:///home/michael/music/Queensrÿche/Rage for Order (1986)/02 - I Dream in Infrared.mp3 ! mad ! audioconvert ! autoaudiosink". The song started playing, although it appeared to be somewhere in the middle.

Stack trace:


Other information:
The person helping had me run: "head -c 100k /home/michael/music/Queensrÿche/Rage for Order (1986)/02 - I Dream in Infrared.mp3 > cut.mp3" and told me to attach it to this report. You don't have any file attachment feature set up here, so I left it out. If you need it, please let me know. Also, I didn't really want to spend my entire evening on this, so I didn't provide a stack trace. Let me know if you really need one. Quite honestly, I don't know what the problem is or what most of the commands I ran actually did, so I completely relied on the knowledge of the person helping me. Let me know if you need any more info or anything or if this bug report is actually not a bug.
Comment 1 Michael Schreifels 2006-07-20 02:43:32 UTC
Created attachment 69214 [details]
Result of: head -c 100k /home/michael/music/Queensrÿche/Rage for Order (1986)/02 - I Dream in Infrared.mp3 > cut.mp3
Comment 2 Tim-Philipp Müller 2006-07-20 08:32:19 UTC
Thanks for the sample, but I'm afraid it's not very useful, since it only contains

 - the ID3v2 tag (993 bytes)
 - followed by ~99kB of zeroes

Zeroes are hard to typefind :)

Any chance you could put up the entire file somewhere for download?

(the assertion has been fixed in CVS, but it's harmless and occurs only if the type of the content couldn't be determined).
Comment 3 Michael Schreifels 2006-07-20 15:24:36 UTC
As I only own the CD, I don't believe that I can legally post the entire MP3 file, can I? If I can do this or there is something else that I can do to provide you will the required information, please let me know.
Comment 4 Tim-Philipp Müller 2006-07-23 10:34:48 UTC
A hexdump of the beginning of this file looks like this:

...
000002c0  58 58 58 00 00 00 18 00  00 03 4d 75 73 69 63 42  |XXX.......MusicB|
000002d0  72 61 69 6e 7a 20 4e 6f  6e 2d 41 6c 62 75 6d 00  |rainz Non-Album.|
000002e0  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0...............|
000002f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
002f8dc0  00 00 51 7d 02 4b ba 31  4e 83 2c cf b9 67 d6 df  |..Q}.K.1N.,..g..|


In other words, the file (which is ~4MB apparently) consists of

 - 1kB of ID3v2 data.
 - about 3.1MB of zeroes
 - about 0.9MB of mp3 data after that



I see two options here:

 - WONTFIX

 - implement a very simple "zero-tag"-demuxer based on the
   tagdemux base class we already have (very little code required)
   that strips zeroes from the beginning of a stream (this seems
   to be reasonably common for some reason, althoug this file is
   an extreme case of course)

Comment 5 Jan Schmidt 2006-07-23 10:38:50 UTC
To me, the file is just broken. It's perfectly normal to leave padding zeroes in an ID3v2 to save rewriting the entire file when the tag changes, but those zeroes should be included in the tag header.

Which program wrote this file?
Comment 6 Tim-Philipp Müller 2006-07-23 10:58:21 UTC
I also think this file is way beyond "just-a-little-bit-unusual", and it doesn't even look like it contains a full song, so even if we did fix this the benefits wouldn't be that great.

WONTFIX-ing this bug, sorry.