search

vividos / winLAME

winLAME is an easy to use encoder for many audio formats, including MP3, Opus, Ogg Vorbis and more. (this is the Git repository mirror of the SourceForge.net Git repository)
GNU General Public License v2.0
40 stars 7 forks source link

Some flac to mp3 conversions show wrong duration time #7

Closed steelowheel closed 1 year ago

steelowheel commented 1 year ago

WinLAME 2021 Release 1 here, I just converted some flacs to mp3. Some resulted mp3 files show wrong duration time in foobar2000 v2.0 x64, and in also Windows 10 File Explorer. Interestingly fb2k and file explorer show different wrong times. The mp3 file plays to the real end, though. The original flac file and an mp3 conversion attached here: monty.zip

vividos commented 1 year ago

I'll look at it, but the LAME Info tag is written by libmp3lame. At least foobar2k should get it right, but the Windows Explorer Code can't handle reading the tag...

vividos commented 1 year ago

I did a few tests, and it seems there's something missing here. VLC can correctly show duration of VBR files. I guess they scan the whole mp3 file. foobar2000 doesn't do this, but offers a menu item "right-click > Utilities > Fix VBR MP3 header...", which fixes the duration for foobar2000. It does this by adding a Xing INFO tag that the unmodified mp3 file is missing, which is strange, since it should have been written by LAME...

vividos commented 1 year ago

I examined the Xing VBR tags that the LAME-produced and foobar2000-fixed files provide, and they are nearly identical and within the Xing VBR tag specifications. I also checked the files using ffprobe from FFmpeg and they report a correct playback time. So I suppose there might be an error in foobar2000. I'm closing the issue as I can't modify the LAME source code producing the tag and other tools can read the duration time correctly.

H2Swine commented 1 year ago

https://www.jwhitham.org/2023/09/system-shock-soundtrack-gapless.html seems to have found the issue with the files: 680 bytes of extra zeroes immediately following the tag frame. So the next isn't where it is supposed to be (or, is it interpreted as a frame that is 680 bytes too long?)

vividos commented 1 year ago

Interesting read! I think you should bring this up to the LAME folks, as this should be fixed in the libmp3lame library.

H2Swine commented 1 year ago

This post identifies it as a winLAME issue: https://hydrogenaud.io/index.php/topic,124803.msg1033309.html#msg1033309

vividos commented 1 year ago

Ok I'll have a look.

vividos commented 1 year ago

This is fixed from version 2.23.0.136 on.