www.makemkv.com

Yes, I think that’s right. Would be great if there were some way to disable jamless play.

Just ran into this issue as well. Anyone find any workarounds/techniques for avoiding bad data coming back from the drive?

I have an Archgon BD drive that sdftool identifies as HL-DT-ST_BD-RE_BU40N_BU10_211705301728_MO4KCTD5208. I am trying to rescue some of my scratched discs both with Libre and standard firmware. I've noticed that in both cases ddrescue often completes showing 0 errors and 100% success, but there are ...

Thanks for the explanation. Is there any workaround with either factory or libre firmware? One problem with this feature is you have no way to know which sectors are actually bad so you couldn’t use ddrescue to create a good image (either just by trimming and scraping one disc, or by combining the g...

So restoring the firmware (to DE_flash_HL-DT-ST_BD-RE_BU40N_BU10.bin) seems to have fixed the problem. With the Libre firmware, makemkv failed entirely when it hit the bad area and stopped copying. With the original firmware, makemkv is able to power through -- it successfully copied the file, notin...

You can use the de firmware i edited its all original except for 1 value change to allow downgrades Or go to lgs website and put the latest 1.04 of but I'm telling you it's a waste of time and your just risking your drive for no reason Sorry if I'm being dense--where do I find the de firmware? I se...

instructions for re-imaging the firmware that came with the drive? I have a tar file I created using sdftool dump before imaging Libre, but it's not clear to me what steps I take to restore those files to the drive. The tar file contains: fd_fwdate.bin fd_sn.bin inq.bin rom_003000.bin rom_1EC000.bi...

might be a bad memory issue. its also possible that libedrive itself mucks with the content. experiment with a disc that makemkv doesn't complain about and see if the same thing happens (i.e. that you get diffrent checksums each time) I have processed several other BD discs (using both MakeMKV and ...

Further update--I've now run ddrescue six times, some without "blessing" the disc first, some after. Each time results in a file with a different md5sum, despite the fact that ddrescue reports 100% rescued. Could this be a Libre firmware issue? Should I try to restore the original firmware?

I have a BD-RE HL-DT-ST BD-RE BU40N flashed with Libre firmware 1.04 (21200506). I own a slightly scratched BD that I am trying to backup with the method recommended here — first use makemkvcon to “bless” the disc, then ddrescue -b2048 to make an ISO copy. ddrescue completes with 0 errors, and repor...

How would you mount the ISO as a "virtual drive" in Linux? The conventional method is to mount an ISO as a loopback device, in which case makemkv doesn't have an option to open the device, only a file within the already mounted filesystem. Once you open a file like discatt.dat, makemkv gr...

One clunky solution that works -- I created a Linux VM and added the ddrescued ISO as an optical device, so it shows up as /dev/cdrom. makemkv from within the VM is then able to rip/decrypt it normally from that device node. Seems like it should be possible, then, to do this without a VM.

Enable LibreDrive before you use dd rescue. Then mount the resulting iso as a virtual drive, open makemkv and select the backup option to make a decrypted folder backup. How would you mount the ISO as a "virtual drive" in Linux? The conventional method is to mount an ISO as a loopback dev...

You need to provide information that MakeMKV usually gets from asking the drive for. Search for "discatt" here on the forum for how to obtain it (assuming you have the original disk). Right, I do have the relevant discatt.dat file. But how do I tell makemkvcon (or makemkv) to make a decry...

https://makemkv.com/forum/viewtopic.php?f=12&t=17087&p=60530&hilit=discatt#p60530 This appears to be something slightly different -- if I make a decrypted backup of a physical disc, I can use other tools like VLC, ffmpeg, etc, directly on the m2ts files that have been thus decrypted. Th...