Looking at early results from myself, Quzar and BlueCrab over DCEmulation, it looks like your Dreamcasts both have very early firmware revisions (both have pre-Japan launch dates)
This might be a plausible reason for the dumping problems you have had, especially the data track sync thing (who knows, it might have been one of the things fixed in later firmwares)
Also, it strengthens quite a lot the possibility of your Dreamcasts having a drive with different offset, explaining the audio mismatches too. IIRC, early models were built somewhat differently. Not sure of the exact differences, but I think they had heat pipe cooling and (possibly) a different drive. Wonder if anyone can confirm if it is known that the drive manufacturer had changed at some point.
I think we are getting closer to identifying the problem.
Here's my current theory:
All PAL DCs and probably all US too will have later firmwares, which have none of the dumping problems you identified. They had plenty of time to iron out early firmware problems before the Western launch dates and maybe they even changed the drive completely.
It's possible that some early Japanese and Asian models might have the earlier firmwares and/or different drive offset, resulting in problems getting tracks with the correct checksums, apart from the last data track.
This should also easily explain what happened in this thread:
http://dumpcast.thekickback.com/forum/v ... .php?t=353
Yamada also had problem getting a correct track01 with his first DC and darcagn replies there's a single byte difference. Thankfully the files he uploaded are still online and I did the comparison. Guess what? The problem is again in sync field of last sector! Also, audio offset is again 452 bytes or 113 samples! Then he gets a 2nd DC and matches our dump. I believe his first DC was old revision and the other one he got was newer and dumped it correctly.
But I think the dumping problems can be attributed to early firmwares. Looks like the problem affects only last sector of a data track followed by audio track, hence the last data track always gets a matching checksum.
Back then, we dismissed the problem as a single issue with the specific console Yamada had, but in light of the gathered information I am strongly inclined to believe that a few early JPN/Asian consoles exist that dump data tracks wrongly due to early firmware and possibly they also have a different audio offset.
Maybe this also explains why the project has a bad name in Japan, according to Yamada's other posts.
If some of the users there have older DCs, they only get matching checksums for the last track.
Of course all these theories will need investigation and I'd love to see more dumps done with early firmwares. It could prove me wrong. If Yamada or other Japanese people or owners of Japanese/Asian Dreamcasts are reading this, please supply information.
Before anyone asks:
In any case, even if my theory is proven correct, it won't affect our dumping checksums or method.
The data track error (currently attributed to early firmwares) is unquestionable (sync field is standard as I already described) so we can't accept these dumps as correct in any case. Since different audio offset seems so far to always be coming together with bad data track dumping, it's not an issue either.
The DCs with newer/fixed? firmwares seem to be dumping in a very consistent manner all the time, regardless of region.
Unfortunately, I doubt there's anything that can be done for fixing the issue with early models, apart from hacking the resulting files to comply. The good news for anyone having them is that the files will not be affected adversely for emulator use. They can't be made compliant with TOSEC checksums without hacking, but they are actually working properly. Data track error is at a place where it won't affect the emulation at all.
Awaiting more info, as and if we get it.