Page 1 of 1
hash table, checksums… How to verify ripped data after rip?
Posted: Tue Dec 22, 2015 12:54 am
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.
Re: hash table, checksums… How to verify ripped data after r
Posted: Tue Dec 22, 2015 2:20 am
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.
Re: hash table, checksums… How to verify ripped data after r
Posted: Sun Jan 10, 2016 10:16 pm
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?
Re: hash table, checksums… How to verify ripped data after r
Posted: Tue Jan 12, 2016 12:06 pm
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.
Maybe something like AccurateRip (audio) for Blu-ray discs.
Re: hash table, checksums… How to verify ripped data after r
Posted: Mon Jan 18, 2016 10:33 am
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.
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.
Re: hash table, checksums… How to verify ripped data after r
Posted: Sat Apr 21, 2018 10:08 pm
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.
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.
Re: hash table, checksums… How to verify ripped data after r
Posted: Thu Jul 23, 2020 11:50 pm
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