#80 Improper time when using quality to encode.

[Dead1Walking]

I noticed that when encoding using advanced options and selecting quality, the reported length of the file is incorrect. Something by a couple seconds, other times by many minutes.
Upon looking into this, I found a program called MP3 Diags. This reviled that the Xing header is not in the proper position. I don't know if that is the only thing that is an issue, however option to fix this corrects the reported length.
I listened to every file after the fix, and they all play correctly and I can properly jump to a point in the song.
I don't know if this is something with the program, the lame encoder, both, or something else. However, I want to mention this as if it can be fixed that would be great instead of relying on another program to correct files when I decide to encode using this method.

[Michael Fink]

Thanks for your bug report! Could you test by also encoding with LAME 3.100? What does the MP3 Diags file say? And can you attach some encoded files (one of the windows .wav files encoded as .mp3 should be enough)? Thanks!

[Kera]

I would like to assist on this topic to help improve your great application.

Tests with the file "Windows Logon.wav" from windows-folder and winlame 2020 release 1. "Custom settings", "q0" and high encoding quality (see screenshot 00-...).

Windows explorer is showing wrong duration (see screenshot 01-...). Just like Kodi 18 (on Linux), Musicolet (android). But Winamp and VLC show the correct duration.

MP3 Diag complains about a NULL-stream (screenshot 01-). Fixing this (screenshot 02-) results in a removed NULL-stream with correctly displayed duration in Windows (screenshot 03-...)

Using lame.exe with -V0 results in a file with a duration that is always displayed correctly.

But "null-stream-is-evil" would be too easy... the same file compressed with winlame-preset "Archiving: Best Quality" also contains a NULL-stream, but duration is always displayed correctly.

Anyway, i hope that helps a little.