Search options (Page 2 of 2)

sarami, I cannot thank you enough!

With the latest test version skipping the 312 bit errors, I finally managed to get several (!) dumps of the previously bad disk matching the dumps I made with CloneCD using a different drive. So finally I have a good dump that will soon enter the redump database. Nice and clean 579 bad sectors, image perfectly working. Thanks again!

I'm very sure that my Plextor W5224 isn't great when it comes to uninententional C2 errors mixed with the Safedisc errors - it detected a few of the Safedisc errors with other bit counts and tried to re-read them too. It should be also noted that the Plextor had issues dumping that disc in CloneCD (random errors there too) while my cheap slimline drive always produced a good dump in CloneCD with the same disc.

I think I should get another Plextor model for safedisc discs in bad condition. If I remember correctly, Nexy reported issues with some Safedisc discs with that drive too - maybe it can only read the Safedisc discs in the first run if they are in perfect condition.

Thanks again!!

Currently DIC is reporting various error counts - waiting for the current dump to complete with a higher re-read count. CloneCD always reports 579 errors for that disc.

So in general, header regenerated messages/sync errors are not harmful as long as I get matching checksums over multiple reads?

Thanks for your support man! (and sorry for asking all those (stupid?) questions )

I dumped 5 safedisc discs, ranging from Safedisc v1.x to 4.6.

Logs: https://www.sendspace.com/file/l7lxjq

C2 error is always 312 bit.

sarami, thanks for the new test version.

Just trying with another known good safedisc disk - I'll see if checksums match with "old" stable version and latest test version. Hold on - logs will follow. Then I'll see if the new test version can do something about the bad safedisc disc.

I'll post the logs of the bad disc too... maybe I can finally get a good dump without any unintentional C2 errors.

It depends on the settings. For my first test run, I used 5 re-reads, but that missed about 20 sectors with unintentional C2 errors (verified against ripping with CloneCD with always creates 579 bad sectors - I guess CloneCD does re-reading right away).

With 5 re-readings, ripping time increased about 5 minutes using my Plextor W5224A at 24x reading speed.

If you want no ripping time increase, just use /sf /c2 0 to disable it.

Update: Test run with 25 re-reads went down to 581 sectors with C2 errors. Now trying with lower read speed and 100 re-reads... Still wonder why CloneCD seems to get past the unintentional C2 errors each and every run.

Thanks sarami for looking in to this! I really appreciate it!

I have a suggestion regarding the handling of Safedisc protected discs.

I have a disc that shows random errors in the Safedisc protected areas. Because of the /sf parameter, the entire Safedisc sector range will receive no C2 error correction or re-reads. I think this is some kind of design flaw, because currently it is not possible to dump Safedisc protected games in a reliable way - you'll never know if your disc has a C2 error caused by Safedisc or a "real" one that could be fixed by re-readings.

Therefore I propose the following change to the Safedisc protection handling:

Detect the protection as always and store the Safedisc error range somewhere in memory. Read the entire disc and then try to correct C2 errors by re-reading. When DIC detects a C2 error inside the previously detected Safedisc error range, it should re-read it multiple times (user defined). If a C2 error can be fixed by re-reading: Congrats, we fixed an unintentional C2 error. If it can't be fixed by re-reading, we probably hit a Safedisc error. In this case, DIC shouldn't quit with an error as it now does, but simply skipping this sector and replace it with 0x55.

This would make dumping Safedisc discs more reliable in my opinion. What do you think?

Thank you sarami for creating this software!

However, I ran into a few issues. Unfortunately, I currently doesn't have a Plextor drive - the one I ordered was DOA. I don't know when the second one I ordered will arrive.

I found a DH-16A6S in my stack of drives. It is an iHAS 120 clone. It doesn't supports /d8, but is capable of reading in scrabled mode according to DIC.

However, when I try to dump a disc, most discs will fail while dumping - it seems that the drive cannot properly read the last sector and therefore reports a non-existing error.

This also accurs on basically all other drives I own using DIC with the "data" command - the last sector will always fail.

Using the DH-16A6S for some reason always requires me to add the /sf command on *all* discs regardless if they are protected or not, otherwise the ripping process stops at around LBA 45 with a semaphore issue.

UPDATE: I think you can ignore the issue with the DH-16A6S - when I redump a disk that's in the redump DB with CDM, I get wrong checksums while the DS8ACSH dump matches the redump DB. So maybe you could focus on the issues I have with my remaining drives combined with "data" mode?

Example 1, using the DH-16A6S (flashed with iHAS 120 firmware, but also happens with the official one):

C:\Users\user>C:\Users\user\Desktop\Redump\DiscImageCreator.exe cd d: E:\Redump\Tests\DH-16A6S\DH-16A6S_1.bin 0 /c2
AppVersion
        x86, AnsiBuild, Dec 10 2017 17:54:51
/c2 val1 is omitted. set [4000]
/c2 val2 is omitted. set [0]
E:\Redump\Tests\DH-16A6S\DH-16A6S_1.bin doesn't exist, so create.
CurrentDirectory
        C:\Users\user
WorkingPath
         Argument: E:\Redump\Tests\DH-16A6S\DH-16A6S_1.bin
         FullPath: E:\Redump\Tests\DH-16A6S\DH-16A6S_1.bin
            Drive: E:
        Directory: \Redump\Tests\DH-16A6S\
         Filename: DH-16A6S_1
        Extension: .bin
Start time: 2018-01-07(Sun) 09:15:48
Set the drive speed: 8468KB/sec
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, SubCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, SubCode: 1]
LBA[008380, 0x020bc]: [F:GetLBAForSubChannelOffset][L:58]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 00, 20, bc, 00, 00, 01, fa, 01, 00
dwBufSize: 2742
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, SubCode: 2]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, SubCode: 4]
LBA[008380, 0x020bc]: [F:GetLBAForSubChannelOffset][L:58]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 00, 20, bc, 00, 00, 01, fa, 04, 00
dwBufSize: 2742
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 2, SubCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 2, SubCode: 1]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 2, SubCode: 2]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 2, SubCode: 4]
LBA[008380, 0x020bc]: [F:ReadCDForCheckingReadInOut][L:434]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 00, 20, bc, 00, 00, 01, f8, 00, 00
dwBufSize: 2742
End time: 2018-01-07(Sun) 09:16:10

This disc is an unprotected IBM PC disc. Sector count is 8380 and it rips fine with CDM.

Example 2, same disc, using a Slimtype DS8ACSH (some OEM drive, don't know the real vendor)

C:\Users\user>C:\Users\user\Desktop\Redump\DiscImageCreator.exe data f: E:\Redump\Tests\DS8ACSH\DS8ACSH.bin 0 0 8380 /c2
AppVersion
        x86, AnsiBuild, Dec 10 2017 17:54:51
/c2 val1 is omitted. set [4000]
/c2 val2 is omitted. set [0]
E:\Redump\Tests\DS8ACSH\DS8ACSH.bin doesn't exist, so create.
CurrentDirectory
        C:\Users\user
WorkingPath
         Argument: E:\Redump\Tests\DS8ACSH\DS8ACSH.bin
         FullPath: E:\Redump\Tests\DS8ACSH\DS8ACSH.bin
            Drive: E:
        Directory: \Redump\Tests\DS8ACSH\
         Filename: DS8ACSH
        Extension: .bin
Start time: 2018-01-07(Sun) 09:21:45
Set the drive speed: 4234KB/sec
LBA[008381, 0x020bd]: [F:GetLBAForSubChannelOffset][L:58]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 00, 00, 00, 20, bd, 00, 00, 01, fa, 01, 00
dwBufSize: 2742
LBA[008381, 0x020bd]: [F:GetLBAForSubChannelOffset][L:58]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 00, 00, 00, 20, bd, 00, 00, 01, fa, 04, 00
dwBufSize: 2742
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Reading DirectoryRecord   12/  12

Set OpCode: 0xbe, SubCode: 1(Raw)
Checking SubQ ctl (Track)  1/ 1
LBA[-00001, 0xffffffff]: [F:ProcessReadCD][L:1501]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-2c-00 = ILLEGAL_REQUEST - COMMAND SEQUENCE ERROR
LBA[-00001, 0xffffffff] Read error. padding [2352byte]
Creating bin from 0 to 8380 (LBA)   8379
No C2 errors
Exec ""C:\Users\users\Desktop\Redump\EccEdc.exe" check "E:\Redump\Tests\DS8ACSH\DS8ACSH.bin""
FILE: E:\Redump\Tests\DS8ACSH\DS8ACSH.bin
Checking sectors (LBA)   8380/  8380
[ERROR] Number of sector(s) where 2336 byte is all 0x55: 1
Total errors: 1
Total warnings: 0
End time: 2018-01-07(Sun) 09:22:41

This time, it seems that DIC is trying to read one sector that's simply not present - and this is always happening when using DIC with the data command. If I limit the reading range from 0-8380 to 0-8379, then it will still fail reading the last sector.

Is there something that could be done about this or are my drives all incompatible and I have to either use another dumping software (hopefully not) or wait until I could obtain a real plextor drive?

I tried all versions of DIC I could find, but always the same issues.

Please note that while the DS8ACSH is connected using the PC's internal SATA bus, I'm using a SATA/IDE-USB-Converter for the DH-16A6S.