www.makemkv.com

http://www.makemkv.com/faq/item/12

says to set the keydb folder. Only problem is I dont see such an option in preferences. Can someone please help me?

For some time, MakeMKV uses a single directory for all its files (aacs keys, SVQ files, profiles, etc). Now it's called "MakeMKV data directory" in preferences.

hmm, I tried that and it didnt work. I tried an older version with the keys directory option and worked perfectly first time.

perhaps the newest version has a bug with detecting the keydb file? I need to manually use the keys since I use my ps3 to make "incomplete" dumps.

EDIT: after my current encode finishes I'll reinstall 1.7.0 and try again.

Please check the keyfile filename. The key file must have one of the following extensions: *.txt , *.htm , *.html, *.key or *.cfg .

Hi all,

First, Mike let me say that MakeMKV is a great utility for full-quality A/V media backup, and I'm generally a very happy (registered) user!

However, I too have found that AACS Volume Unique Key (VUK) lookup no longer works in recent v1.7.x versions, at least not under Mac OS X 10.6.8... Specifically, I happen to have an encrypted backup Blu-ray folder of 'Scream 4' that at some point I'd copied as-is (via the Finder) to an external hard drive from my original disc. Of course, since then I've used MakeMKV 1.7.x to also make a decrypted full backup BD folder, which I use for everyday playback in VLC 2.0.x. :-) Interestingly though, it turns out that VLC can successfully play the DRM'd BD folder too, once I placed the appropriate Disc ID / VUK entry into my ~/.config/aacs/KEYDB.cfg database file used by VLC's libaacs library.

Recently, I was experimenting with opening that same DRM'd BD folder in MakeMKV 1.7.x. I copied the working VUK entry into my ~/.MakeMKV/keydb.cfg database file (with a slightly modified syntax for the hex strings, stripping off the explicit '0x' prefix required by libaacs). The DB file's parent directory is set accordingly in the Preferences ('General > MakeMKV data directory'). Unfortunately, MakeMKV v1.7.x is not at all happy with this key DB; the resulting error messages are typically as shown here for v1.7.3: To carry out more extensive testing, I downloaded several older MakeMKV editions from both this website and VideoHelp. For me, the last version where the key DB works is v1.6.10. (This might also have been the last one where the preference for the key DB location was known as 'AACS > Key files directory'?) I.e., in v1.6.10 with the properly set preference pointing to the key DB's parent directory (and with exactly the same key DB), I was indeed able to open the DRM'd BD folder and see the title list as usual. :-)

However, with every later release that I tested (where that setting has changed to 'General > MakeMKV data directory'), from v1.6.12 up through v1.7.3, the functionality is accidentally broken. So, it does look like a regression issue that started around v1.6.12?

Kind regards,
--Paul

Yes, you re absolutely correct - this is a bug introduced few versions ago that no one noticed. Please see http://www.makemkv.com/forum2/viewtopic.php?f=8&t=4792 , you need place your cfg file in both MakeMKV and "current" directory.

Okay, thanks for the news... The suggested workaround is effective under OS X as well. :-)

I found it easiest to automate the launch by using a small "command" file (a text file that has a '.command' extension, is marked executable, & opens in Terminal when double-clicked). This command file just contains a short 'bash' shell script to first 'cd' into my MakeMKV data directory, and then launch the MakeMKV exec in asynch mode (/path/to/MakeMKV.app/Contents/MacOS/makemkv &). Double-clicking this command file ends up spawning a fully detached instance, so after quitting Terminal, I'm left with a running MakeMKV app whose current directory is my MakeMKV data dir. With this approach, the key DB lookup works fine. (It also avoids having to copy or sym-link the key DB files elsewhere, which is nice for lazy ole me; hopefully it won't have side-effects down the road, but if so, I'll just revert to making copies/sym-links somewhere else & running the exec from there.)

[Actually, just for fun, it's possible to get even more automated & avoid Terminal altogether, by making a double-clickable AppleScript (AS) applet that runs the above script via the 'do shell script' AS command. There are some additional redirection tricks needed to persuade the applet to not wait around on the spawned MakeMKV instance; the details are in Apple's Tech Note TN2065 'do shell script in AppleScript' (the 'Other Concerns' section). This applet technique does work fine too. ;-)]

Anyway, I'm happy with the workaround until a subsequent MakeMKV release can fully resolve the issue.

Thanks again,
--Paul

Mike, many thanks for the recent v1.7.4 release which (along with its other improvements) once again respects the configured data directory when looking for AACS key DB files.

With the appropriate Volume Key entry present in a DB file, for testing purposes, I was indeed able to successfully extract the main title from my as-is/encrypted backup BD folder of 'Scream 4'. [Well, actually I first had to use MakeMKV to make a new as-is backup because the older Finder-copied backup yielded several 'corrupt or invalid at offset ...' errors (no doubt due to some "feature" of my BD drive, or bit rot, or whatever).]

Thanks again,
--Paul

mike admin wrote:Yes, you re absolutely correct - this is a bug introduced few versions ago that no one noticed. Please see http://www.makemkv.com/forum2/viewtopic.php?f=8&t=4792 , you need place your cfg file in both MakeMKV and "current" directory.

Hey guys, it's now 2017, a few years later from the creation of this post. I am on a Mac and using Plex to play my BlueRay MKVs. I am trying to convert BlueRay ISOs to MKV. I have a recent KYEDB.cfg but I can't make MakeMKV to recognize it. Any instructions?

MakeMKV uses the directory set in Preferences->General->MakeMKV directory to handle all user-supplied files, as well as SVQ files downloaded from makemkv.com and dump files it generates that should be sent to Mike. As far as I can tell, that's where the third-party AACS key database would be placed.