redump.info Forum

The error count is still 0, as per redump.org rules around what errors get counted (invalid sync sectors are not counted in the error count). The only change is the index 1 position for two tracks.

Ah, ok !

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 !

If you have the time to, submitting logs from both tools is good. But it is not required.

sarami wrote:

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.

sarami wrote:

03_mode0_zeroed_data.0.pass
04_mode0_non_zeroed_data.0.pass
05_mode0_non_zeroed_data_last_byte.0.pass

User area of the mode 0 sector is all zero. It's CD specifications. But I confirmed that other software also treats as no error sector. I'll fix this case.

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

sarami wrote:

16_msf_mismatch_invalid_sync.42.fail
:
:
45_no_msf_invalid_mode_no_intermediate_max.null.fail

What is the "msf_mismatch" and what is the "no_msf"? It seems msf of test data is normal (00:02:00).

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.

redumper build_490 fixes the incorrect split for your Heroes 2, feel free to redump and it should match DIC.

It's a match ! Well done !

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

Unscrambling has always been a problem for me. It'd be great if both tools were 100% correct about this:
https://github.com/superg/redumper/tree … unscramble

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

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.

sarami wrote: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.

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

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