I'm having problems using the "Fix MP3 header" plugin to make FhG encoded files (that's what encspot reports) gapless. I have two tracks on an album that is "floating" into each other, and i want to make the transition gapless. First i run the "Fix MP3 header" command on both tracks, with encoder delay 672 and no padding. Then i run it again on the first track, rounding length in samples down to nearest multiply of 588. When i listen to the transition between the tracks now, the gap is smaller (but it is still there). So i keep subtracting 588 from sample count on the first track. But when i come to the point that i can't do it anymore (i get an error message: padding value too big), there is still a small gap. (very small, but it is there).

Could someone explain me what i'm doing wrong? Is the encoder delay i'm using wrong? I haven't had any problems making lame files gapless (using encoder delay 576) with this plugin.

Is the transition gapless when you're a listening to it with gapkiller plugin enabled? If not there's no way to fix it with the "Fix MP3 header" command.

Yes, it sounds gapless when i enable the gapkiller.

If you can still hear a gap after you've fixed the delay/padding info, re-check the files in the console with the gapless plugin turned on. I'm quite sure it will remove some more samples to play seamlessly. The special file info box automatically calculates the correct amount of samples necessary to round down to, by the way.

Did the console tell you the encoder delay was 672? For some FhG files I get 864.


Sorry if nothing's new. Good luck.

The gapkiller doesn't seem to remove any samples when i have tried to fix the files. I think i have removed more samples than the gapkiller would. The last time the gapkiller removes any samples from the end of the first track, it removes 408 samples. So when i substract 588 samples, the gapkiller doesn't remove any samples longer... (may i have created a new gap by removing too many samples?)

Before i run the header fix, the gapkiller will remove 674 samples, so i'm assuming the encoder delay of 672 is correct. (i have tried using 674 too, but the gap is still there).

Perhaps i'll have to give up. But thankyou for trying to help me.