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 333900 - [typefind] cannot play a particular mp3 file
[typefind] cannot play a particular mp3 file
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-08 14:47 UTC by Damien Boucard
Modified: 2006-03-09 12:49 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Damien Boucard 2006-03-08 14:47:19 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)
Comment 1 Tim-Philipp Müller 2006-03-08 14:56:20 UTC
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.
Comment 2 Tim-Philipp Müller 2006-03-08 17:24:50 UTC
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.
Comment 3 Tim-Philipp Müller 2006-03-09 12:49:27 UTC
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).