It is nonsense to change behavior depending on CD-i or not.

Good luck and all the best!

If mode bit1 is 0 and bit0 is 1, it deems to the mode1 and calc edc/ecc.
If mode bit1 is 1 and bit0 is 0, it deems to the mode2 form1/2 and calc edc/ecc.
If edc/ecc is correct, the sector is unscrambled, otherwise is not unscrambled.

If mode bit1 is 0 and bit0 is 0, it deems to the mode0 and the sector is unscrambled if sync and msf is correct.
If mode bit1 is 1 and bit0 is 1, it deems to unknown and the sector is not unscrambled.

The result would be the same as redumper's test(01..46), perhaps.

I don't know if such rule (valid for CDi) should be applicable to all systems (especially IBM PC)...

This rule is not affecting IBM PC at all.

It's possible but I don't think it's useful for general public. Descrambling is lossless operation and you can always restore any sector how you want, especially if descrambling algorithm is consistent and easy to understand.
If you really care about having unmodified dump, preserve .scram, that will never change.

Small suggestion: is it possible to emit some metadata describing mastering error of a sector - some info describing what's faulty and how it was corrected - for the purpose of being able to reverse repair operation (to have a possibility of creating unmodified dump)?

To:superg
Thanks for the answer. I still have a question.
Redumper unscrambles the sector if sync is broken but msf and mode are normal. Why? Optical drive treats the broken sync sector as error, do not unscramble.

Yes, this again fixes some bad CDi masterings because they actually store data sectors without sync headers.

Sarami: any chance you could adapt your unscramber code to pass all of those tests?

Here are the logs if you need to check anything : https://mega.nz/file/gDIEkYRI#x2jyworhw … wkAqricv3I

01_invalid_sync.0.pass
10_invalid_mode_zeroed_intermediate.0.pass
11_invalid_mode_non_zeroed_intermediate.0.pass
12_invalid_mode_non_zeroed_intermediate_last_byte.0.pass

Can you explain from the CD specifications why this sector is unscrambled?

The only thing I know of that comes from the CD specification is that if there is sync header and track is data, it needs descramble. Most of these test cases came from bad mastering cases such as early masterings and Philips CDi.

Same is about mode0 sectors. Specs say that those should be empty, but in reality I see discs where

Each filename has a number suffix that indicates the expected LBA. When redumper descrambles, it knows the position of of the sector and if it matches, it's the strong check for the successful descramble.
So .42 means that expected LBA of the sector contents is 42, on the other hand .null means that there is no positional information.
For the details see https://github.com/superg/redumper/blob … ts.cc#L187

The bottom line is, DIC never followed CD specs in the first place (always descramble if there is sync header and it's data track). Long time ago I've been checking your descramble code and you have a lot of logic that checks if padding is empty, if mode is correct and some other things. So the current status quo is to have clean dumps without garbage and redumper is doing exactly that. The test cases were created solely to make sure that any subsequent redumper code change is not affecting whole redump.org database.

So, I'll Keep (And I'll submit) Redumper dumps of the two others games (iM1A2 Abrams & Take No Prisoners)

Thanks both of you guys, for your time, informations and advices !

Error Count : 2