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 605765 - Taglib returns around 70% of the duration of an mp3 if it's VBR
Taglib returns around 70% of the duration of an mp3 if it's VBR
Status: RESOLVED WONTFIX
Product: taglib-sharp
Classification: Other
Component: General
unspecified
Other Windows
: Normal normal
: ---
Assigned To: taglib-sharp-maint
taglib-sharp-maint
Depends on:
Blocks:
 
 
Reported: 2009-12-30 22:07 UTC by Pupeno
Modified: 2018-08-17 19:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pupeno 2009-12-30 22:07:55 UTC
I'm using Taglib to get the duration of some mp3s and it's returning around the 70% of the real duration of the mp3 (real duration as measured by a stopwatch, VLC and other players.

One of the MP3 that is known to cause the problem is this: http://hearablog.com/post/13/A-Smart-Bear-Sacrifice-your-health-for-your-startup.mp3

Probably other MP3s at http://hearablog.com cause it as well.

Thanks.
Comment 1 Gabriel Burt 2009-12-30 22:09:47 UTC
I can reproduce this - taglib# shows duration is 4:50.86 but gstreamer (correctly) shows it as 6:40.
Comment 2 Gabriel Burt 2009-12-30 22:11:17 UTC
Ah, I just noticed that taglib# also says the bitrate is 128kbps, but gstreamer says 96kbps - hence 75%. :)
Comment 3 Gabriel Burt 2009-12-30 22:24:14 UTC
The problem seems to be in the

 } else if (AudioFrameLength > 0 &&
                    AudioBitrate > 0) {

clause of the Duration getter in Mpeg/AudioHeader.cs - line 492.
Comment 4 Gabriel Burt 2009-12-30 22:26:02 UTC
Hrm, VLC also says it's 128 kbps, but has the correct 6:40 duration.
Comment 5 Gabriel Burt 2009-12-30 22:32:21 UTC
Ok, the file is variable bit-rate.  The first bit-rate is indeed 128kbps, but then it switches to 104, 96, 92, etc etc.

In the comment of that else if clause I mentioned in comment #3, it says:

// Since there was no valid Xing or VBRI
// header found, we hope that we're in a
// constant bitrate file.
Comment 6 Pupeno 2009-12-31 04:31:24 UTC
Is there any immediate workaround to get a better value for now? Any way to approximate it?
Comment 7 Gabriel Burt 2010-01-01 01:09:45 UTC
Not that I know of.  Would be interesting to check if GStreamer is indeed calculating it by looking at all frames - and if it does that b/c it somehow knows the file is VBR (which seems hard to detect if there's no xing/vbri header).
Comment 8 Pupeno 2010-01-05 08:28:57 UTC
By the way, it seems Lame is not capable of generating the xing or vbri headers. Considering how popular Lame is, I would say there are a lot of broken MP3s out there.
Comment 9 André Klapper 2018-08-17 19:50:20 UTC
taglib-sharp has moved to Github a while ago.
Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org.

If the problem reported in this Bugzilla ticket is still valid, please report
it to https://github.com/mono/taglib-sharp/issues instead. Thank you!

Closing this report as WONTFIX as part of Bugzilla Housekeeping.