Request: After finishing refine step printing how many sectors/samples are still bad/remaining

[shfil119]

Currently it's difficult to track if refine was fully successful.

[superg]

Define "still bad"?

[shfil119]

Number of sectors that still is missing some data.
Edit I meant by "bad" that missing data will report errors in next stages.

[superg]

This will not answer the question if the dump is bad or not.
There can be C2 and SCSI errors in the areas that do not belong to tracks and this information is unknown before you actually attempt to split (disc offset plus leadin plus leadout logic).
e.g. you may still see non zero C2 and SCSI errors but disc will split fine.

[shfil119]

Maybe explaining through use case will be easier.

When working with scratched disc with MPF, you don't want to progress too far when missing some data (some todo in "refine") as MPF will repackage files and it's easy to miss note that dump is incomplete.

In practice (if there's substantial amount of C2 errors) this means: close redumper's window shortly after refine to avoid splitting, and repeat running refine until it reports no problems.

So I have two ideas:

• reporting still todo sectors after refine
• adding flag to fail splitting if there are still some sectors on refine todo list

[superg]

So I think I can have a flag that will stop refining on the first sector that it wasn't able to recover.

reporting still todo sectors after refine

If I list sector LBA's, those will be drive dependent due to drive read offset plus for damaged disc it will be a lot that will complicate the log and I don't see a reason why dumpers need to know them.

[shfil119]

Thanks, flag (if understand correctly) that prevents spliting and further steps would be amazing.