www.makemkv.com

It doesn't happen often, but sometimes, when the disc has small scratches, the disc will be read successfully but some M2TS files won't pass integrity checks.
It seems that MakeMKV doesn't attempt to read the disc again when this occurs (or at least didn't a few months ago), even if it's enough to get a proper copy of the file in most cases.

I don't have to do if often, but it's annoying to have to manually patch a "partially-good" backup to produce one that's "perfect".

There is an IO setting for retries, but...

If a disk gets "no read errors", you cannot count on there not being any read errors.

Some drives out there will return "valid data" when the data is only "mostly correct". MakeMKV does consistency checks at several levels, from what I can see (I'm an outsider like you are), as evidenced by "corrupt or invalid at offset xxxxxx" messages; no error was received on the read, but the data made no sense.

During backup, it is possible those consistency checks are reduced - MakeMKV isn't trying to interpret what is IN the m2ts and mpls files, just copy them. So if the drive didn't report a read error, the only check is when the hash of the decrypted file is checked that the error is detected.

What happens if you use OPEN instead of backup, and save the files to MKV files? Do you see errors in the reads?

Thanks, this a good suggestion. You are right, MakeMKV does not retry on failed hash check.

It is nearly impossible to do in MKV mode as hash check happens after the data is already processed, but fairly easily can be done in backup mode.

Request noted.