Bug #472
VBR seeking problems in relation to LAME/Xing header (libmpg123?)
0%
Description
I have had some problems with Audacious and VBR files for some time now, so I decided to take a look into it.
The problem in question here is displaying track-length and seeking. Seeking does not work and track-lengths are way overestimated.
VBR files are very hard to estimate in length, that's why they really can't go without a header, holding the track-length. The header used for this is the Xing/LAME header.
Using mp3diag I've been playing around with these headers, and I found this: VBR files only having an mpeg stream are played equally bad (no seeking, skewed estimation on total length) as when having a Xing header. The very same VBR file having a LAME header however, is played fine.
But the funny part is this: A LAME header is an extended Xing header. A Xing header is an non-mpeg frame holding other data; a LAME header is the Xing header with some extra data in what would otherwise be zeroes (mpeg frames have a specified length, right?).
Possible solution: My best guess is that Audacious does not parse the header unless the LAME part is in it, regardless of the data required to make VBR work being there. (The data required for proper VBR playback is not in the LAME-part but the Xing part.)
BTW, VLC and gstreamer play and seek VBR with Xing and LAME header both fine. VLC goes even as far as being able to seek a VBR stream without any header. However it keeps recalculating total length in that case.
History
#1
Updated by John Lindgren over 9 years ago
Updated by Please upload an example file.
#2
Updated by Maarten van Eeuwijk over 9 years ago
Updated by - File Audacious-mp3diag-VBRseek.7z.001 Audacious-mp3diag-VBRseek.7z.001 added
- File Audacious-mp3diag-VBRseek.7z.002 Audacious-mp3diag-VBRseek.7z.002 added
Just tested both files with Audacious 3.5.2, problem still exists (Arch). As does it in the 3.2.4 version (Debian-Wheezy).
For those who don't know mp3diag, it can be found here: http://mp3diags.sourceforge.net/
#3
Updated by John Lindgren over 9 years ago
- Status changed from New to Rejected
I can confirm the problem. Thank you for the good analysis and the test files. Please forward this report to the mpg123 project (http://sourceforge.net/p/mpg123/bugs/) since it is libmpg123 that handles the actual MP3 parsing, including the Xing and LAME headers.
#4
Updated by Maarten van Eeuwijk over 9 years ago
I've had some contact with the libmpg123 project and one of their programmers. Here are the results:
- According to Thomas Orgis from mpg123 the test file that fails (the one sporting only a Xing-header) has no TOC. That had not been taken into account when the parser was written. He later fixed this and the fix should now be in the svn snapshot of libmpg123.
- With this fix applied, libmpg123 should now also read files with a Xing-header just fine. However in the event a bare VBR mpg-stream is encountered, the very same problem described above would arise. This however requires some pluming in Audacious to fix. Thomas suggests to use mpg123_scan() when local file && not too big && might be VBR && has no header. Or add it to a options menu, for the event the user notices the header is b0rked. The function mpg123_scan() builds an index independent of any headers.
- Thomas Orgis also is very curious about whether or not his fix has done the job.
