If hashcheck errors occur, but a rip doesn't fail, are the effects visible and/or audible?

[RasterEyes]

I found a discussion of this on Reddit, but no conclusion, only people wondering but not knowing.

It would be helpful if timestamps were reported along with hashcheck errors, so we'd know just where in a video to watch and listen for glitches if they occur.

[dcoke22]

This post is from the program's author.

It is better to read the whole thread for context (it is short).

Unfortunately the message means exactly what it reads - the program encountered a corrupt area (usually a mastering error) and will try its best to work around. It "works around" instantly but the workaround may (or may not) lead to failure several seconds later. So it's impossible to print the definite message at that time. What is certain, that if the file was successfully created and you've got no audio de-sync errors, then the workaround was successful.

Unfortunately, that answer is from many years ago, so it is hard to know for certain if it is still true.

I generally take the view that if MakeMKV creates an output file, then it believes the file created is not corrupt. When MakeMKV encounters an unrecoverable error, it does not create an output file.

[TaliesinWI]

This might have been me asking that question in Reddit (I can't check right now because r/makemkv is private).

I was actually going to go back there to post an update!

I have several discs where ripping on my LG drive got a "hash check error" here and there, but my Pioneer drive didn't report any errors. (Note that this isn't the kind of error where MakeMKV reports "working around" - it's just a single hash check error with an offset.)
I've found that the resulting mkv IS affected - I took the mkv from the LG rip and the mkv from the Pioneer rip, did a quick PSNR check on them, and visually checked the couple/few frames that showed the frames were different.
In every case the LG ripped mkv (the one where there were occasional hash errors reported) had a visual glitch for a single frame - sometimes barely visible, sometimes somewhat noticeable. The same frame on the Pioneer rip was pristine.

So basically, to reiterate, if you get _any errors_, at all, while ripping, you might get a "complete" MKV file, but there's going to be theoretical visual glitches in it somewhere. _It is not a visually perfect rip_ unless there are zero errors. (A/V sync errors are different, I don't see them often so I've never run them down.)

IMHO MakeMKV should probably try to re-read the section of disc when it encounters a hash error, because it seems to come down to how the drive handles ripping a disc with minor dust or imperfections. Going back and re-reading the sector at a slower speed might just correct the error.
Failing that, MakeMKV should print a timestamp or frame number of where all the hash check errors are in the MKV output so that they could be visually verified before proceeding. In a couple of the above cases the glitch was so small that I could absolutely live with it, or it was literally only noticeable in a frame-by-frame step through.

[RasterEyes]

I have several discs where ripping on my LG drive got a "hash check error" here and there, but my Pioneer drive didn't report any errors...

Thanks for the reply. Do you find your Pioneer drive more reliable? I'm considering replacing my older internal LG drive with a Pioneer BDR-S13UBK.

Failing that, MakeMKV should print a timestamp or frame number of where all the hash check errors are in the MKV output so that they could be visually verified before proceeding. In a couple of the above cases the glitch was so small that I could absolutely live with it, or it was literally only noticeable in a frame-by-frame step through.

Yes, a timestamp is exactly what I would find really useful. I'd have immediately played back my ripped videos to see what they looked (and sounded) like at those moments.

Since you only mentioned visual defects, I take it you haven't heard any pops, clicks, or other audible distortions caused by errors?

[TaliesinWI]

I have several discs where ripping on my LG drive got a "hash check error" here and there, but my Pioneer drive didn't report any errors...

Thanks for the reply. Do you find your Pioneer drive more reliable? I'm considering replacing my older internal LG drive with a Pioneer BDR-S13UBK.

My Pioneer is more reliable than my LG is _right now_, but the Pioneer has only done maybe two or three dozen rips. The LG is a year+ old and I've ripped close to 750 discs with it. So I don't know if it's starting to fail or is just more finicky with the latest batch of discs, or what. I was toying with using the protection plan I bought with it to get a replacement and see what would happen.
I bought the LG because of the ability to flash it for 4K, which the Pioneer can't do. Given that I've used that feature exactly zero times and there were instances where I had problems ripping discs with the LG, in hindsight, I just would have bought the Pioneer from the jump. The extra $15-20 would have been worth it.

Failing that, MakeMKV should print a timestamp or frame number of where all the hash check errors are in the MKV output so that they could be visually verified before proceeding. In a couple of the above cases the glitch was so small that I could absolutely live with it, or it was literally only noticeable in a frame-by-frame step through.

Yes, a timestamp is exactly what I would find really useful. I'd have immediately played back my ripped videos to see what they looked (and sounded) like at those moments.

Since you only mentioned visual defects, I take it you haven't heard any pops, clicks, or other audible distortions caused by errors?

You know, now that you mention it, I don't recall any. But I'm not sure I even had headphones plugged in while I was doing the checking. I should dump the soundtracks with Audacity and do a comparison.