Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 110318 - media-plugins/xmms-mpg123 displays incorrect length for VBR files
Summary: media-plugins/xmms-mpg123 displays incorrect length for VBR files
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Luis Medinas (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-24 06:18 UTC by Henrik Davidsen
Modified: 2006-04-06 08:31 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
xmms-mpg123.patch (xmms-mpg123.patch,650 bytes, patch)
2005-10-24 06:24 UTC, Henrik Davidsen
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Davidsen 2005-10-24 06:18:14 UTC
The mpg123 input plug-in for XMMS displays an incorrect song length for some 
VBR files. Usually, the length is around two times the correct length.
Comment 1 Henrik Davidsen 2005-10-24 06:24:11 UTC
Created attachment 71329 [details, diff]
xmms-mpg123.patch

Patch to fix the problem described above. This patch must be applied after the
Gentoo patches.
Comment 2 Thomas Cort (RETIRED) gentoo-dev 2006-01-17 22:42:00 UTC
While researching the implications of your patch I came upon two VBR related bugs[1][2] on the xmms bugzilla[3]. One has a patch[4] for the mpg123_get_first_frame function in mpg123.c, the same function your patch changes. The one thing that the patches both have in common is that they stop the program from overwriting the contents of frm, which has the decoded frame header information for the first frame, with the decoded frame header information of the second frame. (Why would they want frm to have the second frame header information when the function is called mpg123_get_first_frame and the returned 'buffer' contains the first frame's data?)

The reason why overwriting frm causes the problem for some files and not others is that the part which reads the frame into 'buffer' uses frm->framesize. If 'frm' is overwritten with the decoded second header, then the framesize for the second frame is used. If the second frame is smaller than the first framesize, then not all of the first frame will be stored in 'buffer'.

It should be noted that when I write framesize in this bug report and when the code says framesize, it really means frame length. The framesize member of the frame struct is calculated and used for seek()'ing. Therefore, it refers to frame length. See this[5] for the difference between frame size and frame length.

I haven't been able to reproduce the problem that you are having, so I cannot test the patch, but I believe, from studying the code, that a problem does exist. Could you please attach to this bug a small VBR file that exhibits the problem you are having?

Thanks for the patch!
~tcort

[1] When playing a VBR stream title info isn't working properly
http://bugs.xmms.org/show_bug.cgi?id=397

[2] Bitrate info and VBR (mp3)
http://bugs.xmms.org/show_bug.cgi?id=2186

[3] XMMS Bugzilla
http://bugs.xmms.org

[4] mpg123_get_first_frame.patch
http://bugs.xmms.org/attachment.cgi?id=325&action=view

[5] See the "How to calculate frame length" section
http://www.dv.co.yu/mpgscript/mpeghdr.htm
Comment 3 Luis Medinas (RETIRED) gentoo-dev 2006-04-06 08:31:01 UTC
commited in the new patchset that is available on 1.2.10-r16