hckrnws

> LibreDrive functionality is implemented as part of open-source LibDriveIO library (at the time of this writing the library source code is not yet released)

This was posted in 2019. As of today, there is still no published source code.

See this forum post[1] for some insight on the situation

[1]: https://forum.makemkv.com/forum/viewtopic.php?t=24312#post_c...

Based on this and my experience with the world, I suspect that he's protecting a revenue stream but intends to open-source the code when he retires or no longer depends on the stream.

makemkv itself is also tremendously useful.

Got some inconvenient to work with BD or DVD? Just dump it into a mkv file with makemkv, and now it is convenient to work with.

It is worth pointing out that MakeMKV has a CLI you can use it without the GUI. I have a batch file that rips the main movie from my BD drive and names the MKV based on the BD disc label. My script is old enough I wrote it myself, but ChatGPT/Claude could easily do a better job.

When combining MakeMKV's CLI and Handbrake's CLI there is an easy and very repeatable path of going from disc to an optimized MP4. Some might think it is sacrilegious to use MP4 instead of MKV. I've found MP4s with H264 video and AC3 audio can play almost everywhere (for me: Xbox, Roku, iPhone/Safari, Edge, Android, most smart TVs) now, and support surround sound.

I don't think anyone is against using different containers for compatibility, you can remux from mkv to mp4 very easily with ffmpeg directly. However it's a little odd to go through the intermediate step of using MakeMKV if you're just compressing the resulting remux using Handbrake. Usually the point of MakeMKV is to get the highest quality copies of retail media.

"... you can remux from mkv to mp4 very easily with ffmpeg directly."

According to the HandBrake docs (ISTR) mp4 can't handle multiple languages and subtitle sets, so the conversion mkv->mp4 is (potentially) lossy. I'm no expert, just trying to keep the language/subtitle sets I want, maybe I've missed something here. What I do so far is HB encode to Matroska, not MPEG-4. Then I don't lose any of the ones I want. Also I have noticed sometimes MakeMKV is not entirely inclusive in its defaults and I have to add extra languages/subtitles.

MP4 can handles up to 255 audio tracks, and 255 subtitle tracks. Maybe some players only support a single track of each, but the built-in players on Mac, iOS, and Windows support it out of the box. It only officially supports a few audio codecs, and one subtitle format (not SSA or SRT).

MP4 is the basis for HTTP Live Streaming (HLS) and multiple audio tracks and subtitles/closed captions are required for something like that.

Why would I care what the "built-in players on Mac, iOS, and Windows" support? I don't use those. But I do have a very rich media environment.

So neither comment "responding" to my comment actually responds to my query, which is about MakeMKV -> HandBrake and subtitles/language tracks. My very tentative assertion seems to be unfortunately true.

I'm going to have to add that I'm not missing any life happiness by not using the "built-in players on Mac, iOS, and Windows", and my library is better than I can stream. You'll need to kill public libraries to degrade the lives of people like me. I'm quite certain that you've got funding to do that, soul crushing media bigcorp lickspittle tools. Yer basically destructive nanite greymatter digestors at this point.

I was responding to a user saying they explicitly didn't use MKV for compatibility with players.

I don't think I understand... You are explicitly saying supported subtitle/language streams are... not important?

>However it's a little odd to go through the intermediate step of using MakeMKV if you're just compressing the resulting remux using Handbrake.

mkv makes a very usable source file to work with.

BD and DVD are not. They need to be extracted into something usable. A good form of something usable is the mkv makemkv makes.

Handbrake can open BDs and DVDs directly to rip.

Even if it handled all anti-copy schemes to perfection and had excellent handling of read errors and the like... it still requires a BD or DVD drive in the encoding computer, and to have the the BD or DVD in the drive, every time a new encode is needed.

That's highly inconvenient.

Makemkv only needs to run once. Afterwards, you can just deal with the file it creates, which is much more convenient than a disc.

I didn’t get the impression the guy encoding the resulting files (who I was responding to, not you) to H264, AC3 and didn’t seem to grok what a container was was keeping around these MKVs.

Yes, if you’re archiving blu rays MKV is king. If you’re ditching them after encoding why involve another application and step, that’s all I was telling him.

I remember several years ago when I wanted to watch a Star Wars DVD on a computer.

This was in the UK with the DVDs purchased in the UK and with a DVD reader also purchased in the UK, as that’s where I live.

Windows Media Player told me that the region of the Disc was wrong and that if I wanted to watch it, it could instruct the firmware on the DVD player to update its allowed region, but that I could only do this (I think) five times and no more.

Rather than dealing with this pompous bullshit I watched it with VLC player which just worked without doing any of that legal nonsense.

I’ve remained a big advocate of VLC ever since.

I had a tangentially related situation many (~20?) years ago when I bought a music album released under Sony, I had a sweet PC based Hi-Fi setup, and the DRM ring they'd added to the disc meant it wouldn't play back at anything above MP3 128.

I noticed a ~1.5cm ring around the outside of the disc was visibly a different colour/texture to the standard audio part; I tried blanking it out with Sharpie which some people online suggested might work, but eventually gave up and contacted Sony to tell them how pissed off I was that they were preventing PC-based music listeners from listening to what they'd bought. They sent back an apology and a new copy of the disk without the DRM/MP3 crap.

I bet LibreDrive might have worked by letting me just read the disc raw and grab the bits I need.

Sony really did crazy stuff for "copy protection" on their CDs ...

https://en.m.wikipedia.org/wiki/Sony_BMG_copy_protection_roo...

“Sony BMG initially denied that the rootkits were harmful. It then released an uninstaller for one of the programs that merely made the program's files invisible while also installing additional software that could not be easily removed, collected an email address from the user and introduced further security vulnerabilities.”

That’s diabolical

It was likely very illegal as well, but you know big company and a legal system that is/was decades behind the state of the art

[dead]

I had a similar issue, of moving from the US to Germany in 2000 and my spouse bringing her favorite DVDs with us. However, once we got there, she was unable to watch any of them, as all the DVD players were for the EU region, while her DVDs were for the US.

She is not a technical person, but she is now very acutely aware of B.S. restrictions like this (and later DRM on mp3s) and how to get around them.

Steve Jobs famously called Blu-ray's licensing (presumably mandating annoying DRM requirements at the OS, driver, and device level) a "bag of hurt" - but it probably didn't hurt that Apple already had a competing "iTunes" movie download store, whose annoying DRM requirements Apple happily implemented at the OS, driver, and device level.

In any case, rip/mix/burn never really made it to iDVD or iMovie (or QuickTime Player), and Apple never shipped Blu-ray movie player software for Macs.

This is called freedom

Using libredrive supported devices - would we get some other advantages? Like being able to read from old and broken CDROM and DVD devices more reliably?

No, it actually makes it "worse" in that most usual DVD players and drives will do a "best effort, but keep going" type of read which may result in a pop or skip or desync for a moment on playback - but these tools are archival and refuse to read if they can't read correctly.

It's actually quite annoying at times, for example it's often better to rip audiobooks with iTunes and then grab the files and delete it from iTunes than to use something like XLD directly.

I love how we have gone full circle on retro technology.

Very interesting set of posts. I feel that when this website goes dark and the last grey-beards stops blogging, this kind of arcane information will be lost forever.

This makes me sad.

But but but but AI will remember!

That does make me think about the fact that AI LLMs could be useful at archiving specific fields that are "obsolete".

An archive of documents, presentations, research papers tech specs, relevant code, etc could be prepped and expended over the years for the field/technology/etc. it would be nice having an LLM specifically known to target that body of knowledge so the prompt subclauses to filter out the rest of the general internet bullcrap.

Correct me if i'm wrong but its not even exploiting some firmware bug or anything.

Think there is a 'plugin interface' in those firmware that exposes whatever is needed to read the raw data so all it does is uses that interface to dump data instead of using the official calls. IIRC its why the read speeds are slower.

Source: some post on the same forum couple of years ago.

Depends on the drive. Early drive firmwares were unencrypted and left debug features available. Modern drives use encrypted firmware and have the debug modes disabled. If you’ve got one of those early firmwares, you’re good to go. If not, you’ll need to patch your drive.

However, “encrypted” is fairly weak compared to, say, a game console when the key is the same for all drives and there’s no hardware-level anti-rollback…

As a result, it was fairly easily defeated on modern drives. Find key, decrypt firmware, make changes, re-encrypt, update. Thanks MediaTek for keeping the same flawed legally-approved chip architecture for almost a decade.

I love MediaTek for these things. Same for "old" Android phones.

Almost certainly a DMCA violation and therefore illegal to distribute.

I'm not sure why. If the point is to make the firmware read every bit of the drive, that doesn't seem like it would break any copyright law. The encrypted data is rather useless without breaking DRM, but the DRM breaking doesn't happen in hardware.

If the firmware is based on existing, proprietary drive firmware, then distributing it may run afoul of copyright law, but if all that's distributed is a patch file then I don't see the problem there either.

There are quite a few countries with exceptions in copyright law for compatibility reasons, like modifying programs to make them work on newer hardware without the original authors' consent. The reason VLC (and many other open source projects) can play DVDs is that France, where VLC is based, has laws that make it legal to distribute a DVD playback library. I don't think any Linux distros have faced legal trouble over distributing VLC, even if they are American in nature.

I'm sure the copyright lobby will have a different opinion, but I don't think it's quite as black and white without knowing where the author resides and/it what nationality they have.

The DMCA is American law, so the parent comment can only be referring to America. Obviously doesn't apply outside there.

> I don't think any Linux distros have faced legal trouble over distributing VLC, even if they are American in nature.

That's because they generally don't distribute libdvdcss, which is the illegal part.

> Many Linux distributions do not contain libdvdcss (for example, Debian, Ubuntu, Fedora and openSUSE) due to fears of running afoul of DMCA-style laws, but they often provide the tools to let the user install it themselves. For example, it used to be available in Ubuntu through Medibuntu, which is no longer available.

https://en.wikipedia.org/wiki/Libdvdcss#Distribution

> The DMCA is American law (...) Obviously doesn't apply outside there.

...and when you host your code on Github or Gitlab, they will have to comply with DMCA letters. After one round of exchanging counternotices the content will have to stay down unless the alleged infringer is willing to fight the matter in a US court.

Because the purpose is to read disks protected by technological protection measures. Circumventing technological protection measures is illegal, period. That's one of the things many people don't like about the DMCA. I'd recommend to start archiving this website now.

I mean, the post is from 2019, and MakeMKV has been around much longer than that. I know this isn't always the case, but I feel like if they were going to take down MakeMKV's site, they probably would have done it by now.

They thought that about Yuzu, too.

MakeMKV has been around considerably longer than Yuzu ever was. I think I first downloaded it in 2013-2014.

Not to say that the MPAA isn’t ever going to go after it, but I am sure they’re aware of it by now and have, if nothing else, been biding their time.

Maybe to the letter of the law, but I think there’s a reason why no one seems to go after MakeMKV.

If you’re using MakeMKV, then almost by definition you have a legitimate copy of the media you’re ripping, and as such not a direct target of any kind of piracy prevention. Obviously you could then post your rip on The Pirate Bay or something, but I don’t think that MakeMKV is generally blamed for that.

I have a ton of Blu-Ray movies purchased legitimately, and I use MakeMKV to rip them and play them with Jellyfin. I don’t distribute them, I only play them in my house.

Am I technically breaking the law? Probably, DRM law is weird and confusing in the US, but I doubt that the MPAA has a huge problem with what I am doing, since I am paying them for legitimate copies of my movies.

Too bad I already flashed it long time ago into my LG.