hash table, checksums… How to verify ripped data after rip?

Everything related to MakeMKV
Post Reply
mattmkv
Posts: 9
Joined: Sun Dec 13, 2015 8:52 pm

hash table, checksums… How to verify ripped data after rip?

Post by mattmkv »

Hello!

I am seeing the following in the logs really often:
Loaded content hash table, will verify integrity of M2TS files
What does that mean? Is there a file containing checksums for every M2TS file of the Blu-ray disc?

Where can I find it? I want to verify my M2TS files after a rip.
Woodstock
Posts: 10293
Joined: Sun Jul 24, 2011 11:21 pm

Re: hash table, checksums… How to verify ripped data after r

Post by Woodstock »

Actually, if MakeMKV doesn't say the rip failed, the checksums passed.

There is documentation on the web that describes the hash table, though.
mattmkv
Posts: 9
Joined: Sun Dec 13, 2015 8:52 pm

Re: hash table, checksums… How to verify ripped data after r

Post by mattmkv »

I got two rips, but they differ minimal. Same disc, same blu-ray drive, same hard disk (NTFS).

first rip (sha256sum):

Code: Select all

2217abcb8f012d9a44ce71dfe75c522c7705cd80fab98f96231fab49b88b4dbd  JURASSICWORLD_UPB1/BDMV/STREAM/00800.m2ts
second rip (sha256sum):

Code: Select all

04978d37ef953227c64194902893c78b4c1617d580a15996c48f5f7d618a8f6c  JURASSICWORLD_UPB1/BDMV/STREAM/00800.m2ts
first rip:

Code: Select all

Debug log started at Mon Dec 14 19:08:36 2015 , written by MakeMKV v1.9.7 linux(x64-release)
Using 524544KB for read cache.
001005:0000 MakeMKV v1.9.7 linux(x64-release) started
001004:0000 Debug logging enabled, log will be saved as /home/mint/MakeMKV_log.txt
005072:0000 Backing up disc into folder "/media/mint/BOOTCAMP/linux/Videos/backup/JURASSICWORLD_UPB1"
005050:0000 Evaluation version, 30 day(s) out of 30 remaining
DEBUG: Code 2147483648 at PR?DHGHxB~:D~K5M:121265315
DAFD=PAAAADAAAAEABDQkEHwECAQ==
DCE=vqr+ueFJVjPfXZWZk9H1yxQJirg0SuYBYz/SPArFHBQcaPjqMSO3IlQ4os3DGTDNOc+97ZvtkQjXCQjNTVQxoIGOCdRcJL8lc/VEpEqUWi+CXXbUzab2o0GShh/6SWS7fLpzr3Aibt+ZYHIg8jPJpkKdLKaunkzEkw==
DCE=4DTHfhlfFM7sHbYKyXSq7e5lSv59azcY0MzUggrH4ug8iM7DNtaSxkbqQ09K1Pte2MCJCoFgKp+j4q/3uDtTrJiYi3Q10q9fqYOLBb3JQaYhHW5hSQXT2EkaFNe5hsnxRb/jIkN0IQXGLAgPBy/GhOuIVCHvXG09pA==
005085:0000 Loaded content hash table, will verify integrity of M2TS files.
005070:0080 Backup done
005081:0104 Backup done.
Application exited at Mon Dec 14 20:52:23 2015
second rip:

Code: Select all

Debug log started at Wed Dec 16 20:35:57 2015 , written by MakeMKV v1.9.7 win(x64-release)
Using 524544KB for read cache.
001005:0000 MakeMKV v1.9.7 win(x64-release) started
001004:0000 Debug logging enabled, log will be saved as C:\Users\User1/MakeMKV_log.txt
005072:0000 Backing up disc into folder "C:/2jurassic/backup/JURASSICWORLD_UPB1"
DEBUG: Code 2147483648 at '(&byawYai[o+:&o:121265315
DAFD=PAAAADAAAAEABDQkEHwECAQ==
DCE=WnOYymAFKhNjAE5yE3D39cioQ0X/emqNB4OhSs/OhCAAYTGXDhdu10Jz+qOkQ4kOoFrxjq3c7xRvJYjnSz1F8JAwc6zK0meZGwTflHth/gT9AI6n2kwmWJZ3kwxYXD1n6djIaGobuVQdi4tEyO5FFZW2EMaVyaar5g==
DCE=UgIsEuoVQzJdHpaQSEjYmABjROxKF544elABRnTOFx/ArKxhABeCLg6+CgxquqWpUoCC4zeK/+vSKQ3BQVHpobrK2wUSPiopCaD10sEyutUXbnyQ/a4UAihQqzeleDeJoR4tjfL6JVeJ7jMVR731Pe4WY8MG+322GQ==
005085:0000 Loaded content hash table, will verify integrity of M2TS files.
005070:0080 Backup done
005081:0104 Backup done.
Application exited at Wed Dec 16 21:52:21 2015
I am note sure. Maybe data rot or something? :?

Image
mattmkv
Posts: 9
Joined: Sun Dec 13, 2015 8:52 pm

Re: hash table, checksums… How to verify ripped data after r

Post by mattmkv »

I compared the file 00800.m2ts with another decrypted rip (source: raw image created by ddrescue) and my second rip seems to be fine.

A globally checksum database for m2ts-files would be awesome. :mrgreen:

Maybe something like AccurateRip (audio) for Blu-ray discs.
mike admin
Posts: 4075
Joined: Wed Nov 26, 2008 2:26 am
Contact:

Re: hash table, checksums… How to verify ripped data after r

Post by mike admin »

mattmkv wrote:I compared the file 00800.m2ts with another decrypted rip (source: raw image created by ddrescue) and my second rip seems to be fine.
This is not right, you should get two absolutely identical M2TS files[/quote]
mattmkv wrote: A globally checksum database for m2ts-files would be awesome. :mrgreen:
Maybe something like AccurateRip (audio) for Blu-ray discs.
Each blu-ray disc contains hashes of all M2TS files. This feature is part of AACS protection, not for integrity. Yet it can be used to verify M2TS integrity. Files are hashed in blocks of 96K, so depending on file size up to 90K at file end may be not hashed. MakeMKV checks these hashes in all modes, both backup and MKV. If you get no error messages then it means that all hashes were validated.
baronluigi
Posts: 16
Joined: Thu Jul 13, 2017 3:06 pm

Re: hash table, checksums… How to verify ripped data after r

Post by baronluigi »

mike admin wrote:
mattmkv wrote:I compared the file 00800.m2ts with another decrypted rip (source: raw image created by ddrescue) and my second rip seems to be fine.
This is not right, you should get two absolutely identical M2TS files
mattmkv wrote: A globally checksum database for m2ts-files would be awesome. :mrgreen:
Maybe something like AccurateRip (audio) for Blu-ray discs.
Each blu-ray disc contains hashes of all M2TS files. This feature is part of AACS protection, not for integrity. Yet it can be used to verify M2TS integrity. Files are hashed in blocks of 96K, so depending on file size up to 90K at file end may be not hashed. MakeMKV checks these hashes in all modes, both backup and MKV. If you get no error messages then it means that all hashes were validated.[/quote]

What I usually do is to rip the file twice and make a SFV file of each rip.
rkjnsn
Posts: 17
Joined: Tue Aug 24, 2010 7:03 am

Re: hash table, checksums… How to verify ripped data after r

Post by rkjnsn »

mike admin wrote:
Mon Jan 18, 2016 10:33 am
Each blu-ray disc contains hashes of all M2TS files. This feature is part of AACS protection, not for integrity. Yet it can be used to verify M2TS integrity. Files are hashed in blocks of 96K, so depending on file size up to 90K at file end may be not hashed. MakeMKV checks these hashes in all modes, both backup and MKV. If you get no error messages then it means that all hashes were validated.
For anyone else who runs into this, files are actually hashed in blocks of 96 sectors of 2048 bytes, so blocks of 192 KiB, not 96 KiB. It also looks like the offset of the error reported by MakeMKV is actually somewhere toward the end of the failed block, not the beginning of it. So if MakeMKV reports
Hash check failed for file 01068.m2ts at offset 1083697152, file is corrupt.
It means that the failed block is the 192 KiB block starting at the offset: floor(1083697152 / 196608) * 196608 = 1083506688
Post Reply