Well, my observations on a boring Christmas Eve after the family is soundly sleeping...

*** Test #1 - MP3 files ***
Setup
Encoded tracks 2 and 3 of Pink Floyd's Echoes (our samples seem to be skewed towards Pink Floyd don't they? ). Previously I had used 128k CBR without --nogap, now using 128k CBR with --nogap. The first set (without nogap) have ID3 tags, the second do not.
2.0b3 behavior
Gap was pressent between MP3's without the --nogap option. I toyed with the --nogap while running 2.0b3 but I gave up on it when I heard that there was skipping/gaps for other reasons (player bug.)
2.0b7 Results
I notice no difference with --nogap at all, at least no beneficial one. If anything, the gap might actually be a little more with the --nogap. Why this might be is anyone's guess. Since --nogap is undocumented and doesn't provide any feedback or anything, it's hard for me to say whether it even did anything to the MP3. But there are still gaps with both sets of MP3's. Keep in mind, as I said earlier, the skip between tracks got much smaller in this release, so this isn't a complaint.

*** Test #2 - WAV files ***
Setup
Sent over the WAV files to negate the effect of MP3 frame boundaries, etc. In theory if the player is doing its job, there should be *no* perceivable gap. WAV files have no headers or anything.
2.0b3 behavior
There was a skip between WAV files. Said to be due to a player caching bug of some type.
2.0b7 Results
Huzzah! Nary a gap to be heard. None at all. Completely gapless output. This is a first.

*** Test #3 - MP3 with --nogap and -t ***
Setup
Around this time I noticed during this testing that LAME adds a "lame tag" to each file. This doesn't seem to be an ID3 tag. I found that it can be turned off by adding the -t switch to LAME. So I encoded with --nogap and -t to see what happens.
2.0b3 behavior
Not tested.
2.0b7 Results
Better! Seems to be less gap than without the -t switch. It seems (from my observation) that this LAME tag widens the gap a little bit. Dunno if the "lame tag" is important, but it makes true gapless output difficult unless the decoder is smart enough to skip over it.

*** Test #4 - MP3 with just -t ***
Setup
So I thought that since -t cleaned up some of the gap problems, that maybe --nogap was doing more harm than good. Took off the --nogap and tried again.
2.0b3 behavior
Not tested.
2.0b7 Results
Gap was worse. So --nogap seems to be beneficial in some way. Using only the -t option yielded files with a larger gap than those encoded with --nogap -t.

Conclusions
1. LAME --nogap isn't ready for prime time.
2. The Empeg player seems to be doing its job with WAV files, and assuming that there aren't any differences related to how it decodes and buffers MP3 streams, we can place the blame for that little tiny skip on LAME.
3. Adding the -t option to not automatically add the LAME tag seems to minimize gaps.
4. Adding the --nogap option on its own didn't seem to change the gap (to me anyway.)
5. Using both --nogap and -t provides the best results, but a small gap is stll left behind.
6. In 2.0b7, WAV files play without gaps *flawlessly* so LAME must be the guilty party barring some idiosyncracy in Empeg's handling of MP3 vs. WAV.


Anyway that concludes my scientific study on gap removal. Class dismissed. Time to get visions of sugar plums dancing in my head.