Submit AAC v82 dump, Mecha-Ude Vol.4 JPN

[Keloid]

Already emailed svq@makemkv.com but just in case.

[MrPenguin]

Already emailed svq@makemkv.com but just in case.

Have you tried running SamuriHL's KEYDB Helper tool for this disk?

I understand that SamuriHL has also recently added a "validate disc" option...

[Keloid]

No. The issue, what i doubt, is that aacskeys do not return valid keys when VID start with 0x00. The given VID is 009BF53E840944CA2C4CEBFB94129889 but aacskeys change it to 9BF53E840944CA2C4CEBFB9412988900 arbitrarily and then calc it.

I really hope if somebody able to troubleshooting this. Before this specific VID begin with 0x00, i didn't have problem to calc v82 keys by my own.

[MrPenguin]

I really hope if somebody able to troubleshooting this. Before this specific VID begin with 0x00, i didn't have problem to calc v82 keys by my own.

There are only two ways to fix an incorrect KEYDB entry:

• Ask the DB maintainer to fix it manually.
• Execute "findvuk validateDisc drive=<your drive letter>" to upload a validated replacement entry.

If you own the physical disk then executing "findvuk validateDisc" is much, much faster.

[Keloid]

I just did it and obviously It's invalid. I don't see the point.

[MrPenguin]

I just did it and obviously It's invalid. I don't see the point.

Did you execute "findvuk synchronize" first?

But the point is that since you own this physical disk, you are the best person to fix this disk's entry. "findvuk validateDisc" wants to validate the Volume Unique Key (VUK) and/or the Unit Keys(s) in a KEYDB entry, so you need to add the correct value for at least one of these keys into KEYDB.cfg, remove any keys that you know are incorrect, and then execute "findvuk validateDisc" again. This will then replace the current incorrect entry with a validated entry.

"validateDisc" is also a good way to ensure that the keys you upload are correct. However, this means that it will only upload values that it can prove are correct. The only way to prove that a VID or a MK is correct is to use it to calculate a working VUK, which in turn means that a verifiable KEYDB entry would need to contain either both VID and MK, or neither VID nor MK.

[SamuriHL]

I'm not sure what my tool will do in this case. The info is complete but wrong. I'm not sure I handle that case at the moment. I need to think about that as it's a lot more common than any of us would like and the VUK is recalculated. But I don't think I check it against the keydb entry to see if it's different and probably should. Then we can fix this kind of crap more easily.

EDIT: Also if somehow the entry that's in the keydb is already "validated" status, then the KeyDB will create a new entry which causes problems. Nalor had to deal with this a few weeks ago on someone else's entry. It's a bit ugly.

[MrPenguin]

I'm not sure what my tool will do in this case. The info is complete but wrong.

Looking at that entry, it's missing its MK but I think the VID is correct. However, I don't believe FindVUK can validate a VID without also having the MK.

I suggest deleting both the VID and VUK values from that KEYDB entry, and then re-executing "findvuk validateDisc".

[SamuriHL]

Looking at that entry, it's missing its MK but I think the VID is correct. However, I don't believe FindVUK can validate a VID without also having the MK.

I suggest deleting both the VID and VUK values from that KEYDB entry, and then re-executing "findvuk validateDisc".

For blu-ray, I recalculate the MK, VID, VUK, and UKs anyway assuming they provide a valid device key in their local keydb. What I didn't do in this case when there's a discrepancy is recreate the keydb entry. That needs to happen before the validate disc is executed. It's a fairly simple code change but I likely won't get to it today as I've had a VERY long day already. But I will update it hopefully tomorrow to do this. Then it'll fix these kinds of issues.