Bug 130945

I've seen this as well with Amarok 1.4.3, using the Fedora Core 5 package KDE 3.5.4-0.3.fc5.

The mp3s still play their full length in Amarok, but stop early when downloaded to an iPod. This occurs with, for example, this mp3:
http://audio.lugradio.org/season4/ep2/lugradio-s04e02-250906-high.mp3

There is a thread discussing the problem here:
http://forums.lugradio.org/viewtopic.php?t=1578

KDE used taglib to determine the songlength.

I had the same problems.

During the last weeks I put many efforts into hacking taglib.
I am happy to announce a taglib-1.4 hack release for that issue.

All MP3 VBR files should now have a correct song length, thus making it possible to use Amarok as an Ipod synchronizing tool.

Currently Amarok complies with taglib 1.4. My hack is binary compatible to version 1.4. Amarok does not need to be recompiled.

You can find my hack attached to this comment or on http://www.rafreider.de/taglib-1.4-vbr-hack.tar.gz
 

Tobias, you are THE MAN. I installed on my Feisty test system, she worked
like a champ!

On 4 Feb 2007 21:10:20 -0000, Tobias Rafreider <tobias@rafreider.de> wrote:
[bugs.kde.org quoted mail]



Tobias, you are THE MAN. I installed on my Feisty test system, she worked like a champ!<br><br><div><span class="gmail_quote">On 4 Feb 2007 21:10:20 -0000, <b class="gmail_sendername">Tobias Rafreider</b> &lt;<a href="mailto:tobias@rafreider.de">
tobias@rafreider.de</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">------- You are receiving this mail because: -------
<br>You reported the bug, or are watching the reporter.<br>You are a voter for the bug, or are watching someone who is.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=130945">http://bugs.kde.org/show_bug.cgi?id=130945
</a><br><br><br><br><br>------- Additional Comments From tobias rafreider de&nbsp;&nbsp;2007-02-04 22:10 -------<br>KDE used taglib to determine the songlength.<br><br>I had the same problems.<br><br>During the last weeks I put many efforts into hacking taglib.
<br>I am happy to announce a taglib-1.4 hack release for that issue.<br><br>All MP3 VBR files should now have a correct song length, thus making it possible to use Amarok as an Ipod synchronizing tool.<br><br>Currently Amarok complies with taglib 
1.4. My hack is binary compatible to version 1.4. Amarok does not need to be recompiled.<br><br>You can find my hack attached to this comment or on <a href="http://www.rafreider.de/taglib-1.4-vbr-hack.tar.gz">http://www.rafreider.de/taglib-1.4-vbr-hack.tar.gz
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Simon P Bassett<br>PC Tech<br>717-877-6021

should this be reassigned to taglib?

I would say yes. Once the patched version was used, the behavior certainly changed. However, the patched version showed other flaws (sorry Tobias). So it would seem that taglib is the underlying issue. 

> Hi all,
> I had downloaded some MP3s (MPEG 2.5 Layer III 11025 kHz VBR) and when I
> played it with Amarok, the total time listed in the playlist was double the
> actual time which led to all sorts of problems. I finally traced the source
> of the problem to taglib. I looked at the source (mpeg/mpegproperties.cpp)
> and calculated using its method and got the same doubled result:
>
> static const int blockSize[] = { 0, 384, 1152, 1152 };
>
> double timePerFrame = blockSize[firstHeader.layer()];
> timePerFrame = firstHeader.sampleRate() > 0 ? timePerFrame /
> firstHeader.sampleRate() : 0;
> d->length = int(timePerFrame * xingHeader.totalFrames());
>
> After lots of experimenting, I've come to the conclusion that the
> calculations don't work for resampled music (try using LAME and a 44100 kHz
> wav file and resampling to 11025 or 22050 kHz).
I did a bit more research and came up with this page: http://www.codeproject.com/audio/MPEGAudioInfo.asp
Under section 2.1.4, it has a table with blockSizes and it changes for Layer III MPEG 2/2.5 to 576 instead of 1152. So I guess you can either recreate the blockSize array into table like in the webpage:
 static const int blockSize[3][4] = {
 { 0, 384, 1152, 1152 }, // Version 1
 { 0, 384, 1152, 576, // Version 2
 { 0, 384, 1152, 576 } // Version 2.5
 };
 double timePerFrame = blockSize[firstHeader.version()][firstHeader.layer()];
or:
 double timePerFrame = blockSize[firstHeader.layer()];
 timePerFrame = firstHeader.version()>1&&firstHeader.layer()==3 ? 576 : timePerFrame;
or whatever... I don't really know what is more efficient... I'm just a first year CS student ;)

Woops... never mind, I think Tobias took care of it in his hack. Why wasn't it patched upstream i.e. what other flaws did it exhibit?

There's no special reason other than that I just haven't gotten to it yet.  The fact that it's a tarball rather than a diff also means that I can't just glance at it and see what was changed.  But it will be reviewed before the next release goes out.  (I've been short of time lately, but last weekend I did get a chance to go through about 10 of the reported bugs.)

Created attachment 20159 [details]
Tobias's hack in patch format (diff'ed to current svn tree)

I think only 3 files were changed in the tar file:
mpeg/mpegheader.cpp
mpeg/mpegfile.cpp
mpeg/mpegproperties.cpp

If I missed something... then oops :)

Note that taglib returns incorrect lengths for VBR MP3s that are encoded at MPEG 2/2.5 with a correct Xing header (see comment #6).

*** Bug 129098 has been marked as a duplicate of this bug. ***

taglib doesn't seem to be supporting the other VBR tag around there.
Fraunhofer VBR headers's format (VBRI) description is available here: http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx

In some situations (song length is too short, because Amarok started indexing the song during download/copy) the following work around helps:

- locate the song file
- remove the song from playlist
- move the song file outside the Amarok music folders
- wait until Amarok re-indexed the missing file
- move the song back to it's original location
- wait until re-indexing is finished
- add the song to playlist
- multiple files can be moved at once

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

Upstream bugs should go to 

https://github.com/taglib/taglib/issues

If your issue still happens with a recent release, please report it there, sorry that we did not inform you earlier about this change, seems it was forgotten to close this component for bugs here.