This is not explained in the official guide, because majority of "hardcore" dumpers started to use real Plextor drives and therefore manual method was considered obsolete...
When in the pregap there is at least one entire scrambled data sector (=2352 bytes/588 samples) or more scrambled data with a visible header, first visible header should be observed very carefully.
Requested sector is 22:19:25, and because that sector is marked as audio by the subs drive won't correct the offset. Neither unscramble data.
Drive provides a part of 22:19:20 and the beggining of 22:19:21, that header you can see. Drive is reading 4 sectors before than expected, plus 2324 bytes (because sector 22:19:21 [23:99:21 in scrambled form] starts at 0x914 offset in that screenshot).
2352*4 bytes +2324 bytes = 11732 bytes. Read offset of drive used: +6 samples, +24 bytes.
(11732 bytes - 24 bytes)/4 bytes per sample = 2927 samples, the expected one and verified via a real Plextor drive:
With the classic way, user will see that there are 16436 bytes of scrambled data, so that will think that offset once subtracted the read offset of the drive is 4103 samples. Very wrong, because in that pregap there are two scrambled data sectors which belong to the audio track.
Sample of pregap used, untouched and the valid sectors unscrambled, being 22:19:21 the first one.
https://www.dropbox.com/s/t0h467nl9y84v … 0offset.7z
Once properly detected and configured the offset, any drive should dump the very same audio tracks, if there are mismatches (without taking into account read errors themselves):
-First audio track with data in the pregap. In the posted example, if you delete the first 11732 bytes matches the pregap extracted via a Plextor drive and cdtoimg-d8. Sometimes pregaps with scrambled data sectors can be recovered by extracting the pregap range via IsoBuster, adding a few of extra sectors to correct the offset. In this case, extracting 100300-100460 (10 extra sectors to overdump a little) sectors, deleting the first 11732 bytes and resizing the bin so that size is 352800 bytes (deleting now useless data from the ending, not from the beggining). That would be the pregap with data, which could be pasted into the track dumped by EAC to restore it.
-Gaps badly detected, use another drive or another method of detecting gaps in the drive's properties, until getting gaps which make sense. And always configure EAC to analyze EAN aka MCN aka CATALOG and ISRCs, another thing not mentioned in the guide, to get more complete cues, because many discs have the typical CATALOG 0000000000000.
-Last track truncated. With a +667 drive it is somewhat likely that certain last tracks are truncated. Hot swap method (any useless [or not useless if you treat it well and carefully in the process] CDDA disc bigger (speaking of size in sectors) than the disc to dump is fine for that) and then you can run to recover the lost audio samples. Extract the first sectors of lead-out (previously known that sector, for Fury^3 is 191780) and replace the xyz bytes of the track dumped by EAC with the xyz bytes of the lead-out, where xyz is the combined offset for that disc/drive combination. An easier alternative would be another drive where combined offset for that disc is negative (for example, +6 drive for -22 and -12 discs, at least to dump the last track, never the first one unless you restore the possible missing data) or a drive which can overread into the lead-out.
For that drive:
C2 error reporting enabled.
Cache defeating disabled, because caches audio data under 64 KB of audio. 37/39 KB as far I remember.
And of course, makes use of Accurate Stream, because any decent drive since 1998~2000 offer Accurate Stream = constant and predictable offset, not something like +113 in a read, +115 in other, +116 in other... an 8x CD-ROM drive by Panasonic which jitters.
And try +667-12 for that disc, -16 samples isn't a common offset. -12 is.
To mount the image, don't forget to replace MODEx/2xxx with the proper one (MODE1/2352 or MODE2/2352, pretty obvious seeing the byte 15 of the dumped data track, 01=MODE1 and 02=MODE2) and replace every .wav" WAVE with .bin" BINARY, because audio tracks dumped following the guide lack of header.
CCD question: make a CloneCD dump and replace the img created with bins concatenated:
copy /b "Track 01.bin"+"Track 02.bin"+"Track 03.bin"+"Track 04.bin"+... "Name of the IMG.img"
Done, CCD image with the audio ripped securely and with corrected offset. And additionally sub could be replaced with the dumped by subdump if you care.
. MSF/AMSF to LBA/offset and viceversa calculator: linkTo write properly occidental characters contained in japanese titles: screenshotSpaces must be the fullwidth variant: link