DiscImageCreator

[matura713]

Did you try to dump with /sf?

thanks, I did try it, "DiscImageCreator.exe cd f AUDIOCD 8 /sf /c2 /d8" - no difference, except this time DiscImageCreator says it cannot detect the protection and will ignore the "/sf" switch. it proceeds from there with no any difference

[matura713]

@sarami

just to let you know that "px_d8" from the links here:

https://wiki.redump.info/index.php?title= … isc._Tools

more specifically this one:

http://www.mediafire.com/file/khnzcxdae … 8.zip/file

works with my Yamaha CDR200t drive, i.e. it returns the exact same data for each LBA read on Plextor and Yamaha CDR200t on the same disc. yet, as I reported, it fails with DiscImageCreator:

/viewtopic.php?p=26258#p26258

So, I don't know exactly why it fails, but it seems to me Yamaha D8 is fully compatible with Plextor D8 command, if "px_d8" works with my Yamaha CDR200t.

[EDIT] or maybe it's because Yamaha CDR200t is doing just main plus sub-channel and not main plus sub-channel plus c2?

[matura713]

Unfortunately, today I am really out of any luck and I came across another problem - this time with Key2Audio protection. So, here are my steps to confirm something is not right:

1. Rip the disc with ExactAudioCopy using physical Plextor DVD drive
2. Dump the disc with DiscImageCreator using physical Plextor DVD drive
3. load the image from step2 in virtual drive
4. Rip the disc with ExactAudioCopy using the virtual drive with DiscImageCreator image in it from step3

So, with all other discs ExactAudioCopy "TestCRC" Hashes match those from step1 and step4, i.e. ripping from the DiscImageCreator image in virtual drive is absolutely equivalent to ripping from the original physical media.

However, with my Key2Audio protected CD, ExactAudioCopy "TestCRC" Hashes from step1 and step4 are different. It's open question to me if ExactAudioCopy is correct or DiscImageCreator is correct, but it's the very first time I see difference between the the 2 applications and one of them must be wrong...

[EDIT] Decided to try with my Asus BW-16D1HT drive, this time:

* DiscImageCreator completely failed:

[INFO] This disc is Multi-Session. /ms is set.
Checking SubRtoW (Track) 18/18
Set OpCode: 0xbe, SubCode: 1(Raw)
Checking SubQ ctl (Track) 18/18
LBA[000001, 0x00001]: [F:ProcessReadCD][L:318]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
LBA[000001, 0x00001]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
End of readable sector

then it stop accessing the disc, creating for several minutes ".scmtmp" file, then more errors:

Code: Select all

LBA[337562, 0x5269a]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337563, 0x5269b]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337564, 0x5269c]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337565, 0x5269d]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337566, 0x5269e]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337567, 0x5269f]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337568, 0x526a0]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337569, 0x526a1]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337570, 0x526a2]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe

and at the end it reported something about "failed to analyze subchannel" - sorry but by accident I deleted the log, but bottom line is no any image was produced. I am even lost, which logs are beneficial to provide.

At the same time Asus BW-16D1HT with ExactAudioCopy produces the same Track hashes as Plextor with ExactAudioCopy. So, on this Key2Audio disc both Asus BW-16D1HT and Plextor PX-712A produce the exact same rips using ExactAudioCopy, i.e. the 2 drives are equivalent there.

[EDIT2] looking in hex-editor the differences, it seems some chunks of data are positioned at different addresses, for example on the attached screenshot what EAC put at 0x1ffffd0, DIC put at 0x2000000...

[sarami]

* Logs from recent version of DiscImageCreator - it quits with PX-5224, saying "This program doesn't support to dump the multi-session disc by the plextor CD Drive"

See https://github.com/saramibreak/DiscImag … /issues/41

works with my Yamaha CDR200t drive, i.e. it returns the exact same data for each LBA read on Plextor and Yamaha CDR200t on the same disc. yet, as I reported, it fails with DiscImageCreator:

Anyway, I don't have it and it is hard to get than plextor and if I find it, it is expensive for me. I can't support it now.

[bikerspade]

I own at least three audio CDs where dumping with my BW-16D1HT and the /mr flag is always unable to proceed with dumping the disc (Cache is short), even with 999 retries. Each and every time, the cache result is the same. I have also tried power cycling the drive and trying again. I successfully dumped these audio CDs with my Plextor, so if there is interest I can share those logs.

[matura713]

I own at least three audio CDs where dumping with my BW-16D1HT and the /mr flag is always unable to proceed with dumping the disc (Cache is short), even with 999 retries.

you're not alone:

/viewtopic.php?p=26268#p26268
/viewtopic.php?p=26269#p26269

I guess it's just  BW-16D1HT limitation and nothing can be done in software, i.e. in DiscImageCreator.

[matura713]

See https://github.com/saramibreak/DiscImag … /issues/41

yes, I understand, why Multi-Session support was removed with Plextor CD drives in the General case, but why remove it in case of Cactus protected CD, when the only confirmed Plextor drive (so far) that can do it is PX-5224? just ignore the 2nd session do not dump it - it's garbage data. It's very easy to detect, at least Cactus CDS200 V5, please, read my details below:

Maybe my main point was missed in the conversation - the 2nd session is just there as part of the protection, i.e. to even further confuse the drive on top of the C1/C2 errors pressed on the discs at the factory.

So, the 2nd session is additional lawyer of protection similar to how Key2Audio protection uses fake sessions, etc. Isn't then the logical thing to do - check for Cactus and if yes then ignore the 2nd session and dump only of the 1st session (if necessary, I am not familiar and knowledgeable about image formats, fix the dumped image to indicate only one session or if that's hard, not possible or not preferred, fill with 0x55 or 0x00 or something like that for all data in the 2nd session - do not care to read that garbage from the disc).

* How to detect Cactus:

- at least Cactus V5 is ultra simple to detect, because there is file:

"F:\player\version.txt"

that in case of the latest revision (at least known to me, it's also the hardest protection for a drive to overcome) and on which I am testing contains:

CDS200.5.11.90
5.10.090

What do you all think about the following ReDump/DiscImageCreator Standard for Cactus discs:

* add check to DiscImageCreator about "\player\version.txt" file on the CD, if it's there, read and report the Cactus version back to the user, in such case allow use of PX-5224 (even better inform the user he/she needs PX-5224 and quit otherwise). Dump only the 1st session, discard the 2nd session as it's just garbage data. Preferably, even add command line-switch to DiscImageCreator for the user to select it's Cactus disc manually, if for some reason the Cactus cannot be detected - I am suggesting such option, because on some discs both "A-Ray Scanner" and "ClonyXXL" tools fail to detect the Cactus, because there is no "\player\version.txt" file, which is very rare case (I have only one such CD). You can see all Cactus versions I listed in a table here:

/viewtopic.php?t=34468 … otections/

BTW, Sony seems to do exactly what I am suggesting above in the firmware of their PS3 BD Drive - I tested it today connected to PC - for Cactus disc it doesn't even need authentication to read it, but it hides the 2nd session makes the disc look as single session to the computer. Also, interesting fact that I found - it seems Sony process the Cactus disc entirely in PS3 BD firmware, because the drive rips all tracks correctly, but with +2305 offset, no matter what offset is set in ExactAudioCopy. So, PS3 BD drive also is capable to fully overcome Cactus like PX-5224, but it seems in a different way - hides the 2nd session and adds that weird +2305 sample offset to each track. However, PS3 BD drive is amazing - rips Cactus 2 times faster than PX-5224 without any single error - all bytes are correct - compared in Hex-editor, just  that 2305 samples offset is added to the beginning of each track. So, PS3 BD C1/C2 error correction is out of this world - to fix 8000 such errors on such high read speed - I tested over 30 other drives on Cactus so far and PS3 BD drive blows my mind (KEM-450 drive from a slim console), really unbelievable and amazing! Especially, when drives like Asus  BW-16D1HT fail so spectacularly on Cactus disc and go to 0.3X speed, struggling and struggling.

[EDIT] even in cases when  both "A-Ray Scanner" and "ClonyXXL" tools fail to detect the Cactus, it's still very easy to detect it, because there is "CACTUSPJ.EXE" file in those cases. So, based on that I guess the correct detection algorithm (at least for the time being) is: check for "player\version.txt" file and if there is proper "CDS200" string  inside it with version report it, if no then check for  "CACTUSPJ.EXE" and report some unknown exact version of CDS200 V3/V4 detected. I have no V5 discs without "player\version.txt". So, those without it are CDS200 V3/V4 for sure, they are also released 2-3 years before discs with CDS200 V5.

[sarami]

just ignore the 2nd session do not dump it - it's garbage data.

If you want to dump only the 1st session, why not use IsoBuster or others? Why are you particular about using DIC?

2nd session of CDS is not garbage. If CDS is preserved, 2nd session is also important. I don't ignore it.

[matura713]

Why are you particular about using DIC?

What is ReDump standard for dumping Cactus CDs? If I use IsoBuster then if ReDump will accept my dump information? How is supposed to dump Cactus CDs compatible with ReDump standards based on available hardware software and their respective limitations? that's what I don't get. sorry, I am newbie here and maybe I am missing some point... thank you!

[sarami]

What is ReDump standard for dumping Cactus CDs? If I use IsoBuster then if ReDump will accept my dump information?

No...
Btw, what title do you want to dump?