I backed up my disks over time as full, decrypted bdmvs but I suspect either the ripper box or the NAS has/had intermittent RAM issues due to spurious video glitches during playback.
In order to bit check the bulk of the bdmv data, is it possible to check against the original content hash table again? I'd rather re-rip only the corrupted ones.
Thus, use data from MAKEMKV/ folder to re-encrypt the files for which content hash entries exist and check.
Or is there some essential key derivation material missing from the MAKEMKV/ folder?
Am also happy to go spelunking through the source(s) but would appreciate some pointers.
content hash re-verification
Re: content hash re-verification
You can load a backup into MakeMKV and make a .mkv from it. I wonder if that process checks the .m2ts files against the content hash table? If it did, then I would guess making a .mkv from a corrupted backup would result in an error.
-
contenthasher
- Posts: 2
- Joined: Sun May 01, 2022 6:22 pm
Re: content hash re-verification
Afaict from the AACS specs, the content hash table is over encrypted (or plaintext) original .m2ts files.
Hash values per 96 sector sized chunks at 2KB per sector, and remaining tail less than 96 sectors does not deserve a hash.
Pulling a .mkv out of the backed-up BDMV folders does complain for some but only if the corruption did hit meta data vs. content.
So re-loading is a viable first level check but I have seen plenty decode glitches make it past it.
Does makemkv replace the encrypted content hashes with hashes over the decrypted chunks? That'd be handy and it does have all the bits on hand during the decryption step. Short of that, for my existing catalog sure seems that re-encrypting and hash checking against original content hash table would provide the most accurate measurement?
Hash values per 96 sector sized chunks at 2KB per sector, and remaining tail less than 96 sectors does not deserve a hash.
Pulling a .mkv out of the backed-up BDMV folders does complain for some but only if the corruption did hit meta data vs. content.
So re-loading is a viable first level check but I have seen plenty decode glitches make it past it.
Does makemkv replace the encrypted content hashes with hashes over the decrypted chunks? That'd be handy and it does have all the bits on hand during the decryption step. Short of that, for my existing catalog sure seems that re-encrypting and hash checking against original content hash table would provide the most accurate measurement?
Re: content hash re-verification
I didn't realize the content hash table was hashes of the encrypted content. I would doubt (though I don't know one way or the other) that MakeMKV replaces the content hash table with hashes of the decrypted content. MakeMKV is focused on making a 1:1 copy of the disc and generally doesn't create or synthesize data.
Re: content hash re-verification
I wonder if you could crank up MPV's log message level (or your player of choice) and let it play movies in the background and then grep your way through the log looking to telltale errors?
If there's been some bit-rot of your files, you'd think it would mess up the playback just enough that a player might notice a broken time code or something but be able to recover.
If there's been some bit-rot of your files, you'd think it would mess up the playback just enough that a player might notice a broken time code or something but be able to recover.