GNOME Bugzilla – Bug 172419
[typefinding] unrecognised realmedia format?
Last modified: 2006-03-15 14:16:10 UTC
Please describe the problem: When adding this mp3 in Rhythmbox, it asked me to file this bug for a particular mp3. Steps to reproduce: 1. Import the attached mp3 2. 3. Actual results: Rhythmbox asked me to file this bug. A message like this appears on console when running with -d option: [0x91c3440] [rb_metadata_load] rb-metadata-gst.c:468 (21:43:24): loading metadata for uri: file:///mp3/Kiwi/Darcy%20Clay/English%20Rose.mp3 [0x90d6ad8] [rb_shell_player_state_changed_cb] rb-shell-player.c:1435 (21:43:24): state changed [0x90d6ad8] [rb_shell_player_sync_control_state] rb-shell-player.c:1377 (21:43:24): syncing control state [0x90d6ad8] [rb_shell_player_sync_buttons] rb-shell-player.c:1684 (21:43:24): syncing with source 0x92114a0 [0x90d6ad8] [rb_shell_player_set_play_button] rb-shell-player.c:1577 (21:43:24): setting play button [0x91c3440] [rb_metadata_gst_typefind_cb] rb-metadata-gst.c:421 (21:43:24): found type application/x-id3 [0x91c3440] [rb_metadata_gst_error_cb] rb-metadata-gst.c:332 (21:43:24): caught error: Internal GStreamer error: caps problem. File a bug. [0x91c3440] [rhythmdb_add_song] rhythmdb.c:938 (21:43:24): failed to read data from "file:///mp3/Kiwi/Darcy%20Clay/English%20Rose.mp3" [0x91c3440] [push_err] rhythmdb.c:1015 (21:43:24): queueing error for "file:///mp3/Kiwi/Darcy%20Clay/English%20Rose.mp3": Internal GStreamer error: caps problem. File a bug. [0x90d6ad8] [rb_shell_db_error_cb] rb-shell.c:1836 (21:43:24): got db error, showing: TRUE Expected results: Does this happen every time? yes Other information:
Sorry, couldn't attach the mp3. Can I email it to someone?
Cut the first MB off and attach that: head -c1M file.mp3 > head.mp3
Created attachment 39600 [details] Problematic mp3 (first 900k, still displays the problem)
try playing the file with this command (does it work?): $ gst-launch-0.8 gnomevfssrc location="/mp3/Kiwi/Darcy%20Clay/English%20Rose.mp3" ! spider ! volume ! audioscale ! audioconvert ! $(gconftool-2 -g /system/gstreamer/0.8/default/audiosink)
I had to modify the command slightly: $ gst-launch-i386-0.8 gnomevfssrc location="/mp3/Kiwi/Darcy Clay/English Rose.mp3" ! spider ! volume ! audioscale ! audioconvert ! $(gconftool-2 -g /system/gstreamer/0.8/default/audiosink) RUNNING pipeline ... ERROR: from element /pipeline0/spider0/id3demux0: Internal GStreamer error: caps problem. File a bug. Additional debug info: gstid3tag.c(960): gst_id3_tag_do_typefind: /pipeline0/spider0/id3demux0: no caps found Execution ended after 12 iterations (sum 224145000 ns, average 18678750 ns, min 321000 ns, max 156086000 ns).
The file contains an ID3 header with, behind it, a realaudio song. What a life... Get the realaudio using gst-launch filesrc location=$file ! id3demux ! filesink location=$file.noid3, then use gst-typefind to reproduce that we don't see its type and use hexedit to confirm that it's a realaudio song.
This still doesn't work right even with Jan's new spiffy id3demux. The new id3demux determines a total tag size of 1682+10=1683 and typefinding then starts at offset 1683 and fails. If typefinding starts at offset 1684, it works fine. Not sure if the right fix is something like this if (tag_res == ID3TAGS_READ_TAG) { res = TRUE; GST_DEBUG_OBJECT (id3demux, "Read ID3v2 tag of size %d", id3demux->strip_start); + id3demux->strip_start = GST_ROUND_UP_4 (id3demux->strip_start); } else if (tag_res == ID3TAGS_BROKEN_TAG) { res = TRUE; GST_WARNING_OBJECT (id3demux, "Ignoring broken ID3v2 tag of size %d", id3demux->strip_start); } or if it should skip all zeroes after the tag until it finds a non-zero byte and start typefinding on that (is there any ID3-taggable file format that starts with a zero byte?)
Skipping non-zero bytes isn't going to help here, because byte 1684 is non-zero as we expect. At byte 1684 there is the sequence 0x29 0x2e 0x52 0x4d 0x46 ").RMF", but the typefinding function is looking for ".RMF" Are we sure the typefind function is correct?
libmagic also seems to be checking only for .RMF at offset 0 (see /usr/share/misc/file/magic.mime), so the typefind function seems correct (and no other player recognises the format either).
So either a broken file or a typefinding problem. Re-assigning to -base where our typefinding functions live.
I can not find a single player that will play or recognise this file (of mplayer, xine, vlc, helix-player). Not even Real's own 'RealPlayer 10 for Linux' will play it. I don't know what kind of this file is, but it looks just broken. Len - if you know any player on any operating system that can play this, please re-open the bug and let us know. There is a (very small) possibility that the original is in fact an mp3 file and there's a very large realmedia tag of some sort (image data, whatever) between the ID3 tag and the mp3 data. If that realmedia data was more than ~450kB in size, we might not recognise the file right with a 900kB snippet. If this is the case and the really is mpeg audio data somewhere then we should be able to recognise this now with an up-to-date core (0.10.4), -base (0.10.5) and gst-plugins-good from CVS. Feel free to e-mail me the whole file so I can check whether that's the case or not (although I somehwhat doubt it). Closing the bug, as there isn't much more we can do about this for now.