1,201

*2018-01-27
- added: Dumping of DVD which is the parallel track path and dual layer
- changed: Visual Studio 2015 to 2017
- fixed: Dumping of audio disc (didn't work from 2017-12-10)
- fixed: Rewrite .c2 file if c2 errors exist.

1,202

F1ReB4LL wrote:
rosewood wrote:

Audio trap disc, DIC stop command and subdump displays this a couple of times:

Sense data (SK/ASC/ASCQ): 0x00/0x00/0x00
No sense data. No additional sense information.

Have you tried to dump other discs this way? Maybe the drive itself doesn't like swapping?

Not yet, I'll try it with my other multi track CD-i discs when I have more time. The drive is a Plextor PX-760A

1,203

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?

1,204

As you say, dic needs to reread the safedisc error range to fix the unintentional errors of the range. But dic can't judge whether the errors is intentional or not, therefore the intentional errors are also reread about 500-600 sector × multiple times.

1,205

But when DIC hits a "real" Safedisc sector, it will quit after re-reading this sector multiple times because it was unable to fix it, right?

1,206

Yes. Verbose rereading just occurs, surely real c2 errors may be fixed. Plz wait until I add the code.

1,207

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

1,208

Is HL-DT-ST UH12NS30 still a drive that works for PSX dumping and DIC? I have a friend with PS1 & PS2 code discs that has one and is interested in dumping. I guess it just can't read big offsets "(Combined Offset minus disc only)"?

Shouldn't be a problem for unlicensed discs, which usually how a low or no offset.

1,209

I think DIC only works with D8-capable drives, giving the messy data tracks on the rest?

1,210 (edited by diego-rbb-93 2018-01-31 12:49:41)

Hi everyone!

Im trying to dump an spanish PSX demo (Syphon Filter 3 SLED-02040) and the Plextor-W4012TU im using here keeps reporting me this error:


C:\Users\diego\Desktop\HDD\Release_ANSI>DiscImageCreator.exe cd h "SCED-03780.bin" 10 /c2 /nl
AppVersion
        x86, AnsiBuild, Jan 13 2018 21:29:26
/c2 val1 is omitted. set [4000]
/c2 val2 is omitted. set [0]
CurrentDirectory
        C:\Users\diego\Desktop\HDD\Release_ANSI
WorkingPath
         Argument: SCED-03780.bin
         FullPath: C:\Users\diego\Desktop\HDD\Release_ANSI\SCED-03780
            Drive: C:
        Directory: \Users\diego\Desktop\HDD\Release_ANSI\
         Filename: SCED-03780
        Extension: .bin
Start time: 2018-01-31(Wed) 10:11:47
LBA[000000, 0000000]: [F:ExecSearchingOffset][L:82]
        Opcode: 0xd8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
lpCmd: d8, 00, 00, 00, 00, 00, 00, 00, 00, 01, 00, 00
dwBufSize: 2352
This drive doesn't support [OpCode: 0xd8, SubCode: 0]
LBA[000000, 0000000]: [F:ExecSearchingOffset][L:82]
        Opcode: 0xd8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
lpCmd: d8, 00, 00, 00, 00, 00, 00, 00, 00, 01, 01, 00
dwBufSize: 2368
This drive doesn't support [OpCode: 0xd8, SubCode: 1]
LBA[000000, 0000000]: [F:ExecSearchingOffset][L:82]
        Opcode: 0xd8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
lpCmd: d8, 00, 00, 00, 00, 00, 00, 00, 00, 01, 02, 00
dwBufSize: 2448
This drive doesn't support [OpCode: 0xd8, SubCode: 2]

Any thoughs about it?

EDIT: Im trying to dump other games but this error keeps pursuing me:

This drive doesn't support [OpCode: 0xd8, SubCode: 2]

1,211 (edited by sarami 2018-01-31 14:14:32)

user7 wrote:

Is HL-DT-ST UH12NS30 still a drive that works

http://forum.redump.org/topic/15076/add … ification/
I don't have this drive, but he reported this drive worked about scrambled and lead-in.

diego-rbb-93 wrote:

Plextor-W4012TU im using here keeps reporting me this error:

Try using the latest firmware.

sarami wrote:

Yes. Verbose rereading just occurs, surely real c2 errors may be fixed. Plz wait until I add the code.

Uploaded the test version. I haven't tested the protected disc except safedisc yet.

1,212

Thanks for the new test version - testing right now. Hopefully I can properly dump this problematic disc now and get matching checksums...

How much is ripping time increased because of this new feature?

1,214 (edited by celebi 2018-01-31 17:36:19)

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.

1,215

I did a few more runs on that problematic disc - it seems that it is in a condition that makes it unusable for proper dumping. I get not only random C2 errors (that get fixed by the re-readings, so the new feature works as expected), but also sync issues. Damn.


sarami, thank you for the fast implementation of this feature request!

1,216 (edited by sarami 2018-02-01 02:14:57)

Uploaded  test ver.
----
I confirmed the specific bit was error.

 :
LBA[002089, 0x00829] Detected C2 error 312 bit

LBA[002109, 0x0083d] Detected C2 error 312 bit

LBA[002114, 0x00842] Detected C2 error 312 bit

LBA[002134, 0x00856] Detected C2 error 312 bit

LBA[002159, 0x0086f] Detected C2 error 312 bit

LBA[002188, 0x0088c] Detected C2 error 312 bit
 :

If your disc also has a specific value of error bit count, app can exclude the sectors which this value has. As a result, app can only reread unintentional c2 error sector.
Please upload the log of your all safedisc. (Because I have only 1 safedisc..)

1,217 (edited by celebi 2018-02-01 12:49:59)

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.

1,218

The latest test version is only added the log message --- "Detected C2 error xxx bit". No need to dump full, I want to know "xxx" value of your all safedisc.

1,219

At least for one good safedisc disc I can confirm that *all* sectors with C2 errors are 312 bit.

Most of the sectors of my bad safedisc disc have 312 bit too, the random ones have random values. Logs of the bad disc attached. I'll try to confirm more good safedisc disks.

Logs of the bad disc after a full redump: https://www.sendspace.com/file/9i1ne5

1,220

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.

1,221

Thanks. Uploaded the latest test.
added: Skip rereading for safedisc 312 errors
              => The problem is that dic skips rereading if unintentional error is also 312.

1,222 (edited by celebi 2018-02-01 16:33:10)

Thanks, I'll give it a try.

=> The problem is that dic skips rereading if unintentional error is also 312.

How is the bit number for C2 errors calculated and how high is the chance that an unintentional error is exactly 312? Still improves the reliability compared to previous versions though...

EDIT: Btw, have you looked into mainError.txt from the bad disc I submitted? Assuming all unintentional C2 errors could be fixed, would this be a good or a bad dump? I don't know what those "header generated" messages mean.

1,223

dic gets the c2 (294 byte=2352bit). If error exists, a bit stands and coutinue checking this 2352 times.

how high is the chance that an unintentional error is exactly 312?

Unintentional error changes every times CD is read, but I don't know how high rate (depending on CD).
Anyways, I always recommend dumping at least twice, especially bad condition disc.

I don't know what those "header generated" messages mean.

Sync is 12byte (00 FF ... FF 00)

========== LBA[002832, 0x00b10]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF 7F FF FF FF  FF FF FF 00 01 B9 A3 61   ...............a
========== LBA[002832, 0x00b10]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 01 B9 57 61   ..............Wa

Fixed 0x7f to 0xff.

Assuming all unintentional C2 errors could be fixed, would this be a good or a bad dump?

Check _EdcEcc.txt. I don't know the error of this disc is truly 584 because I don't have this.

1,224 (edited by celebi 2018-02-01 17:15:13)

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 tongue)

1,225

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!!