foobar not gapless on MP3's encoded with LAME 3.94b Options

[jimbof]

I know 3.94b is an ancient version of LAME; however the files it creates appear to play gaplessly fine in both Winamp and XMPlay. In foobar2000 there is a noticeable glitch between tracks. Running "Fix VBR header" on the files appears to make them work again, but this is a bit strange as they are supposedly 320KB CBR (lame -b 320 infile outfile).
Files encoded with LAME 3.97 play fine without such "fixing".
Why is the fixing needed, and why doesn't this seem to affect two other popular players?
Many thanks!
James

[shakey_snake]

Can you upload sample files to the upload forum?

This post has been edited by shakey_snake: Sep 25 2012, 16:08

[jimbof]

Can you upload sample files to the upload forum?

done, a very short sample file uploaded, in original wav, 3.94b encoded mp3 and then the resulting mp3 after VBR fix.
sample files
Thanks!

[Peter]

Thanks for the sample file.

The LAME header of this file is obviously broken (nonsensical frame count).

Other applications may play this file gaplessly because they do not rely on the frame count field. foobar2000 could potentially cope with this but it still cannot show correct file duration (only possible workaround == scan whole file when reading tags, too slow to be feasible).
I recommend using the File Integrity Verifier component to detect such files in your library and then fix headers on them all.

I will keep this issue in mind, to be possibly fixed in some future foobar2000 update.

[jimbof]

I see that Foobar2000 shows the length of the WAV file as 53248 samples, and the length of the "fixed" MP3 as the same, but the original MP3 is shown as being 54400 samples - a difference of 1152 samples. This happens to be double the "ENC_DELAY" value. Probably not a coincidence? All the failing files seem to exhibit the same issue (1152 samples too long).

[jimbof]

I recommend using the File Integrity Verifier component to detect such files in your library and then fix headers on them all.

Thanks. Although that component spots the fault in these two files I just uploaded, it doesn't seem to spot the issue in all files I have, which seems weird.

[Peter]

1152 samples = MP3 frame duration. The header indicates file duration longer by one frame than it really is (I guess it counts the header itself as a frame which is against the spec).

[CoRoNe]

(only possible workaround == scan whole file when reading tags, too slow to be feasible).

Excuse my intrusion, but too slow for what exactly? Would this cause such a performance hit, even with today's computers?

[tpijag]

do you really want peter to work on this?

Version in question is 9 years old
File integrity component is available as already mentioned

[CoRoNe]

Not at all, I'm just looking for some info. I am allowed to ask, aren't I?

[Peter]

Do you really want your whole MP3 collection to be read from the hard disk when indexing your music library? It could possibly be bearable with modern storage devices in your local computer but certainly not on any network share; I can guarantee that would cause more annoyance than benefit.

[CoRoNe]

I can perfectly imagine in Foobar's case that undesirable, but in DC-Bass Source Mod's case (1 file at a time) I believe it wouldn't do much harm. I'm just trying to decide what I should do.