GNOME Bugzilla – Bug 428021
[mad, mp3parse] better duration estimates for VBR
Last modified: 2008-05-21 22:54:51 UTC
Please describe the problem: Audio tracks lengths are not properly detected when gstreamer backend is used by totem, with xine backend it works fine. I attach an AVI video with an example, in this, properly length is 5:18, look at button bar, the length is always changing Thanks a lot Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 86075 [details] totem-gst.avi.gz
banshee has a similar problem, seems a problem with gstreamer, but I don't know what plugin is failing
This happens with VBR mp3 audio files, probably with both the 'mad' mp3 decoder and fluendo's 'flump3dec' mp3 decoder. This is really expected behaviour at the moment. In order to know the exact length of an VBR mp3 file, GStreamer would need to scan the entire file (or at least parts of it), something which causes as many problems as it solves (think of files mounted on an NFS/samba share etc.), so it's a trade-off we're making on purpose here. We should be able to handle this better though, hence marking as enhancement and moving to GStreamer.
I don't have this problem with rhythmbox-0.10.0 :-/
(In reply to comment #3) > This is really expected behaviour at the moment. In order to know the exact > length of an VBR mp3 file, GStreamer would need to scan the entire file (or at > least parts of it), something which causes as many problems as it solves (think > of files mounted on an NFS/samba share etc.), so it's a trade-off we're making > on purpose here. > Most VBR MP3 files start with a xing header (dummy mp3 frame) containing the duration among other thing, the mad element handles them afaik (and xingmux can write them). Maybe this can't work in that case because the mp3 is muxed in an AVI file?
I have the problems with a data CD with some mp3 files Thanks
It seems like something has changed between gstreamer-0.10.11 and gstreamer CVS, because gstreamer 0.10.11 (on Fedora Core 6) gets the duration correct but CVS doesn't, as show by the following gst-launch outputs: Here is the gstreamer 0.10.11 output (note the bitrate of 142803 bps and the duration): gst-launch -t playbin uri=file:///tmp/foobar.mp3 Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: Awake artist: Faultline track count: 9 track number: 1 album: Closer Colder genre: Unknown encoder: Rhythmbox 5641861 date: 1999-01-01 track ID: 7a405e7e-d0a9-4299-a786-1f2aee03faaa artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 album ID: 13d036da-0f87-4cf5-a12e-5928122f2582 album artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 ID3v2 frame: buffer of 20 bytes, type: application/x-gst-id3v2-tsop-frame, version=(int)4 FOUND TAG : found by element "mad0". duration: 331000000000 bitrate: 142803 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 here is the output for gstreamer CVS (as of 2007-04-23), which shows a bitrate of 32000 bps Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: Awake artist: Faultline track count: 9 track number: 1 album: Closer Colder genre: Unknown encoder: Rhythmbox 5641861 date: 1999-01-01 track ID: 7a405e7e-d0a9-4299-a786-1f2aee03faaa artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 album ID: 13d036da-0f87-4cf5-a12e-5928122f2582 album artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 artist sortname: Faultline FOUND TAG : found by element "mpegaudioparse0". bitrate: 32000 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none bitrate: 32000
The problem appears to be with the mpegaudioparse0 element in gstreamer-plugins-ugly in CVS, if I move this element aside: [gstreamer-0.10]$ mv -i libgstmpegaudioparse.* /tmp/ and try again with gstreamer (CVS), I get the correct duration/bitrate: Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: Awake artist: Faultline track count: 9 track number: 1 album: Closer Colder genre: Unknown encoder: Rhythmbox 5641861 date: 1999-01-01 track ID: 7a405e7e-d0a9-4299-a786-1f2aee03faaa artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 album ID: 13d036da-0f87-4cf5-a12e-5928122f2582 album artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 artist sortname: Faultline FOUND TAG : found by element "mad0". duration: 331000000000 bitrate: 142803 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3
Here is the debugging output: GST_DEBUG="mp3parse:5" gst-launch -t playbin uri=file:///home/alex/mp3/complete-rips/Faultline/Closer\ Colder/01\ -\ Awake.mp3 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: Awake artist: Faultline track count: 9 track number: 1 album: Closer Colder genre: Unknown encoder: Rhythmbox 5641861 date: 1999-01-01 track ID: 7a405e7e-d0a9-4299-a786-1f2aee03faaa artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 album ID: 13d036da-0f87-4cf5-a12e-5928122f2582 album artist ID: f42ce12a-5007-48b0-8730-f2348784fac6 artist sortname: Faultline 0:00:00.176046000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:348:gst_mp3parse_sink_event:<mpegaudioparse0> Converted incoming segment to TIME. start = 0, stop = -1pos = 0 0:00:00.176110000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:369:gst_mp3parse_sink_event:<mpegaudioparse0> Pushing newseg rate 1, applied rate 1, format 3, start 0, stop -1, pos 0 0:00:00.176376000 5647 0x8dab7a0 LOG mp3parse gstmpegaudioparse.c:498:gst_mp3parse_chain:<mpegaudioparse0> buffer of 2406 bytes 0:00:00.176436000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb9044 0:00:00.176487000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 417 bytes 0:00:00.176535000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 128000, layer = 3, channels = 2 0:00:00.176584000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:573:gst_mp3parse_chain:<mpegaudioparse0> header=FFFB9044, header2=00FFFB10, bpf=417 0:00:00.176633000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:584:gst_mp3parse_chain:<mpegaudioparse0> next header doesn't match (header=FFFB9044, header2=00FFFB10, bpf=417) 0:00:00.176731000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.176778000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.176826000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2 0:00:00.176874000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:573:gst_mp3parse_chain:<mpegaudioparse0> header=FFFB1064, header2=FFFB1064, bpf=104 0:00:00.176936000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:395:gst_mp3parse_emit_frame:<mpegaudioparse0> pushing buffer of 104 bytes 0:00:00.177054000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.177104000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.177151000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2 0:00:00.177200000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:395:gst_mp3parse_emit_frame:<mpegaudioparse0> pushing buffer of 104 bytes 0:00:00.180384000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.180443000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.180493000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2 0:00:00.180542000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:395:gst_mp3parse_emit_frame:<mpegaudioparse0> pushing buffer of 104 bytes 0:00:00.180823000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.180873000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.180921000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2 0:00:00.180969000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:395:gst_mp3parse_emit_frame:<mpegaudioparse0> pushing buffer of 104 bytes 0:00:00.181245000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.181294000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.181342000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2 0:00:00.181390000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:395:gst_mp3parse_emit_frame:<mpegaudioparse0> pushing buffer of 104 bytes FOUND TAG : found by element "mpegaudioparse0". bitrate: 32000 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none bitrate: 32000 0:00:00.191780000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.191837000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.191886000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2 0:00:00.191935000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:395:gst_mp3parse_emit_frame:<mpegaudioparse0> pushing buffer of 104 bytes 0:00:00.192221000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:660:head_check:<mpegaudioparse0> checking mp3 header 0xfffb1064 0:00:00.192271000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:185:mp3_type_frame_length_from_header:<mpegaudioparse0> Calculated mp3 frame length of 104 bytes 0:00:00.192319000 5647 0x8dab7a0 DEBUG mp3parse gstmpegaudioparse.c:187:mp3_type_frame_length_from_header:<mpegaudioparse0> samplerate = 44100, bitrate = 32000, layer = 3, channels = 2
I have gstreamer-0.10.11 under gentoo and it doesn't work ok for me :-/
I filed bug #432533 about not reading correct VBR files with xing headers, this is a regression from previously correct reading of VBRs ripped with xing headers using the xingmux element from -bad.
I have a *maybe* related problem, I'm converting from ogg to mp3 using soundconverter, a gnome app that uses gstreamer. The produced mp3s don't have a length so totem goes crazy with the value as well as the iPod. I have tried with AVR and VBR, the only one that works is CBR. AVR and VBR makes the iPod crazy and totem read wrong length (jumping around like crazy). Might these be the same problem but in a different manifestation?
> (...) I'm converting from ogg to mp3 using soundconverter, a gnome app > that uses gstreamer. (...) Might these be the same problem but in a > different manifestation? Maybe, that depends a lot on the pipeline soundconverter uses (e.g. does it contain an xingmux element or not, etc.). You should file a bug with soundconverter first. If it's a GStreamer issue, the developers will pass it on to us. From the ChangeLog, it looks like this should be fixed in version 0.9.4 or newer (see http://soundconverter.berlios.de/).
Unfortunately, the change in soundconverter 0.9.4 was to remove the unused xingheader option of lame and adding xingmux element instead. I tought the VBR related problems were gone, but someone pointed out that VBR mp3 s encoded with soundconverter now have a broken xing header, like described in bug #397759.
Created attachment 91182 [details] sorry, wrong bug :(
please ignore the previous patch, it's not for this bug.
Ok, so IMHO we can close this bug now. xingmux writes correct Xing headers now, mp3parse reads VBRI and Xing headers for the duration and that's more or less all we can do about this bug. VBR files without VBRI or Xing header will have inacurate durations but the estimated duration will converge to the real duration after a few seconds usually.
Thanks a lot :-) Should be fixed in (upcoming) gst-plugins-ugly-0.10.8 then?
Yes, IIRC everything except VBRI headers should be fixed in 0.10.7 already (and VBRI headers are very uncommon)