www.makemkv.com

Hi there,

I'm new to this Forum and to this Software, so I apologize if this has already been discussed or is even implemented, I tried to search for it but got no results.

My Question is if there is already some Way to have MakeMKV zip up a created Blu-ray Backup into an .zip or .7z, for Example and if not, if that may be a useful Feature Suggestion.

I believe this feature would not only be useful for at least somewhat lessening the impact on your available Storage but also aid in (automated) handling of larger Libraries (sources) as it makes transferring non .iso Backups easier and faster being one big file instead of a lot of smaller & medium ones.

I'm not claiming that this would be a game changer, just a nice Option to have:)

I'm happy to be corrected if I misunderstood something!

I'm on Windows 11, using Version 1.17.8 of MakeMKV

Story:
I started my Journey a few Days ago when I decided that I would like to have a local Media Library via Plex or Jellyfin and started to rip all DVDs and Blu-rays I had. 1.8TB later, the amount of free space on my built-in HDD is at a never before seen low point and I have to temporarily vacate the created Backups to an external HDD to be able to add the rest of my Media Collection, at least until I have set up an automated process to treat all those Backups to get the needed Files for what I plan. I have not decided yet if I will keep the raw Backups or just the processed Files, but if I were to keep the raws I would definitely zip them

Question is, why? To save space, why are you creating an image of the disk via backup, rather than simply ripping the MKV files? And MKV files can be compressed using existing tools (like handbrake) to make them much smaller.

My main use case for this would be the automated processing of the backup result on a device different from the one where the Disk Reader is attached, the Backup of a Blu-ray Disc contains potentially hundreds of Files, while not a real problem as is, having them in one single file would make the Transfer process easier, saver and faster.

Again, not claiming that this is a major problem or that it would be a game changer, it's just something that would be nice to have as an option somewhere in the settings.

I'm no Dev, so this may be complete BS, but I think a simple Version of this wouldn't be very intense to implement, which is the only reason I'm even asking, it's certainly not worth a big invest as it's for a very niche use case.

As for space-saving, yes, there are many better ways to achieve this so it is not something I would put forth as an argument for the implementation, rather it's a small additional benefit if this would be implemented for other reasons.

To illustrate my thinking, I currently scan my entire collection as Backups, so I have the highest possible "quality" available for whatever comes next, and so I never have to touch the physical Media ever again (and to have a true Backup, in Case the Disks get damaged or something). When I'm done setting up whatever I will do for my local Media Library, I will have the actual stream ready files in the state my highest Quality Device can display on my NAS/Media Server (which while generally being already relatively cheap storage still has some requirements to Redundancy and so on, making it not Ideal for massive "place and forget" secondary Content Backup), but I will keep the original Backups on the cheapest warm Storage I have so in the Future, when I have better Devices I will be able to go through the raw backups with an updated processing pipeline.
While a bit convoluted, yes, the intention is to have a reasonable high change of survival of the raw data. If the Discs die I have the raw backups, if the warm Storage dies I can rescan the Discs.

Zip it yourself.

I've been doing this will all the backups I rip myself using "mount-zip" to mount under FUSE. Although you can use any filesystem (FS) type on loopback, I personally find zip easier to work with in other things (Node, Go, Python, etc.). However, most recently I've simply left them in a directory as wrapping them up is kind of pointless.

I use ZFS so FS integrity is pretty high, but leaving them in a directory also makes it a little easier if you use par2 to create integrity files for your rips as repairing smaller files is typically faster due to smaller calculations. Par2 is Reed Solomon stored independently on a filesystem, so it's basically just as good as any other RS implementation (like ZFS's).

https://github.com/google/mount-zip