www.makemkv.com

My wife and I were watching Raiders of the Lost Ark yesterday (she told me specifically that she was in a mood to see Nazis get melted). We were watching a copy of the movie when playback stuttered and skipped about 12 minutes in. Then again about 25 minutes in. This movie was ripped using MakeMKV and then processed with Handbrake, god knows how long ago.

I tried rebooting my video player (a Zidoo Z10 Pro) and that didn't help. I pulled out the Blu-ray and we watched that instead.

After the movie was over I messed around some more, seeing if I could play the file on the Zidoo again. This time, instead of just stuttering, playback simply stopped immediately when a snag was reached. As a side note, whatever was wrong with the file, VLC didn't care. VLC played the file (at least at the trouble points I tested -- not like I watched the entire movie again) without a problem.

So I began to wonder: Is there any way to find possibly corrupted or otherwise troublesome MKV files ahead of time, and proactively repair them before finding out the hard way there's a problem, while trying to relax and enjoy a movie? A quick Google search led me to mkvalidator, a command-line tool.

mkvalidator definitely showed some issues with the problem file, but all warnings, no errors, and declared the file valid. I nevertheless re-ripped my Raiders Blu-ray and created a new MKV file which mkvalidator had no complaints about. My Zidoo was also much happier with that file.

So I've started a long, slow automated process running mkvalidator on my entired ~20TB collection. Just a short way into this process, however, I'm finding lots and lots of mkvalidator warnings, but no official errors yet.

One type of warning I trust to be entirely benign is this:

WRN0D0: There are xxxx bytes of void data

This appears to be nothing more than a warning about extra space created by editing metadata (as with MKVToolNix), space which could be reclaimed by remuxing if you cared enough.

This also seems to be safe:

WRN103: Unnecessary secondary SeekHead was found at xxxxxxxxxx

Beyond that, I'm not sure which warnings are safe to ignore. This warning occurred several times in the faulty copy of Raiders of the Lost Ark:

WRN0C2: The timecode of the Cluster at xxxxxxxxx is not incrementing (may be intentional)

But I'm also seeing this error in more files than I think are likely to be bad, given that I've done quite a bit of viewing before this first playback glitch while watching Raiders.

Here are some other types of warnings I've seen crop up in my automated validation. I have yet to pick one of the files with these warnings and try playing it from beginning to end:

WRN0B8: Track #4 is defined but has no frame
WRN0C0: First Block for video track #1 in Cluster at 320857186 is not a keyframe
WRN0E7: DisplayUnit seems to be pixels not aspect-ratio for Video track #1 1920px width from 1920
WRN861: The SegmentInfo (or TrackInfo, Cues, Tags, Chapters) is not referenced in the main SeekHead

If I were to re-rip everything with any one of these warnings that would be a LOT of work, and probably not necessary. If I finally hit any actual errors, not mere warnings, I'll certainly re-rip those files.

Can anyone recommend other MKV validation tools that might give me more confidence about which files of mine might need work?

I don't have any experience with mkvalidator.

Last year a user on this forum was looking for the source of occasional corruption in his collection. It turned out to be a bad USB chip on the computer if I recall correctly. The user did, however, have a ffmpeg command to test .mkv files for corruption.

Strange corruption issue - MakeMKV's fault or bad HDD?

pneumatic wrote: ↑

Sat Apr 01, 2023 9:02 am

…
I found I could test for corruption using ffmpeg:

Code: Select all

ffmpeg -v error -i "C:\MyVideo.mkv" -f null NUL

Ideally there should be no error messages, but in my experience many DVD's will produce some benign error messages, but the corrupted mkvs have different error messages and more of them so they are still identifiable from non corrupted mkvs.

dcoke22 wrote: ↑

Mon Dec 16, 2024 6:00 am

The user did, however, have a ffmpeg command to test .mkv files for corruption...

Thanks! I'll give this a try.

RasterEyes wrote: ↑

Mon Dec 16, 2024 6:29 am

dcoke22 wrote: ↑

Mon Dec 16, 2024 6:00 am

The user did, however, have a ffmpeg command to test .mkv files for corruption...

Thanks! I'll give this a try.

This turns out to be a very slow, and didn't reveal any warnings or errors where mkvalidator did.

The problem could be, of course, that my Zidoo might be sensitive to issues that it shouldn't be sensitive too, so I might not be able to reliably detect, with any tool, whatever it is that upsets the Zidoo.