#88 tag and encoding bug

[Anonymous]

V1.0.22 Win7 64/32

If ID3v1 tags are not enabled alongside all others, then any file encoded (tested with FLAC and WAV) into mp3 using LAME 3.99.5 will be slightly shortened at the end compared to the original file. This can be easily seen in tracks on CDs that are supposed to flow into the next one. Exact measure of time(data) lost is a little difficult to determine, but small; measured using Audacity after aligning, due to LAME adding a bit of silence at the beginning of the track, and zooming into original file and converted one in parallel.
It would seem that the issue can be fixed by editing ID3v1 tags, without necessarily removing others, into converted file using a dedicated, separate, program. It is, however, something that does affect the sound at the end of the file if submitted to playback on dedicated players.

Custom test settings (these I use, but have tested with a couple presets with the same result)
-CBR
-320kbps
-set quality 0
-Stereo Auto
-only Original bit enabled
-default APH
-Temporal masking enabled
-Auto output sampling rate

Note: haven't found any information about this error being native to LAME, though the possibility exists, and I have yet to test the compiled (rarewares bundle) LAME to contrast.

[Robert Kausch]

Hi, there is no problem with fre:ac or LAME here. The effect you are seeing is entirely because of Audacity not supporting gapless MP3.

You can verify this by decoding one of the MP3s created by fre:ac to WAV using an application that supports gapless MP3 first and then inspecting that WAV file using Audacity. You will find that it perfectly aligns with the original.

Converters that support gapless MP3 are (for example) foobar2000, Winamp and of course fre:ac itself. Your MP3 files will also play without gaps in players with gapless support including foobar2000 and Winamp.

If you have a hardware MP3 player that does not support gapless playback, there's not much you can do about it. If you do not want to get a different player, your only chance is using WAV or FLAC (if supported by your player) instead of MP3 for gapless albums. Gapless MP3 playback is not quite straightforward to implement, so there are lots of players that simply do not support it.

[Anonymous]

I understand, thank you for your response. However, if it is not much trouble, do you have any idea why the inclusion or not of ID3v1 tags is the factor that causes with it?

[Robert Kausch]

When decoding MP3, the decoder library prepends a silent frame and always stays one frame behind the data fed by the application. This is called decoder delay and is necessary in order to apply some psychoacoustic processing filters while decoding.

Because of this delay, it is necessary to flush the decoder buffers after decoding in order to get the final audio frame. This is what Audacity currently fails to do.

So why does it make a difference then whether an ID3v1 tag exists? When such a tag is appended at the end of the file, Audacity will feed it to the decoding library. The library, however, cannot handle it and treats it as an invalid MP3 frame, causing it to flush its buffers and return the last valid frame to the application.

I'll see if I can write a patch for Audacity to fix decoding of the last frame. Maybe also to add support for gapless decoding. fre:ac uses the same decoder library as Audacity, so I should be able to implement it in a similar way.