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 623409 - mp3 wrong duration decreasing to the correct one during playback
mp3 wrong duration decreasing to the correct one during playback
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
unspecified
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-02 15:58 UTC by Nicolò Chieffo
Modified: 2010-07-03 14:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicolò Chieffo 2010-07-02 15:58:41 UTC 
Hello I have a mp3 file which is actually 3:06, but when I start it in any gstreamer players (totem, banshee) the detected duration is much higher (for example in totem-video-indexer I get 25:26)
While playing, the duration progressively decreases to the correct value (reached only almost at the end of the song).

example mp3: http://dl.dropbox.com/u/989015/example.mp3
Comment 1 Sebastian Dröge (slomo) 2010-07-03 14:35:26 UTC 
That's expected and can't be easily fixed for VBR MP3 files without a valid VBRI or XING header. Problem is, that you can't know the duration unless you look at the complete file.
Comment 2 Tim-Philipp Müller 2010-07-03 14:51:44 UTC 
Part of the problem is lack of API GStreamer side. We don't provide a way for apps to say that they care about duration accuracy, or for apps to query the reliability of the duration returned. Apps don't even know if the duration is an estimate or based on an index or stream-embedded timestamps. This is something we're well aware of though, and there are bugs open for this elsewhere, see e.g. bug 564749 comment 23.