This sounds like an Apple problem.
We're not going to work on this anytime soon.
Jim,
If you look at ALL the evidence (and not just the recent test by prod by itself), it does NOT sound like an Apple problem. Tests results have already been posted showing that using iTunes for the whole process DOES result in proper gapless playback. A user named "coolblue" did some extensive test on this issue last october. Here are the findings from his post:
Ripping Software: iTunes; Upload Software: iTunes; Source: AAC; gaps evident: NO
Ripping Software: iTunes; Upload Software: iTunes: Source: MP3; gaps evident: NO
Ripping Software: MC12; Upload Software: iTunes: Source: MP3; gaps evident: YES
Ripping Software: MC12; Upload Software: MC12; Source: MP3; gaps evident: YES
Ripping Software: iTunes; Upload Software: MC12; Source: MP3; gaps evident: YES
Ripping Software: iTunes; Upload Software: MC12; Source: AAC; gaps evident: NA (did not upload properly, but that's another story).
Summary: When it's all internal to iTunes gapless playback works beautifully.
Regardless of what's been fixed in MC since then, one thing is clear from these tests; if you use iTunes for both ripping and synching, the problem does NOT occur, and you get proper gapless playback on the iPod. This was proven several months ago, and there is no reason to dismiss these findings now. As you can ALSO see from the results, as long as MC was ANYWHERE in the chain of ripping/synching, gapless playback did not work properly.
Just because LAME encodes still have the problem when synching with iTunes does NOT mean that this is Apple's fault since iTunes doesn't use the LAME encoder -- i.e. you can't blame Apple for gapless issues when you use a non-iTunes encoder. Apple has no responsibility to make LAME encodes work with iPod syncs.
That said, I still believe that LAME synchs CAN be gapless on the iPod -- I just think that there is a problem when converting the LAME header info to the iPod's gapless info. Everything seems to be pointing to this. If I knew more about this, I would compare the iTunes header info to the LAME header info. Unfortunately, this is WAY beyond my experience and I wouldn't know what to look for.
For some reason, we keep reverting back to square one with this issue. Some time goes by, and everybody seems to forget the tests that have already been run. Recently, prod synched a LAME encode with iTunes and it showed the same gapless problems as the MC sync. The conclusion made from this was that this is therefore a problem with Apple and not with MC. If you really look at the evidence, however, it does NOT point to Apple, but rather to something else (my guess is LAME encodes.) When you look at all the combinations above, you can see that the one thing in common with the failures is the LAME encode. This is the ONLY thing that all the failed tests have in common. Some fixes in MC have been made since then, and it's now possible that songs ripped with iTunes will be gaples when synched with MC (this hasn't been tested yet.) All we know for sure, however, is that LAME encodes STILL do not result in gapless playback regardless of whether MC or iTunes is used to sync. This does NOT point to iTunes or the iPod as the probelm.
I personally consider this a high priority, but I understand and accept that JR might have other issues that they consider more important. If this is the case, however, MC cannot claim "gapless playback" with iPod syncs. There might not be an actual "gap" of silence between tracks, but the songs do NOT flow smoothly from one to the next, which is what "gapless" means in this arena. iTunes encodes synched with iTunes ARE gapless, but MC encodes/synchs are NOT.
Thanks,
Larry
PS. We never did hear back about the files that coolblue sent in. Did these reveal anything?