CDArchive - Improved support for ring based protections

[reentrant]

All calls to Python functions are enclosed in try/catch blocks (boost::python::error_already_set) with retVal set to ERROR_ACCESS_DENIED - this value is chosen arbitrarily. What do you mean by "comment-out"?

In case sector cannot be repaired (for example because corruption is too big, exception will be thrown, retVal = 5).

HandleC2 can only handle data sectors (data sectors with ECC blocks, mode 2 sectors without ECC are not supported)...

[sarami]

All calls to Python functions are enclosed in try/catch blocks (boost::python::error_already_set) with retVal set to ERROR_ACCESS_DENIED - this value is chosen arbitrarily. What do you mean by "comment-out"?

Doxygen style is useful for me.

Code: Select all

/**
 * @brief  -> Description of this function
 *
 * @param  -> Description of parameter
 * @return -> Description what value is returned
 */
typedef DWORD (WINAPI *pInitC2)(PC2_CORRECTOR_INIT c2InitBlock);

In case sector cannot be repaired (for example because corruption is too big, exception will be thrown, retVal = 5).

Is the return value of HandleC2 only 0 and 5? It seems that same as system error code(https://learn.microsoft.com/en-us/windo … es--0-499-)

HandleC2 can only handle data sectors (data sectors with ECC blocks, mode 2 sectors without ECC are not supported)...

Ok. This dll can repair mode 1 and mode 2 form 1 sector.

[reentrant]

HandleC2:
ERROR_ACCESS_DENIED - error in ECC logic (too many errors)
ERROR_INVALID_PARAMETER - error in ECC logic (parameters checking for Python function)
ERROR_INVALID_DATA - error in ECC logic (Python function returned not enough data)

The last two error codes shouldn't happen - these are sanity checks.

Under normal circumstances HandleC2 returns either 0 if repair is successful or ERROR_ACCESS_DENIED (5) when it fails.
All return values are the same as system error codes.

[StriderSkorpion]

I have been using this version of CDArchive to get some sectors from problematic discs and noticed that it won't save the sector if the data section matches, but the ECC Q doesn't. The problem is in the .bin file, as verified by scanning with CDMage. Would it be possible for CDArchive to (force) save the sector in such cases?

[reentrant]

Added new command line switch:
extrforceecc: 0/1 - this option forces correction of ECC even when EDC is correct. Old version skipped ECC correction when EDC was ok. Default value is 0.

But... after looking at: /viewtopic.php?t=55852 … -redumper/ @ sector 25701.bad things get complicated. The bad sector internally gets corrected but it zeroes out M/S/F/Track bytes. It looks like ECC is deliberately corrupted. After all even with extrforceecc = 1, repaired sector is not merged into the image.

So, this version does what you want but not for this specific sector...
What do you think about all of this?

[StriderSkorpion]

This seems to have worked. The sectors are saved with the correct ECC Q data. I'm not having any issues with MSF section of the header that you mentioned.

I'm not sure what happened when dumping the disc initially, but apparently the drive told redumper that the C2 error was corrected despite the ECC Q parity data being corrupted.

[reentrant]

Ok, I'm glad it worked.