DiscImageCreator (Page 34 of 141)

After some even more deeper tests here are my results:
1) Audio tracks are properly offset corrected in D8 mode. In BE mode audio tracks are not offset corrected.
2) Data tracks: DIC seems to have problem with VOB Protect CD and D8 mode. I also tested a SafeDisc 1.00.026 and tracks are correctly dumped using both D8 and BE. For VOB discs I'm reripping data tracks in BE mode and the results are CloneCD compatible which I think is desired. In D8 mode VOB protected sectors have corrupted sync and header areas and DIC is not able to descramble them. OTOH in BE mode such sectors are replaced with 55 pattern. Maybe DIC should also replace such sectors with scrambled 55 pattern?

I have a Settlers IV CD that seems to expose another issue with D8 command. Some sectors (variable count) after C2 sector are not read correctly. I'll be investigating the issue later. But I think the conclusion is that D8 ripping is not reliable in case of C2 errors.

Sorry, I have no time to code it for a while because I'm busy with other thing...

Added.

Small bug using data mode:

E:\DiscImageCreator\Release_ANSI>DiscImageCreator.exe data i "Unreal Mission Pack I - Return to Na Pali" 16 0 331789 /c2
(...)
Allocating packed memory for C2 errors: 8192
Set read command: 0xbe, subcode reading mode: Raw
Checking SubQ ctl (Track)  1/ 1
Creating bin from 0 to 331789 (LBA) 331788

No C2 errors
Exec ""E:\DiscImageCreator\Release_ANSI\EccEdc.exe" check "E:\DiscImageCreator\Release_ANSI\Unreal Mission Pack I - Return to Na Pali""
[F:main][L:690] GetLastError: 2, The system cannot find the file specified.

Freeing allocated memory for C2 errors: 8192
End time: 2016-08-02(Tue) 20:47:08

DIC forgets to add .bin to the EccEdc command line.
Manually running

EccEdc.exe check "Unreal Mission Pack I - Return to Na Pali.bin"

works

sarami, I think you can test this with plextor drives also. Just don't read the disc in scrambled mode.
This is what already happens when you use DIC with the "data" and "audio" options. We're only missing the option of reading a mixed-mode disc.

DiscImageCreator.exe cd f: DISC 4 /rc /c2 20 /d8

And watch out for C2 errors
Always look at mainError file

If nothing pops up the dump should be good. Watch out for protected discs.

Ok, here are the DIC logs from http://redump.org/disc/37976/

Link: http://hotfile.mobi/fqj6g59
Pass: __http://redump.org/disc/37976/__

The key problem here is that there are two data tracks and the last data track has corrupted sync and is not picked up by edcecc. Also edcecc does not seem to repair sectors if header is different than 00 FF .. FF 00. In order to dump this game I modified edcecc to replace the sector with 55 pattern if sync is different than 00 FF .. FF 00...

Other games have the same protection pattern except for http://redump.org/disc/37856/ (you didn't list this game). In this case there's no 2nd data track but the corrupted sync headers are embedded into middle of the image. Also 1st track contain 2nd track pregap. My custom edcecc does not replace sectors in pregap area (there was a bug in 1st revision - watch out for this)...

Example: 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF C0 02 97 21 66 16 7C B4 CF 98 2A C3 DF 7E 66 11

It looks like D8 is more appropriate. BE seems to fail 6 sectors to recover from bad sync? Probably is a drive / firmware dependent...

Could you read sectors 341222 -> 341227 in BE mode but starting with 341222 (maybe seek to sector 341230 and start reading from 341222)? Dunno if this makes sense but it could test the drive how it reads sectors that failed in previous attempt.

Meh, no, it's a bad mastering afterall, very similar to http://redump.org/disc/34036/
First 88706 sectors are correct, the next sector has 1104 bytes of data, then 7508 bytes of zeroes, then it goes data again, but, of course, shifted by 7508 bytes. The first 7508 bytes of the audio track also belong to the data track.

So the DIC dump is as correct as possible, though, the image is non-functional in this form

If to cut that 7508-bytes sequence of zeroes and glue them to the end of the 2nd track, then split the image and descramble the data track - the image doesn't have any errors and the audio track doesn't have any incorrect data.

I did some tests with "data command" and different drives. Some drives doesn't work with DIC.
Here my test result, if possible fix error. Drives can be used to verify discs with data command.

TOSHIBA XM-6402B, DIC error.
HL-DT-ST GCR-8525B, DIC error.
Lite-On iHAS124-F my new drive,  DIC error.
HL-DT-ST GH22NS40, works, no C2, drive support it.
SONY CRX230ED, works, C2 support, good reader.
TEAC CD-W552G works, C2 support.
NEC NR-9500A, works, no C2 support by drive.

If it's possible fix errors with drives.

sarami, thanks. Lite-On iHAS124-F works fine with C2 support.
TOSHIBA XM-6402B also works, no C2 by drive itself.
And yes, HL-DT-ST GCR-8525B - Drive cannot read Subchannel Data directly (from Nero DiscSpeed DAE test and CloneCD report)

Also I can't run 2 copy DIC at the same time, it's normal? And DIC blocks access to ASPI or drives in OS (Win10) for yourself because EAC can't see drives, while DIC works.

update:
In TOSHIBA log sometimes appears, but all works.

LBA[000000, 0000000], [F:ReadBufferCapacity][L:536] OperationCode: 0x5c
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-20-00 = ILLEGAL_REQUEST - INVALID COMMAND OPERATION CODE
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Reading DirectoryRecord    1/   1

Hm. Accidentally found drive which can read in scrambled mode and works with DIC - ASUS DVD-E616A. But drive doesn't read in lead-out.

And question about C2 pointers. Why on some drives DIC doesn't use C2 although example Perfectrip and EAC report about C2 support and errors.