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 428021 - [mad, mp3parse] better duration estimates for VBR
[mad, mp3parse] better duration estimates for VBR
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other All
: Normal enhancement
: 0.10.8
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 432533
 
 
Reported: 2007-04-09 21:13 UTC by Pacho Ramos
Modified: 2008-05-21 22:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
totem-gst.avi.gz (886.41 KB, application/x-gzip)
2007-04-09 21:15 UTC, Pacho Ramos
Details
sorry, wrong bug :( (639 bytes, text/plain)
2007-07-04 14:51 UTC, Gautier Portet
Details

Description Pacho Ramos 2007-04-09 21:13:32 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:
Comment 1 Pacho Ramos 2007-04-09 21:15:28 UTC
Created attachment 86075 [details]
totem-gst.avi.gz
Comment 2 Pacho Ramos 2007-04-10 10:36:47 UTC
banshee has a similar problem, seems a problem with gstreamer, but I don't know what plugin is failing
Comment 3 Tim-Philipp Müller 2007-04-10 11:10:57 UTC
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. 

Comment 4 Pacho Ramos 2007-04-11 18:32:54 UTC
I don't have this problem with rhythmbox-0.10.0 :-/
Comment 5 Christophe Fergeau 2007-04-15 21:35:22 UTC
(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?
Comment 6 Pacho Ramos 2007-04-15 21:39:35 UTC
I have the problems with a data CD with some mp3 files 

Thanks
Comment 7 Alex Lancaster 2007-04-23 08:33:06 UTC
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

Comment 8 Alex Lancaster 2007-04-23 08:47:34 UTC
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
Comment 9 Alex Lancaster 2007-04-23 08:57:48 UTC
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
Comment 10 Pacho Ramos 2007-04-23 09:11:16 UTC
I have gstreamer-0.10.11 under gentoo and it doesn't work ok for me :-/
Comment 11 Alex Lancaster 2007-04-23 09:37:28 UTC
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.
Comment 12 Diego Escalante Urrelo (not reading bugmail) 2007-05-11 23:55:01 UTC
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?
Comment 13 Tim-Philipp Müller 2007-05-13 16:44:39 UTC
> (...) 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/).
Comment 14 Gautier Portet 2007-07-02 15:52:24 UTC
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.
Comment 15 Gautier Portet 2007-07-04 14:51:00 UTC
Created attachment 91182 [details]
sorry, wrong bug :(
Comment 16 Gautier Portet 2007-07-04 14:54:32 UTC
please ignore the previous patch, it's not for this bug.
Comment 17 Sebastian Dröge (slomo) 2008-05-16 22:42:38 UTC
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.
Comment 18 Pacho Ramos 2008-05-17 10:02:53 UTC
Thanks a lot :-)

Should be fixed in (upcoming) gst-plugins-ugly-0.10.8 then?
Comment 19 Sebastian Dröge (slomo) 2008-05-17 10:21:30 UTC
Yes, IIRC everything except VBRI headers should be fixed in 0.10.7 already (and VBRI headers are very uncommon)