Bug 105128 - Length for variable bitrate mp3 files wrong
Summary: Length for variable bitrate mp3 files wrong
Status: RESOLVED WORKSFORME
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.2.3
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-05 04:58 UTC by Johan Brannlund
Modified: 2006-06-11 12:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Brannlund 2005-05-05 04:58:05 UTC
Version:           1.2.3 (using KDE KDE 3.4.0)
Installed from:    Unlisted Binary Package
OS:                Linux

I use the lame mp3 encoder to rip my cd's to mp3. By default, lame uses a variable bitrate which confuses amarok - the length reported is wrong, which also wreaks havoc with the ratings. Is there a reliable way of figuring out the length of such mp3's? Other players such as xmms and rhythmbox also get it wrong.
Comment 1 Mark Kretschmann 2005-05-05 08:25:40 UTC
Yes, the trick is to enable writing of the XING-header during encoding. This header contains the correct tracklength, which will be read by the player software.

Without the XING-header it's not possible to determine the correct length at the decoding stage.
Comment 2 Johan Brannlund 2005-05-05 19:54:28 UTC
Lame doesn't support XING, as far as I can tell. From the manpage:

       -t     Disable writing of the INFO Tag on encoding.
              This  tag  is  embedded in frame 0 of the MP3 file.  It includes
              some information about the encoding options of the file, and  in
              VBR it lets VBR aware players correctly seek and compute playing
              times of VBR files.

Also, mp3info manages to figure out the correct length:

$ mp3info -p "%f: %m:%s\n" 01*mp3
01 - In State.mp3: 3:56
$

I can understand if you're not terribly interested in implementing support for this tag, but if a patch for this feature is likely to be accepted I might give it a try myself.

Comment 3 Mark Kretschmann 2005-05-05 20:08:22 UTC
Well, that has little to do with our "will". We'll happily read this tag. The question is if TagLib supports it. Please check back with the TagLib author (wheeler@kde.org, hangs on freenode in #kdemultimedia as wheels).

If TagLib doesn't support it, the report should be reassigned to TagLib.

BTW: I'm wondering why lame wouldn't support XING. AFAIK it's a standard feature.
Comment 4 Johan Brannlund 2005-05-07 04:55:54 UTC
Alright, after doing some experiments it turns out that the problem seems to lie with the arguments for the gstreamer pipeline to lame that sound juicer uses - lame does actually support xing. In any case, it's definitely not an amarok bug so I'm closing this.

Just in case anyone with the same problem as me happens to come across this bug, a useful program for adding vbr tags after encoding is VbrFix, available at
www.willwap.co.uk/Programs/vbrfix.php

Sorry for the noise and thanks for an excellent player!