Maybe this is too much work, but has anyone tried altering the split point to coincide with the closest zero-crossing for both channels to reduce the problem?  For me this would be a far better solution than bloating all the audio data with 320 kbit frames.  Perhaps just a setting to force 320kbit frames on just transitions that have a lot of energy?

Pcutmp3 gives perfect gapless mp3 playback in foobar2000 but the files don't work properly on my portable players (iPods and Clip+).

Unless it's rejecting the large enc_delay values from pcutmp3 (fb2k used to do that), I'm inclined to think that any player that claims to be gapless but chokes on pcutmp3 files is pretty hopeless.

My experience with my Clip+ and lame mp3s is that it's trying to have smaller gaps than my old Clip, but it would be a joke to call it gapless. I'm not worrying about the "right" way to make gapless files until the player demonstrates at least the possibility of doing things properly.

Cheers,
David.

Maybe this is too much work, but has anyone tried altering the split point to coincide with the closest zero-crossing for both channels to reduce the problem?

You mean before mp3 encoding? That could help a lot. You have to move beyond per-track encoding though - to encode track Y, you need the audio data from tracks X, Y and Z.

It would be possible to check where the mp3 frames would lie, keep the original track transition points (using approriate enc-delay and duration tag values) but fade out the audio between the "real" end of the track (given by enc_delay + duration) and the end of the final mp3 frame. That should encode far more cleanly.

You still need more than the current track's audio data though - once you get into that, you might as well just do it "properly".

For me this would be a far better solution than bloating all the audio data with 320 kbit frames.  Perhaps just a setting to force 320kbit frames on just transitions that have a lot of energy?

Wouldn't that be fun to tune - for a given basic setting, when and how much should lame boost the bitrate on the first and last frames to avoid audible glitches. I think it's a great idea - maybe it can be made "good enough" on "the most commonly used settings" without too much work.

Cheers,
David.

For me this would be a far better solution than bloating all the audio data with 320 kbit frames.  Perhaps just a setting to force 320kbit frames on just transitions that have a lot of energy?

Wouldn't that be fun to tune - for a given basic setting, when and how much should lame boost the bitrate on the first and last frames to avoid audible glitches. I think it's a great idea - maybe it can be made "good enough" on "the most commonly used settings" without too much work.

Do you really think that a couple of 320 kbps frames would increase the overall bitrate significantly? I suggested the use of 320 kbps frames over a month ago in this same thread:

I wonder if a VBR encoder could have a mode that would use the maximum possible quality for the first and last frame (and maybe gradually change to the normal quality during a few following/preceding frames). It could make some track transition problems less pronounced without increasing the file size significantly.

The first and last frames in the VBR mode would then always use -b 320 or what ever is the "safest" setting to produce clean track transitions. In case of the LAME encoder, probably the LAME developers would know what tricks if any would be needed for the few preceding/subsequent frames when the encoder changes to the normal VBR behavior. It could be named as a "safer gapless" switch or something like that.

However, Case's "Fake Gapless DSP" solution is brilliant. It seems to always work and if it has any effect to the resulting bitrate it will reduce it. That kind of DSP feature could be included in the LAME encoder. For now, foobar2000 + Fake Gaples DSP can be used for creating truly audibly gapless files.

EDIT: BTW, has anyone noticed this problem with AAC, Vorbis, or Musepack files?

Here is the transition point of the above posted samples (m1 and m2) encoded with lame 3.98.4 -V5 (~140 kbps):

http://i.com.ua/~alexeysp/mp3.png

Here is the same transition of the same samples encoded with Vorbis aoTuVb5.7 -q2 (~96 kbps):

http://i.com.ua/~alexeysp/vorbis.png

The winner is quite obvious.

I've tried out the samples with LAME 3.98.4 at -V0 and LAME 3.97 at -V1 --vbr-new.

I found my LAME 3.98.4 encode has a very small pop at m2, but its abit hard for me to notice though. While my LAME 3.97 encode seems to decode the samples without any pops.