GNOME Bugzilla – Bug 333900
[typefind] cannot play a particular mp3 file
Last modified: 2006-03-09 12:49:27 UTC
Please describe the problem: mp3 files works very well excepted one which is available on http://tchoy.net/~dboucard/rondo_veneziano.mp3 (89MB). sox'play command can play it without any problem but apps using gstreamer cannot. Steps to reproduce: 1. Download the failling file : http://tchoy.net/~dboucard/rondo_veneziano.mp3 (89MB). 2. Try to play it with : gst-launch-0.10 playbin uri=file:///path/to/rondo_veneziano.mp3 Actual results: Here is what gst-launch tells : Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /playbin0: Only a subtitle stream was detected. Either you are loading a subtitle file or some other type of text file, or the media file was not recognized. Additional debug info: gstplaybasebin.c(1453): prepare_output (): /playbin0 ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... FREEING pipeline ... Expected results: Normally, it would play the mp3 file, with an output like that : Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock2 Got EOS from element "playbin0". Execution ended after 201148895000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... Does this happen every time? Currently, the problem has only been found for this file, but I suppose it exists other files in that format. Other information: sox complained about some errors when I tell it to convert the file into ogg. The conversion works, but error messages could give us a track : sox: recoverable frame level error (lost synchronization). sox: recoverable frame level error (bad main_data_begin pointer). [...] sox: recoverable frame level error (forbidden bitrate value). [...] sox: recoverable frame level error (reserved sample frequency value). [...] sox: recoverable frame level error (reserved header layer value). [...] Run "sox rondo_veneziano.mp3 rondo_veneziano.ogg" (may be with -V option)
This is a typefinding problem. There's lots of other data between the ID3v2 tag at the beginning of the file and the mp3 data. It's a similar issue as in the old bug #152688. Here's what happens: tim@sceptic:~$ GST_DEBUG=*:5 gst-launch-0.10 playbin uri=file:///home/tim/rondo_veneziano.mp3 2>&1 | grep typefindhelper | grep suggest gsttypefindhelper.c(139):helper_find_suggest:<sink:proxypad0> 'application/x-id3' called called suggest (100, application/x-id3) gsttypefindhelper.c(139):helper_find_suggest:<id3demux0> 'audio/mpeg' called called suggest (24, audio/mpeg, mpegversion=(int)1, layer=(int)3) gsttypefindhelper.c(139):helper_find_suggest:<id3demux0> 'text/plain' called called suggest (95, text/plain) The text/plain typefinder's probability is WAY to high, and the mpeg typefinder's too low.
This particular file works now: 2006-03-08 Tim-Philipp Müller <tim at centricular dot net> * gst/typefind/gsttypefindfunctions.c: (utf8_type_find_count_embedded_zeroes), (utf8_type_find_have_valid_utf8_at_offset), (utf8_type_find): Make plain/text typefinder more conservative: firstly, check for embedded zeroes, which are perfectly valid UTF-8 characters, but also a fairly good sign that something is not a plain text file; secondly, probe into the middle of the file if possible. If we can't probe into the middle, limit the probability value to be returned to TYPE_FIND_POSSIBLE (see #333900). However, the mp3 typefinder still needs to be fixed to probe into the middle of a file as well if possible. Keeping bug open for that.
Should be fixed now: 2006-03-09 Tim-Philipp Müller <tim at centricular dot net> * gst/typefind/gsttypefindfunctions.c: (mp3_type_find_at_offset), (mp3_type_find): Refactor mpeg/audio typefinding to make it more maintainable and easier to fine-tune. Make probing into middle of the file work properly (fixes #333900, also see #152688).