updated solution to MakeMKV/Handbrake?

[morpheus1]

Hello,

I've just now tried this solution:

mkdir ~/lib
ln -s /Applications/MakeMKV.app/Contents/lib/libmmbd_new.dylib ~/lib/libaacs.dylib
ln -s /Applications/MakeMKV.app/Contents/lib/libmmbd_new.dylib ~/lib/libbdplus.dylib

So that I can rip straight from Handbrake. After doing the above Handbrake crashed at each lunch. I narrowed down the problem by trying to open the same disc with Handbrake it opened before. It crashed. Second, I removed the directory, and Handbrake opened the disc.

My version of MakeMKV: 15.1
My version of Handbrake: 1.3.3
My version of VLC: 3.0.8
MacOS: 10.11.6

Like many, I'd like to skip the rip first with MakeMKV and rip straight with Handbrake.

Thanks a lot for your help.

[Woodstock]

Like many, I'd like to skip the rip first with MakeMKV and rip straight with Handbrake.

So, what advantage does ripping straight with handbrake give you?

Can you quickly recover from, "Oops, it wasn't subtitle 3 I wanted!", or "Why does the movie audio have someone describing the movie?" errors?

[morpheus1]

Like many, I'd like to skip the rip first with MakeMKV and rip straight with Handbrake.

So, what advantage does ripping straight with handbrake give you?

Reduced a two-step process to 1.

[Woodstock]

You have said that. However...

Running handbrake this way has several disadvantages.

The first of which is that you toss out error handling for disk read errors. Handbrake will happily finish up a partial encode if you hit a smudge on the disk, with nothing reported in the logs except that the input ended. This is why the handbrake team deprecated use of 3rd-party decryption methods over a decade ago.

If you happen to catch the error and you're trying to rip more than one item from the disk, your choice becomes letting the rip continue (hoping no other errors occur), or aborting your whole queue to clean the dirty disk. Remember to export your queue in hopes that you can reload it and start again before you stop it.

Next is how slow encoding is. With a UHD disk, you may have the buffer full and the disk stops... so you hope your drive doesn't have the "sleep bug" that means it won't start back up again. When your encode choices push the encode frame rate to single digits, this is a major issue.

If you have more than one disk to rip, you have to wait for one encode to finish before you can swap disks. You cannot even set up the queue to encode the next disk until you swap it.

Running MakeMKV separately, you can even have multiple drives ripping disks, while handbrake makes its way through an encode queue. And, if you find that you have made bad encoding choices, you still have the raw MKV file to try again.

[morpheus1]

You have said that. However...

Running handbrake this way has several disadvantages.

The first of which is that you toss out error handling for disk read errors. Handbrake will happily finish up a partial encode if you hit a smudge on the disk, with nothing reported in the logs except that the input ended. This is why the handbrake team deprecated use of 3rd-party decryption methods over a decade ago.

If you happen to catch the error and you're trying to rip more than one item from the disk, your choice becomes letting the rip continue (hoping no other errors occur), or aborting your whole queue to clean the dirty disk. Remember to export your queue in hopes that you can reload it and start again before you stop it.

Next is how slow encoding is. With a UHD disk, you may have the buffer full and the disk stops... so you hope your drive doesn't have the "sleep bug" that means it won't start back up again. When your encode choices push the encode frame rate to single digits, this is a major issue.

If you have more than one disk to rip, you have to wait for one encode to finish before you can swap disks. You cannot even set up the queue to encode the next disk until you swap it.

Running MakeMKV separately, you can even have multiple drives ripping disks, while handbrake makes its way through an encode queue. And, if you find that you have made bad encoding choices, you still have the raw MKV file to try again.

You, @woodstock are a valuable member to this community. Your response can be turned into a small book. Thanks so much. I have since stopped pursuing the foolish idea I had. Thanks so much. I was only trying to streamline and reduce steps, but obviously, I would have been creating more problems. Thanks.

I have a question, you said, " you can even have multiple drives ripping disks, while handbrake makes its way through an encode queue." What I understand by this is that if I have more than 1 bluray drive, I can use two instances of MakeMKV? Second, I can start Handbrake starting to re-encode while MakeMkV is working? Please confirm. So, far, I've been waiting until MakeMKV is done before proceeding with Handbrake. Lastly, do you know if MakeMKV allows for ripping sound off discs? I have a few music bluray and I only need the music off them. Thanks a lot.

[Woodstock]

Yes, you can have multiple instances of MakeMKV running simultaneously on one machine, each with control over one or more drives. In Preferences->IO, enable "Ask for single drive mode", and you will be asked which drives (default all) this instance should control. This will test your destination drive bandwidth; when my network was down to 100Mb/s (bad cable), it was hard pressed to keep up with one instance of MakeMKV. When that was fixed, I can run 3 at full speed, ripping BDs are up to 10x speed.

Handbrake is CPU intensive, MakeMKV is not. I regularly start handbrake on encoding as soon as I can set up the first job. It and MakeMKV are "harmonious" in that sense, because handbrake doesn't do a lot of I/O. If you have enough cores available, you could even run multiple handbrake instances (I don't have enough, but I have tested this) attacking different source files. (the handbrake team is working on automatically doing this right now, in their nightly builds)

Don't be discouraged from experimenting. I can see the value in "one step conversion", especially if you only want one thing off of a disk. It just isn't as practical once you have more than one disk, you're experimenting with different settings, or the disk isn't "perfect".

The other major problem comes when you do that next update on the operating system, and that integration breaks. The solution you list above should survive MOST of the things Apple has done to cross-program integration in the last 5 years, but there are no guarantees. Even though they do not recommend it, the handbrake team has a LOT of support requests for "why doesn't DVD reading work anymore?"

But there are a lot of things out there that are more "fun hacks" than "practical solutions". I haven't tried them all, yet, but...