variable rate mp3 have wrong length

[Maxim Levitsky]

Binary package hint: rhythmbox

When I play variable bit rate mp3s in rhythmbox, the progress bar shows incorrect file length
Sometimes it is shorter that actual song, and progress bar stops at the end of it, but song continues to play, sometimes it is longer, and song stops playing before it reaches the end.

Happens with all my mp3 that are vbr encoded.

ProblemType: Bug
Architecture: i386
Date: Thu Sep 18 16:50:14 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/rhythmbox
NonfreeKernelModules: nvidia
Package: rhythmbox 0.11.5-0ubuntu8
PackageArchitecture: i386
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: rhythmbox
Uname: Linux 2.6.27-rc5 i686

[Pedro Villavicencio (pedro)]

thanks for the report, does teh same happens with totem? could you attach one of those files to the report for testing with it? this is more like a gstreamer issue rather than a rhythmbox one.

[Maxim Levitsky (maximlevitsky)]

Nope, totem shows correct length.

It shows in properties window a bitrate thought, while for VBR files it shouldn't.

[Maxim Levitsky (maximlevitsky)]

I did more tests.

Totem seems to update music file length on the fly
It also shows incorrect bitrate and length during first few seconds of playback, but then updates the information
to reflect right length and average bitrate.
Or in other words it determines the length, "on the fly", and it is correct
On the other hand rhythmbox only queries length once, and never updates it

I hope this helps.

This happens here with all MP3 that I have
(All MP3 were recorded as WAV from TV card, tapes, etc, And were converted to MP3 using gnome's soundconverter.)
I don't think I can post a mp3 due to copyrights

[Sebastien Bacher (seb128)]

could you open the bug on bugzilla.gnome.org where people writting the software will read it then? you can easily reply to their comments which is not the case of ubuntu bug triagers which don't get the issue and have no example to try

[Maxim Levitsky (maximlevitsky)]

Done,

http://bugzilla.gnome.org/show_bug.cgi?id=553468

[OnlyWhisky (alexeisergeev)]

I'd like to approve that this bug happens on amarok2, kaffeine and dragon player on kubuntu hardy. It seems like systemwise problem, not player bug.

[Maxim Levitsky (maximlevitsky)]

But doesn't happen in totem.

Any update on this?

[Maxim Levitsky (maximlevitsky)]

Happens in interpid

[HolgiT (holgit)]

Problem persists, but a workaround exists: Rhythmbox takes into account the TLEN information in the ID3v2 tags if present.

[Maxim Levitsky (maximlevitsky)]

Still happens in karamic

[jimmy the saint (lowid95)]

I believe this has to do with the VBRI headers in many mp3 files today. I installed mp3diags and had it strip out the VBRI header and replace it with the Xing headers and now the length is fine. Just thought I'd share.

[ubuntolo (ovitaerc)]

I can confirm this happening in Karmic, Totem shows the wrong length at startup, but after a few seconds it updates the value correctly. This bug also produce an annoyng problem, because when the length is wrong you're not allowed to use the seek bar to move inside the song.

[corristo (corrmage)]

I can confirm this bug. It also brokes last.fm scrobbling :(

[Marcos Magalhães (marcos-daekdroom)]

I confirm this on Lucid.

[tedmar (tedmar)]

The problem must not be in Ubuntu; in Windows, in Ubuntu 8.10 and in my Nokia 5800 phone the length for tha same song is incorrect

[jushirouuki (jushiroukitakex)]

Jimmy The Saint is correct, the bug is VBR MP3s. I really do like how this bug has been opened for two years and has yet to be fixed. Hell, the guy who filed this ticket knew from the very beginning it was VBR MP3s causing the problems and there still isn't a patch submitted upstream? I really like how bug reports are treated in these parts -- even low priority ones. That makes me feel better about the software I use on my day-to-day basis.

[Markus Pointner (mooware)]

I can confirm it on Maverick.

[GNUbee40 (docnino)]

This problem seemed to have been fixed in Jaunty 9.04 and, for me, has reappeared in 10.10. It seems that bitrates are now only showed in discrete values of 32, 64, 128, 144, 196 and so on.
Interestingly, VLC shows different overall-bitrates than Rhytmbox and Nautilus. But when looking further in Functions - Media Information - Statistics, VLC also shows the bitrate of Indata with the same wrong value.
Once again, in Jaunty the bitrates were shown in continuous numbers, each song had its own bitrate, so VBR files were clearly read correctly. When did this regression occur - and how?
BTW, WMP mostly misreads the length and bitrate of VBR MP3s as well, while Winamp reads them reliably.

[Ray DeCampo (rdecampo)]

I am still seeing this bug in 12.04, any chance it gets addressed?

[Andras Beck (betamx)]

This bug is still present in version 2.98 under ubuntu raring 13.04. Seeing the importance set to LOW, while 5 years passed from the first report, is outraging.

Most of my files are vbr encoded mp3, and I cant check song duration, cant jump to a position in song, or see where the current playing position is, because rhythmbox shows incorrect duration for mp3 songs encoded in variable bitrate. This is unacceptable for a media player, and should have been resolved years ago.

I hope you recognise what a major bug this is. I really like your player, but unfortunately this bug makes it neccessary to have another player, so I can jump into vbr encoded songs too.

Other than that keep up the good work, your player is still one of the best.

[Andras Beck (betamx)]

up

[Andras Beck (betamx)]

Yay, compiling from the latest source code solved the problem for me.