GNOME Bugzilla – Bug 325972
[typefinding] doesn't recognise this mp3
Last modified: 2006-03-10 09:02:41 UTC
This bug is a part of the issue described by https://launchpad.net/malone/bugs/6399
"I have got around 250 mp3 songs anf they play well with the "ugly" gst0.10 plug-in, except 5 of them.
Rhythmbox reports an "internal gstreamer error". It talks either about "pad" or "caps" problem.
$ gst-launch-0.10 --gst-debug-level=2 -t filesrc location=325972.mp3 ! decodebin ! fakesink Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARN (0x817a030 - 0:00:00.155193000) id3tag(10997) gstid3tag.c(1037):gst_id3_tag_do_typefind:<id3demux0> error: no caps found
WARN (0x817a030 - 0:00:00.165811000) id3tag(10997) gstid3tag.c(1037):gst_id3_tag_do_typefind:<id3demux0> error: no caps found
WARN (0x817a030 - 0:00:00.166104000) id3tag(10997) gstid3tag.c(1037):gst_id3_tag_do_typefind:<id3demux0> error: no caps found
WARN (0x817a030 - 0:00:00.166358000) id3tag(10997) gstid3tag.c(1037):gst_id3_tag_do_typefind:<id3demux0> error: no caps found
WARN (0x817a030 - 0:00:00.167464000) mad(10997) gstmad.c(1347):gst_mad_chain: mad_frame_decode had an error: lost synchronization
WARN (0x817a030 - 0:00:00.177884000) mad(10997) gstmad.c(1347):gst_mad_chain: mad_frame_decode had an error: input buffer too small (or EOF)
Pipeline is PREROLLED ...
ERROR: from element /pipeline0/decodebin0/id3demux0: Internal GStreamer error: caps problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.
Additional debug info:
gstid3tag.c(1037): gst_id3_tag_do_typefind: /pipeline0/decodebin0/id3demux0:
no caps found
ERROR: pipeline doesn't want to preroll.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...
The same command with gst-launch-0.8 works fine
You can download the corresponding file from http://pkg-gnome.alioth.debian.org/bugzilla/325972.mp3
Doesn't work with current CVS.
Looks like it has a stand-alone ID3v2 'custom object' frame at the beginning of the file that is not embedded in a proper ID3v2 tag:
00000000 0b 47 45 4f 42 00 00 06 90 00 00 00 62 69 6e 61 |.GEOB.......bina|
00000010 72 79 00 00 52 65 61 6c 4a 75 6b 65 62 6f 78 3a |ry..RealJukebox:|
00000020 4d 65 74 61 64 61 74 61 00 52 4a 45 58 00 00 00 |Metadata.RJEX...|
00000030 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Probably Real's custom object is fairly large; from the looks of it the MP3 frames start around offset 0x6f24 at the earliest, that might be longer than we're probing for header frames for in typefind. IIRC in 0.8 the mp3 typefinder would also scan the middle of the file for consecutive mpeg audio frames; possible there are some typefind changes from 0.8 that need to be forward-ported.
Seb, any idea where these files came from? I've seen others that have these Real binary blobs, but don't know what produces them.
no idea, the file is not minde, I pinged the distribution bug submitter about that
Hi, I am the one who reported that bug in Ubuntu originally.
All 5 files gst0.10 is having problems with, where downloaded from P2P.
As for the "Real binary blobs", I seem to recall that a few years ago, under Windows, Real offered a program to rip audio CD's and convert them into MP3, and manage a library of songs/albums. Looking at the above header, it think it was indeed called "Real JukeBox".
Maybe the guy I happened to download these songs from, had them on CD and ripped them using this program.
Still, the songs play perfectly with gst 0.8, totem-xine, XMMS...
Okay, RB appears to be happy again with this particular song, it's getting better then... ;-)
Oops please ignore that last comment ! I mixed things up (with bug 325974). No, it still doesn't work, sadly. Sorry for the noise and confusion... :-/
This file works now after the recent typefinding changes in core and -base _and_ addition of pull-based typefinding to id3demux in -good CVS.