Yesterday I watched a video file with my android media player that I ripped a year ago. At one point there was pixelation for around one second. However, the sound played completely normal. I later confirmed that the error was indeed in the file (I copied the file from my NAS and used VLC - it was the exact same error).
I don't know if that file was corrupt from the beginning or if it occurred later on my NAS. The latter option would be considerably worse.
I always thought that MakeMKV would either rip a perfect bit-for-bit copy or the process would fail. I even used the program to check if my Blu-rays are still intact. My question is if it's possible that the error on the disk was so small (again, sound was working finde) that MakeMKV still delivered an output file? Has anyone experienced something like that?
Are rip errors in finished mkv file possible?
Re: Are rip errors in finished mkv file possible?
If the source was a blu-ray or a UHD, those formats include hash tables that MakeMKV checks to verify that the bits it read from the disc are what the disc authors intended and thus a 'perfect' copy.
Data corruption on hard drives isn't as rare as most people would like it to be.
Data corruption on hard drives isn't as rare as most people would like it to be.
-
Radiocomms237
- Posts: 377
- Joined: Mon Oct 18, 2021 12:23 am
Re: Are rip errors in finished mkv file possible?
Yes, but those Content Hash Tables can only confirm that the data able to be read from the disc itself is error-free, although I grant you, that is typically the most likely point of failure in the whole process.
Any error that happens after that, whether it be due to MakeMKV removing frames here 'n there for syncing purposes, or in muxing everything together, or just plain old file copy errors, has no way of being detected, let alone corrected.
For example, I always thought that using those Hash Tables guaranteed a true backup copy of a disc, but they don't. Just the other day I had backed-up a Blu-ray (without even a hint of an error, I might add) but when I opened the backup and began ripping I started getting file corruption errors the same as you would from a dirty disc. I cleaned the disc and made another backup (again, without errors) and that one ripped perfectly.
While I obviously have no control over the .mkv file creation itself, thereafter I use TeraCopy to transfer EVERYTHING, and I have it setup to CRC every file it moves before it deletes the source material, and it does regularly pick up file copy errors over my LAN between the PC and the NAS.
When I say "regularly" I should clarify: In terms of time it's maybe one file a week that fails the CRC; and in terms of the number of files transferred it's probably only one in ten thousand. Unfortunately, problems seem more likely to be within a movie file, I'm guessing because they're bigger and are therefore exposed longer to errors creeping-in during read/write & transfer.
Any error that happens after that, whether it be due to MakeMKV removing frames here 'n there for syncing purposes, or in muxing everything together, or just plain old file copy errors, has no way of being detected, let alone corrected.
For example, I always thought that using those Hash Tables guaranteed a true backup copy of a disc, but they don't. Just the other day I had backed-up a Blu-ray (without even a hint of an error, I might add) but when I opened the backup and began ripping I started getting file corruption errors the same as you would from a dirty disc. I cleaned the disc and made another backup (again, without errors) and that one ripped perfectly.
While I obviously have no control over the .mkv file creation itself, thereafter I use TeraCopy to transfer EVERYTHING, and I have it setup to CRC every file it moves before it deletes the source material, and it does regularly pick up file copy errors over my LAN between the PC and the NAS.
When I say "regularly" I should clarify: In terms of time it's maybe one file a week that fails the CRC; and in terms of the number of files transferred it's probably only one in ten thousand. Unfortunately, problems seem more likely to be within a movie file, I'm guessing because they're bigger and are therefore exposed longer to errors creeping-in during read/write & transfer.