Inconsistent output from MakeMKV

[KYThrill]

For the past couple of months, I have been getting glitches in the MKV files created by MakeMKV. They appear to be random, sometimes in audio, sometimes in video. One file may have one or two and the next 15. They may be spaced out or occur close together. Just totally random. I can confirm they are in the file and not the playback device. Each file was tested on four different playback devices and all the glitches occur in exactly the same spot. They occure whether streaming on played back directly from a hard drive.

In troubleshooting this problem, I came across something disturbing. I have tested this on version 1.6.8 and 1.6.10 and found the problem both places. Basically, if I load a disc, scan it with MakeMKV, and then select the audio/video I want ripped, I click a button and make the mkv. It says it completes and I click okay. I then cut/paste the mkv file out of that directory, and then make another with all settings exactly the same, including file path. Move it and repeat once more.

So I would think that I should end up with three MKV files, all identical. However, if I run a MD5 hash on the three mkv files, I get a different checksum on each file. Shouldn't they all be the same?

My first concern was that I had a hardware problem somewhere that was corrupting data. However, memtest+ ran for 12 hours with zero errors, so my memory looks clean. My HDD also completed several diagnostic tests with no errors and the SMART report also looks clean. Before I continued down that path, I decided to repeat this test with DVDFab Blu-ray ripper. I ripped a MKV three times with identical settings. The three resulting DVDFab mkv rips all had matching MD5 checksums. So this has led me to the point of either a) DVDFab has some awesome error checking and correction that is lacking in MakeMKV, or b) there is no problem with my hardware, and something flawed in MakeMKV.

I've been using MakeMKV since version 1.6.0 and have never had a problem with glitches. I didn't start noticing these problems till towards the end of April/ first of May, which coincides with me updating from 1.6.5 to 1.6.8 (and since then to 1.6.10). I have now rolled back to 1.6.5 and I plan to run some of these tests again to see if I get different results.

Any ideas?

[crowfax]

So I would think that I should end up with three MKV files, all identical. However, if I run a MD5 hash on the three mkv files, I get a different checksum on each file. Shouldn't they all be the same?

Use mkvextract (from the mkvtoolnix package) and pull out all the streams from each of the mkv files, then do an md5sum on all 3 video streams, this will tell you if the streams are corrupt.

[Icetrips]

Between 1.6.8 and 1.6.10, the checksum will be different since mike fix the mkv descriptor.

But I'm still interrest with the answer I have the same issue.
My guest was the ACS version or format cause the problem (like async dummy data on the source) but never had confirmation for that.

I currently reencode the mkv to mp4 for fix this kind of error.

[KYThrill]

So I would think that I should end up with three MKV files, all identical. However, if I run a MD5 hash on the three mkv files, I get a different checksum on each file. Shouldn't they all be the same?

Use mkvextract (from the mkvtoolnix package) and pull out all the streams from each of the mkv files, then do an md5sum on all 3 video streams, this will tell you if the streams are corrupt.

Well, I already used eac3to to extract the video stream from the 3 mkvs and used md5summer to calculate the checksums. All three were different (and all three files exhibit different video glitches, so I would expect them to be different).

And to elaborate, these glitches can look like a single small area of macroblocking, to entire screen corruption. Sometimes it is a single green line that will appear across the screen for 10-12 frames, just enough to notice. On glitch that cropped up on two different rips makes the entire image turns green for about 2-3 frames, causing a weird green "flash bulb" effect. On the audio side, it may be a pop or crack. On a couple of rips, the rear surround channels drop out a couple of times. On one rip, at 59 minutes into the movie, the audio just cuts out and never returns. You can scan back and audio reappers and disappears again at the same spot. None of these defects are present on the source disc, just the MKV rips. Every problem MKV reports being made with either version 1.6.8 or 1.6.10.

I can't make one good rip with either version, but I have over 2000 mkvs made with 1.6.0-1.6.5 and never encountered an error.

[KYThrill]

Between 1.6.8 and 1.6.10, the checksum will be different since mike fix the mkv descriptor.

But I'm still interrest with the answer I have the same issue.
My guest was the ACS version or format cause the problem (like async dummy data on the source) but never had confirmation for that.

I currently reencode the mkv to mp4 for fix this kind of error.

Well, I did three rips for 1.6.10 and three different checksums (using BD of 30 Days of Night).

I then uninstalled and reinstalled 1.6.8 and again ripped the same disc three times and got three different checksums. Further I did three rips of 3:10 to Yuma with 1.6.8, and again got three different checksums.

I have now rolled back to 1.6.5 (the last version where I can find rips with 0 glitches in them). I ran out of time this morning, but plan to repeat again with 1.6.5 as soon as time allows.

[Icetrips]

Really interresting.
I remember had mismatch in 1.6.5 too.

Could you check what is the ACS version of "30 Days of Night"?

I really need to remember which disc cause me this problem.

----

Did your eac3to extract video stream are the same size because they should be...?

Next step should be check which part mismatch with a tool like Beyond compare but since file are probably over 10gb... I don't think it's a good idea.

[KYThrill]

Really interresting.
I remember had mismatch in 1.6.5 too.

Could you check what is the ACS version of "30 Days of Night"?

I really need to remember which disc cause me this problem.

----

Did your eac3to extract video stream are the same size because they should be...?

Next step should be check which part mismatch with a tool like Beyond compare but since file are probably over 10gb... I don't think it's a good idea.

It's all at home now, but I saw it so many times that I'm 98% certain it is AACS v4.

Oh yeah, video stream file sizes and number of frames are identical (even though number of frames reported is roughly 2X number of frames reported on the disc) after extracting with eac3to, but md5 checksums are different.

[KYThrill]

Okay, I just ripped 30 Days of Night twice with MakeMKV 1.6.5. extracted both video streams and ran a MD5 checksum. Checksums are identical (still different than the video stream from the BD disc though). Ran a checksum on the entire MKV file. Checksums were identical.

So with 1.6.8 and 1.6.10 I can't get identical video stream checksums. With 1.6.5 it appears I can. My glitch problems started around the time I upgraded to 1.6.8, so I'm just going to roll back to 1.6.5 until a new version comes out that can produce identical checksums on multiple rips. Actually I upgraded to 1.6.8 on 5/2 and so far I've found a glitch in about 90% of my rips dating back to 5/7.

[mike admin]

Okay, I just ripped 30 Days of Night twice with MakeMKV 1.6.5. extracted both video streams and ran a MD5 checksum. Checksums are identical (still different than the video stream from the BD disc though). Ran a checksum on the entire MKV file. Checksums were identical.

Stream checksums must be identical no mater which version do you use, even with 1.6.10 . This is clearly a bug, we just have to figure out if it's a bug in your setup, in MakeMKV or both.

Can you make a full disc backup to HDD first and ensure that there are no hashcheck errors. After that, would you get a consistent result when opening files from this backup instead of original disc?

[KYThrill]

Okay, I just ripped 30 Days of Night twice with MakeMKV 1.6.5. extracted both video streams and ran a MD5 checksum. Checksums are identical (still different than the video stream from the BD disc though). Ran a checksum on the entire MKV file. Checksums were identical.

Stream checksums must be identical no mater which version do you use, even with 1.6.10 . This is clearly a bug, we just have to figure out if it's a bug in your setup, in MakeMKV or both.

Can you make a full disc backup to HDD first and ensure that there are no hashcheck errors. After that, would you get a consistent result when opening files from this backup instead of original disc?

Is there a way to install three versions of MakeMKV at the same time (1.6.5, 1.6.8, 1.6.10)? This would make the process easier.

Also, can I install an old version over a new one, without doing an uninstall, or would it keep some of the newer DLL's? Also, do I need to do more than just an uninstall to get a "clean" uninstall? I want to make sure that no results are affected because some file versions get mismatched.

[crowfax]

Is there a way to install three versions of MakeMKV at the same time (1.6.5, 1.6.8, 1.6.10)? This would make the process easier.

On Windows yes, just install to different directories.

Also, if all you need are files from a certain version, you can extract them from the installer using 7-Zip.

[Ventura]

Just out of curiosity, but is there a way to run 1.6.5 short of having to set your system's time back? I've had problems with rips from both 1.6.8 and 1.6.10 also, but 1.6.5 complains it's too old and won't take any keys.

[KYThrill]

Just out of curiosity, but is there a way to run 1.6.5 short of having to set your system's time back? I've had problems with rips from both 1.6.8 and 1.6.10 also, but 1.6.5 complains it's too old and won't take any keys.

Well, my 1.6.5 appears to be running off the latest key. I had 1.6.10 installed when the key expired. I added the new key and got 1.6.10 working. The I reinstalled 1.6.5 and it continued to work and appears to be using the new key.

[Ventura]

Well, my 1.6.5 appears to be running off the latest key. I had 1.6.10 installed when the key expired. I added the new key and got 1.6.10 working. The I reinstalled 1.6.5 and it continued to work and appears to be using the new key.

Thanks mate, that did it. Entering the current key in a more recent version (either 1.6.8 or 1.6.10) allows me to run 1.6.5 without setting the time back.