Today I started dumping, and of course the first disc I grabbed from my stack threw me a curve ball.

Here's the story...

I have a plextor drive, so I decided to use px_d8 to detect the write offset of the disc. It gave me a rather huge offset, being +1206 for combined offset. I thought this was pretty insane, so I started to dig deeper. First I went ahead and dumped track 01 with IsoBuster, then I ripped the CDDA tracks with EAC with this offset. All seemed well, but this huge offset was bothering me somewhat, so after dumping a few other discs, I came back to it and decided to have a look.

I started at the reported raw sector of track 2, and since EAC decided the pregap was 2.00 , I went back 149 sectors. Looking at this sector, I decided something was wrong, because it appears to be a valid data sector. Ok... at this point I hadn't used resize to cut the gap out yet, so I backed up the raw track, and then dumped it again with my other drive. They were identical so something else was up. I will note now that all the other tracks have a gap of 1.74. This got me thinking a bit because of the apparently good sector, which when I cut the excess data with resize, was gone. I opened up winhex and scrolled to the offset, copied the sector, and put it back in to the cut version. I opened this up in CDMage and did an error scan, and as I thought it is a valid data sector. So... problem one is EAC did not correctly detect the gap. Allright then... I put the disc in 2 other drives on 2 different computers, and the results were the same. It detects the gap as 2.00 when it should really be 1.74 (150 vs 149 sectors). Ok... so that's one weird thing discovered and documented.

Next, I decided to figure out the write offset, put the disc back in my plextor and went to track 2, and went back 148 sectors. Hrm, this entire sector is full of random data, seems the offset is really is large... moved forward a sector... hrm, THIS sector is entirely full of garbage too... what's going on here. Ok, move forward one more sector... ah ok 120 bytes in the garbage stops and the 00's begin and continue until the start of track 2... ok this is good. Lets add that up.

2532+2532+120 = 5184
5184/4 = 1296

wait a minute... what's going on here? that's 90 samples longer than what px_d8 told me the write offset is. Uhm... now what? Is the combined offset 1206 or 1296 ??

Now I do not know what to do about this. Should I trust px_d8, or the method described in the dumping guide. Does one or the other method have a bug? Also... EAC is not detecting the track 02 pre gap correctly on 3 different drives on 2 different computers. Are these problems related, or not?

Curious as to anyone elses thoughts on this matter.

The game is Dark Reign the Future of War (C) 1997 Activision for IBM-PC if you want to compare notes.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

Probably this game was burned and dumped (with garbage) on a mastering stage, then burned back. The last 90 bytes of garbage should match the pre-last 90 bytes of garbage. If so, combined offset is 1206 and the first audiotrack does really contain 90 bytes of garbage as a part of the gap.