Is there any software to scan a MKV file for errors?

[Radiocomms237]

As the title says, is there any software available that will scan a .mkv file and detect pixelation or any other video defects without me having to watch the video myself?

I realize any such software may detect false positives, like when filmmakers try to make part of a film look old (grain, sepia, static, etc.) but I'd be happy to verify anything like that myself afterward as that happens only rarely, just so long as it picked-up and reported any actual video defects as well.

I want to check files straight away, while I still have everything open and setup (and easily re-rippable/re-encodable), as sometimes I don't watch a title off my media server until months later.

Any suggestions?

[Billycar11]

i dont believe there is currently a way to do it automatically
i have a similar want but not so much for pixilation but for just knowing what the hash is at the end of a rip and make sure it does not change in the future
i recently had a stick of ram go bad in my ripping pc caused lots of hash errors so found out what was wrong very quick but i wonder if it sometimes silently corrupted things as it was writing them to disc and makemkv didn't catch it but makemkv seemed to always catch it but it would be nice to know for sure.
but we would have had to manually make a hash right after we back it up and then check against that so for me its to late

but who knows maybe there is a secret hash built in to the makemkv file mike or woodstock might know.

[Radiocomms237]

I know MakeMKV says "Loaded content hash table, will verify integrity of M2TS files", but I have several reservations about that particular statement...

I *think* it can only verify the transport streams on the actual disc itself, prior to ripping, for two reasons:

Firstly, the files on the disc are (most of the time) encrypted so I would assume the hashes within the table are generated on the encrypted versions of the transport streams? Once decrypted, I'd think the content hash table would be useless?

And secondly, even if the hashes are generated on the decrypted files, playlists (and therefore the ripped .mkv files) are often a compilation of many transport streams, then MakeMKV often removes frames here 'n there to re-sync tracks as well, so again, the content hash table would be useless for verifying the end result.

So I think the bit about verifying the integrity of M2TS files gives a kind-of false sense of security?

Further to that, I more-often-than-not end-up re-encoding my .mkv files to reduce the overall size (GB-wise), which introduces another possible point of failure, and then there's disc errors as you describe on top of that.

Knowing what can be done with video analytics these days, I'd be surprised if it couldn't be done, but has it been done?

[dcoke22]

Firstly, the files on the disc are (most of the time) encrypted so I would assume the hashes within the table are generated on the encrypted versions of the transport streams? Once decrypted, I'd think the content hash table would be useless?

https://aacsla.com/wp-content/uploads/2 ... ed.921.pdf\

See section 2.3.2.1 on page 10. If the blu-ray is encrypted, the hash is generated on the encrypted data.

[Radiocomms237]

Thanks.

So that would seem to confirm that MakeMKV can only verify the data on the optical disc, it can't actually verify that the file was copied to a PC's hard drive without errors, or that a file from a backup directory is error-free.

That's how I figured it must work.

[dcoke22]

By checking the content hash table, MakeMKV can verify that the bits read from the optical disc match what is expected. My guess is errors from reading the disc in the optical drive are the most likely source of corruption. There's then the decryption process and other processing in memory as the bits from the optical disc get assembled into either a .mkv file or the files of a backup. It seems very unlikely that the data will be corrupted during its time in your computer's memory on its way to your disk, although not impossible.

If you're really concerned about that, you probably need a PC with ECC memory in it.

It is more likely that after the file lives on your hard drive for some time and you read it back you might get a read error that perhaps goes undetected. For that, the best thing is probably making a hash of the file(s) at the time they are written to disk. You could periodically check the files against the stored hash. You won't necessarily be able to recover the now corrupted file, but you can detect the corruption and restore from a backup.

[EvilWarMachine]

The way I do it, which I discovered by accident, is to add the rip to Subtitle Edit (this can take up to 10 minutes on my device to process but more recent PCs will process quicker). I then scroll to the end of the subtitles to see if it has processed the final subtitle (it's normally "Subtitles created by xxx"). The rips that have glitches or errors normally stop processing the subtitles when the first glitch occurs. This has been my experience, anyway.

Only useful if you include subtitles with your rips, obviously.