Redump Forum

pablogm123 wrote:Or at least the already implemented option but affecting only RMSFs 03:xx:xx and 09:xx:xx, the known positions of these modified frames.

Improved at above. (change option /n -> /l)
added: xxx_infolog.txt (for no error log)

No success.

http://www.mediafire.com/?6brdaaafxn78ew8





These modified frames. And once modified the new CRC-16 is XORed with 0080.

43012    09:33:37    41 01 01 09 31 33 00 09 13 37 63 09    8f60
43017    09:33:42    41 01 01 09 11 42 00 0d 33 42 15 c2    e948

sorry, I didn't write the subcode for LibCrypt...
re-fixed. But data is incorrect probably. Please test...

Much better. Expected intentional errors (32) + 9/10 false ones due to either corrupted RMSF/AMSF or CRC-16. I am wondering if would be possible to create an algorithm to smartly detect these sectors and leave them untouched, as XOR every frame of this range with 0x0080 and 0x8001 (I mean try both possibilities, not literally XOR with 0x0080 and the got data XOR with 0x8001) to undo the initial XOR operation, if the new CRC-16 matches now the rest of the Q-Frame, is a Libcrypt frame and shouldn't be altered.

Main page gives the tips, posted below.

http://www.mediafire.com/?u213sekbnonirdf

2 bits from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
2 bits from both MSFs are modified, original CRC-16 is XORed with 0x8001.
Either 2 bits or none from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.

Wip3out is the third case, because certains frames have no MFSs altered and CRC-16s are recalculated and XORed with 0x0080.

- improved: SubQ of adr 3(=ISRC sector)(if adr is correct but ISRC data is wrong, fixed it.)

pablogm123 wrote:2 bits from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
2 bits from both MSFs are modified, original CRC-16 is XORed with 0x8001.
Either 2 bits or none from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
Wip3out is the third case, because certains frames have no MFSs altered and CRC-16s are recalculated and XORed with 0x0080.

I don't have a LibCrypt disc. So, it would help me if someone could test the 1st/2nd case.

Dummy images to test:

http://www.mediafire.com/?z741kkwfz6nef1r

To be burned only using CloneCD, in RAW DAO 96 mode and with that option not to repair subcode data enabled.

improved /c2 ripping ver.20140607

It sounds good. In what sense?

By the way, I can dump properly discs using my PX-716AL drive connected via a JMicron based PATA/SATA to USB 2.0 adapter, finally.

pablogm123 wrote:improved /c2 ripping ver.20140607

It sounds good. In what sense?

- improved: /c2 option (support PX-4824)

pablogm123 wrote:By the way, I can dump properly discs using my PX-716AL drive connected via a JMicron based PATA/SATA to USB 2.0 adapter, finally.

ok, thanks.

Why don't release a complete package once fixed several bugs and add new functions, including the Unicode release, driveOffset.txt, scramble.bin and EccEdc.exe files? Releasing the loose WIP app is somewhat confusing for the novice users, because they don't realize that driveOffset.txt and scramble.bin are required.

Possible suggestion, because this app is obviously used by users who own a PX-4824 drive or a +30 Plextor drive:

Download this source code:
And see the source code of pxfw. It includes a function which maybe you can implement to reset via software (I run many times the Win32 version of pxfw.exe for that) a real Plextor drive without resetting the entire system, useful to reanalyze TOC of inserted disc after hot swapping without ejecting+closing the tray and to recover a drive which has got silly. Possible name of argument: «reset».

Another suggestion: could you develop an complementary app which would do this?

-Analyze the data track passed as argument: [name of app].exe [name of data track].bin and determinate if according to the stored EDC/ECC sectors are OK.

-For those corrupted sectors, replace everything except the sync and header fields with 0x55 bytes.

That way discimagecreator would offer support for SafeDisc CDs and should match CloneCD and CD Manipulator, but much faster.

Those corrupted sectors (DIC will dump them as they are interpolated by the drive, because contain intentional and constant C2 errors) should look this way once processed.