Currently, Redumper will use sample based C2 correction to correct errors. This is useful, but can be an issue if there are a lot of C2 errors that affect a group of sectors close together I think. This might be more of an issue if the sectors aren't able to be verified for integrity, like a lack of EDC/ECC data.
It might be best to have an optional flag for cd/refine mode (like --strict-refine, or --strict-mode) where instead of using sample based correction, only merge all 2352 bytes from a returned sector upon read if the drive reports all c2 error bits are correct. Basically, we do what DIC does, but allow users to resume and refine with other drives. This way we might theoretically cut down the amount of false returns in scenarios where the drive might return a good c2 bit for a given sector but the data ended up being incorrect.
Currently, Redumper will use sample based C2 correction to correct errors. This is useful, but can be an issue if there are a lot of C2 errors that affect a group of sectors close together I think. This might be more of an issue if the sectors aren't able to be verified for integrity, like a lack of EDC/ECC data.
It might be best to have an optional flag for cd/refine mode (like --strict-refine, or --strict-mode) where instead of using sample based correction, only merge all 2352 bytes from a returned sector upon read if the drive reports all c2 error bits are correct. Basically, we do what DIC does, but allow users to resume and refine with other drives. This way we might theoretically cut down the amount of false returns in scenarios where the drive might return a good c2 bit for a given sector but the data ended up being incorrect.