HandyMKV for MakeMKV and HandBrake Automation(github.com)
github.com
HandyMKV for MakeMKV and HandBrake Automation
https://github.com/dmars8047/handymkv
26 comments
If that's not too cheeky, would you consider sharing it?
It's incidentally a number three on my own backlog, so I'd rather spend this time learning more Python than addressing the exact problem you've already solved :)
TA.
It's incidentally a number three on my own backlog, so I'd rather spend this time learning more Python than addressing the exact problem you've already solved :)
TA.
How does this compare to ARM? https://github.com/automatic-ripping-machine/automatic-rippi...
Maintainer here! I got asked this awhile back on the Level1 forums so maybe I should add a blerb to the README about this.
Basically the difference is primarily in design philosophy and objectives. ARM strives to be the ultimate automation tool with lots of customizable options. Its so automated that basically you can put in a disc and it takes over from there.
HandyMKV does have some automation features but its primarily designed to provide a simple TUI to replace/streamline the desktop experience. It even offers some simple encoding options to get you setup quickly. There are also some concurrency time/saving things going on under the hood (parallelizing ripping and encoding). To answer your question more directly, HandyMKV doesn't really strive to be an autonomous tool and infinitely tweakable in the same way ARM does. It mostly strives to streamline and simplify the error prone and time consuming desktop experience (in TUI form).
Basically the difference is primarily in design philosophy and objectives. ARM strives to be the ultimate automation tool with lots of customizable options. Its so automated that basically you can put in a disc and it takes over from there.
HandyMKV does have some automation features but its primarily designed to provide a simple TUI to replace/streamline the desktop experience. It even offers some simple encoding options to get you setup quickly. There are also some concurrency time/saving things going on under the hood (parallelizing ripping and encoding). To answer your question more directly, HandyMKV doesn't really strive to be an autonomous tool and infinitely tweakable in the same way ARM does. It mostly strives to streamline and simplify the error prone and time consuming desktop experience (in TUI form).
It's in a similar vein, seems like something that would be useful to document in the project's README.
Oh this is neat! I've put off ripping and encoding because it is so much manual work.
HandBrake is the best if you want to ruin all of your DVD encodes.
e: downvote if you want but I'm right and you're wrong lmfao
For anyone in the peanut gallery who wants a good deinterlacer, try QTGMC. It's originally an Avisynth script, but I use a VapourSynth port: http://avisynth.nl/index.php/QTGMC
e: downvote if you want but I'm right and you're wrong lmfao
For anyone in the peanut gallery who wants a good deinterlacer, try QTGMC. It's originally an Avisynth script, but I use a VapourSynth port: http://avisynth.nl/index.php/QTGMC
Can you explain why it ruins the DVD encodes? I like this community to learn stuff
It all comes down to the fact that DVD is more of an analog format than a digital one. I feel like people get “CD ripping brain” which causes them to think that the most desirable thing is making the most-accurate copy of what's on the disc. For CD that's true because PCM is PCM, but for DVD the thing we really want is the program material, which is three layers deep on a DVD: inside an NTSC video signal, which is digitized following the Rec.601 standard, which is then shoved into an MPEG2 transport.
Four major things that can be done to DVD to make them look great on modern displays:
- Deinterlacing is the hardest to get right. Progressive-scan 24-frames-per-second DVDs exist but are mostly confined to movies where there will be a better BD release anyway. Interlaced DVDs where the program material is intended to be seen in 24FPS get “inverse telecine” (IVTC) instead of straight deinterlaced, but again I don't do a lot of those for the same reason. Almost any NTSC DVD that I care to encode is thus going to be 60000/1001 fields per second, which needs to be turned into 60000/1001 frames per second to avoid throwing away half of the available motion detail. If you do nothing at encode-time and produce an interlaced output, then the display or player software will end up doing it and will do a bad job. HandBrake's deinterlacing options just don't look good in my experience. I like QTGMC for this because it predicts the motion of the infill fields instead of just copying the previous field verbatim. It's very noticeable any time there's a lot of horizontal movement in the program material.
- Resolution and ratio. Most people hear “anamorphic” DVD and think of 16:9 crammed into a 4:3 image, but the truth is that all NTSC DVDs are anamorphic. They're 720x480 which if you calculate it is actually a 3:2 aspect ratio. Very clever because it ends up being about the same amount of scaling for 4:3 or for 16:9 material. They rely on PAR/DAR flags to tell the player or display how to scale it, but modern displays have terrible terrible scalers because it's purely a box-checking thing for them and not a feature they spend money or effort on. When I encode a DVD I stretch it myself at encode-time to 720x540 or 960x540. There's obviously some artifacting inherent in that vertical stretch, but it avoids throwing horizontal resolution detail away by scaling 4:3 programs down to 640x480 like most encoders do. Then the 540 pixel-doubles cleanly into 1080, 2160, etc.
- SD colorspace (Rec.601 again) is a similar issue where modern displays are just fucking terrible at it because there's no economic reason for them not to be. The chroma is already subsampled, so greens especially end up looking washed out and terrible. When I encode a DVD I convert them into HD colorspace which doesn't restore subsampled chroma but at least avoids letting the display make it worse.
- Cropping. The program-area resolution is actually 702 or 704x480 for anything transferred from tape (look up SONY D-1). If you have any "DVDrips" sitting around of an '80s or '90s TV show, does it have 8 pixels of black pillarbars on the left and right? If so then the person who encoded it didn't know what they were doing. It subtly throws off the aspect ratio for the entire program, especially noticeable in animation where they tended to use exact-circle tools. Look at the characters' eyes in The Simpsons for a great example. I crop those off before my one-time scaling so the program ratio comes out perfect.
This all applies similarly to PAL DVDs except I'm usually shrinking them down to 540px because the loss of some vertical resolution is still better than trying to get a modern display to scale 576px to panel-native res, and deinterlacing PAL is a straight 50-fields-to-50-frames without the wacky 1001 division notation that is a legacy of the backwards-compatible way that color was introduced to NTSC.
Four major things that can be done to DVD to make them look great on modern displays:
- Deinterlacing is the hardest to get right. Progressive-scan 24-frames-per-second DVDs exist but are mostly confined to movies where there will be a better BD release anyway. Interlaced DVDs where the program material is intended to be seen in 24FPS get “inverse telecine” (IVTC) instead of straight deinterlaced, but again I don't do a lot of those for the same reason. Almost any NTSC DVD that I care to encode is thus going to be 60000/1001 fields per second, which needs to be turned into 60000/1001 frames per second to avoid throwing away half of the available motion detail. If you do nothing at encode-time and produce an interlaced output, then the display or player software will end up doing it and will do a bad job. HandBrake's deinterlacing options just don't look good in my experience. I like QTGMC for this because it predicts the motion of the infill fields instead of just copying the previous field verbatim. It's very noticeable any time there's a lot of horizontal movement in the program material.
- Resolution and ratio. Most people hear “anamorphic” DVD and think of 16:9 crammed into a 4:3 image, but the truth is that all NTSC DVDs are anamorphic. They're 720x480 which if you calculate it is actually a 3:2 aspect ratio. Very clever because it ends up being about the same amount of scaling for 4:3 or for 16:9 material. They rely on PAR/DAR flags to tell the player or display how to scale it, but modern displays have terrible terrible scalers because it's purely a box-checking thing for them and not a feature they spend money or effort on. When I encode a DVD I stretch it myself at encode-time to 720x540 or 960x540. There's obviously some artifacting inherent in that vertical stretch, but it avoids throwing horizontal resolution detail away by scaling 4:3 programs down to 640x480 like most encoders do. Then the 540 pixel-doubles cleanly into 1080, 2160, etc.
- SD colorspace (Rec.601 again) is a similar issue where modern displays are just fucking terrible at it because there's no economic reason for them not to be. The chroma is already subsampled, so greens especially end up looking washed out and terrible. When I encode a DVD I convert them into HD colorspace which doesn't restore subsampled chroma but at least avoids letting the display make it worse.
- Cropping. The program-area resolution is actually 702 or 704x480 for anything transferred from tape (look up SONY D-1). If you have any "DVDrips" sitting around of an '80s or '90s TV show, does it have 8 pixels of black pillarbars on the left and right? If so then the person who encoded it didn't know what they were doing. It subtly throws off the aspect ratio for the entire program, especially noticeable in animation where they tended to use exact-circle tools. Look at the characters' eyes in The Simpsons for a great example. I crop those off before my one-time scaling so the program ratio comes out perfect.
This all applies similarly to PAL DVDs except I'm usually shrinking them down to 540px because the loss of some vertical resolution is still better than trying to get a modern display to scale 576px to panel-native res, and deinterlacing PAL is a straight 50-fields-to-50-frames without the wacky 1001 division notation that is a legacy of the backwards-compatible way that color was introduced to NTSC.
That's fascinating, thx!
Thank you! I don’t have many DVDs (and only PAL), but it’s good to hear that I would need to be careful when ripping them
As with any lossy encoding process, I also always keep my originals so I can do it over in the future if need be :)
Not necessarily the physical disc but at least an ISO. I tend to rip DVD ISOs with the encryption intact in the name of making an untouched copy, since CSS is so thoroughly broken and since I have seen some very bad “backup” tooling that corrupts the VOBs when decrypting. I use DVDfab Passkey which is free for DVD usage; “Rip to Image” → “Keep Protection”.
Not necessarily the physical disc but at least an ISO. I tend to rip DVD ISOs with the encryption intact in the name of making an untouched copy, since CSS is so thoroughly broken and since I have seen some very bad “backup” tooling that corrupts the VOBs when decrypting. I use DVDfab Passkey which is free for DVD usage; “Rip to Image” → “Keep Protection”.
I just remembered that I have a non-infringing example encode I can share: PBS's “Code Rush — A Year in the Life of a Silicon Valley Supernova: Netscape” (2000)
Original PBS web page: https://web.archive.org/web/20000815055556/http://www.pbs.or...
A copy of this was released as an MPEG-4 Part 2 (not AAC/H.264!) MOV back in 2008 to commemorate the Firefox 3.0 release: https://waxy.org/2008/06/code_rush/
Then re-released and licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0: https://waxy.org/2009/07/code_rush_in_the_creative_commons/
Original PBS web page: https://web.archive.org/web/20000815055556/http://www.pbs.or...
A copy of this was released as an MPEG-4 Part 2 (not AAC/H.264!) MOV back in 2008 to commemorate the Firefox 3.0 release: https://waxy.org/2008/06/code_rush/
Then re-released and licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0: https://waxy.org/2009/07/code_rush_in_the_creative_commons/
mega dot nz/file/QhtHzBZD#Z8eUnBgmk3lsjRgKQsiSaGD_gAnRgNY6FCk2rzrSisMThis seems like a bit of a microoptimization if you're just interested in getting a streaming-service-quality level of DVD rip (which is fine by me).
I have no problem with someone wanting the highest quality possible, but for me, I mostly stream videos to a TV or to an iPhone, and unless it's a 4K UHD video (which I still compress to H.265 currently), I'm not too worried about pixel peeping at the quality.
I still watch VHS dubs too, and those have all kinds of crazy artifacts/color issues :)
I have no problem with someone wanting the highest quality possible, but for me, I mostly stream videos to a TV or to an iPhone, and unless it's a 4K UHD video (which I still compress to H.265 currently), I'm not too worried about pixel peeping at the quality.
I still watch VHS dubs too, and those have all kinds of crazy artifacts/color issues :)
There's no reason this can't by automated! I have a StaxRip workflow that takes care of everything I mentioned below except for the cropping which tends to be more fiddly — some times larger on the left or the right, or some times including the top and bottom too for e.g. Academy-ratio material that's hard-matted to the DVD res.
> I have a StaxRip workflow
I hope if you have time that you could document that workflow for us, as detailed as possible. I'm not trying to make work for you, so no worries.
I hope if you have time that you could document that workflow for us, as detailed as possible. I'm not trying to make work for you, so no worries.
I'm on vacation right now (shouldn't be on HN or my phone at all but what're ya gonna do) but can upload it somewhere when I get home next week and can access that machine.
IMO encoding is just not that worth it these days. Storage is relatively cheap. An 8TB HD can hold 200+ bluray discs as is (assuming we are talking 30-40TB each). Lets say encoding lets us store 400-600 movies in the same amount of storage (going to argue that this is stretch at quality).
Is the $100-$200 savings worth the extra time spent (also computing/gpu electrical costs.
There's a reasonable argument that the cost in electricity would be measurable, perhaps small, but still measurable, if it's 1c per movie, not such a big deal, if its 50c a movie, one didn't actually save any money in practice. if one wants to software encode to get the best results, cost is going to be more than if one is ok with gpu encoding and just ok results from fixed encoders. (I would hazzard software encode at reasonable quality is going to be in the 25-50c cost if paying 25c a kwh)
If one lives in an area where electricity is cheap but storage is more expensive, the calculation is different.
Now, I'd note that there is one thing that storage being cheap can't directly solve. The ability to keep them online at a time (i.e. many computers are limited to the number of connected devices). In that world, one can argue that reducing that complexity also has value.
Is the $100-$200 savings worth the extra time spent (also computing/gpu electrical costs.
There's a reasonable argument that the cost in electricity would be measurable, perhaps small, but still measurable, if it's 1c per movie, not such a big deal, if its 50c a movie, one didn't actually save any money in practice. if one wants to software encode to get the best results, cost is going to be more than if one is ok with gpu encoding and just ok results from fixed encoders. (I would hazzard software encode at reasonable quality is going to be in the 25-50c cost if paying 25c a kwh)
If one lives in an area where electricity is cheap but storage is more expensive, the calculation is different.
Now, I'd note that there is one thing that storage being cheap can't directly solve. The ability to keep them online at a time (i.e. many computers are limited to the number of connected devices). In that world, one can argue that reducing that complexity also has value.
> Storage is relatively cheap
was! Even a plain - non NAS - HDD has increased 40%+ since 6 months ago
was! Even a plain - non NAS - HDD has increased 40%+ since 6 months ago
IMO, that just changes the calculation a bit. As I said, it depends on the quality one wants to store it at relative to size to determine how long it will take to encode / power consumed to encode.
Was.
Plus what's the point in keeping ISO on the disk if I can have a convenient mkv/whatever with everything what's on it, _and_ everything recognises it, and it takes 1/20 - 1/4 space anyway?
Plus what's the point in keeping ISO on the disk if I can have a convenient mkv/whatever with everything what's on it, _and_ everything recognises it, and it takes 1/20 - 1/4 space anyway?
1. easy enough to store it remuxed as an mkv (this tool first converts it to a remuxed mkv via makemkv) to get that convenience.
2. "easy enough" (this is a bit hyperbole, but i've done it) to take an iso and expose the playlists one wants as individual .m2ts files, and then everything recognizes it the same as mkv
did this using a fuse fs. drop all isos in a dir with a metadata file to list the playlists one wants exposed with how one wants them named, and the fuse fs turns each iso into a virtual directory populated by files named <name>.m2ts that corresponds to the playlist you wanted for it (work for seamless branching as well).
3. if saving space is so important to you, yes, none of this will apply, I still think the energy costs need to be factored in, to understand how much money one is saving / spending to accomplish that space savings. If one is going to be storing a digital iso backup of the discs they purchase (or borrow), what I listed in #2 is the best overall.
2. "easy enough" (this is a bit hyperbole, but i've done it) to take an iso and expose the playlists one wants as individual .m2ts files, and then everything recognizes it the same as mkv
did this using a fuse fs. drop all isos in a dir with a metadata file to list the playlists one wants exposed with how one wants them named, and the fuse fs turns each iso into a virtual directory populated by files named <name>.m2ts that corresponds to the playlist you wanted for it (work for seamless branching as well).
3. if saving space is so important to you, yes, none of this will apply, I still think the energy costs need to be factored in, to understand how much money one is saving / spending to accomplish that space savings. If one is going to be storing a digital iso backup of the discs they purchase (or borrow), what I listed in #2 is the best overall.
Feel like the encoding estimate is off by an order of magnitude. A few GB is decent enough quality, you're looking at 2-4 thousand.
I disagree. But to each their own, also depends how one watches it. a truehd atmos audio stream for a movie can be 3-4GB by itself. Of course, for many perhaps a TrueHD atmos audio stream is overkill, but for many its not.
To each their own indeed, I definitely don't think a statement like
> encoding is just not that worth it these days
applies to people watching backed up media. The vast majority are fine with encodes.
> encoding is just not that worth it these days
applies to people watching backed up media. The vast majority are fine with encodes.
If one is going to store the originals anyways (i.e. the ISO images one backs up from disc), then I'd still stand by my statement, you're not saving anything by encoding it then, beyond perhaps limitations in how much storage one can keep online at a time (and in that context then, my initial statement of storage being cheap further applies, as one is saving the same content twice).
If one is just download encodes off of usenet so doesn't have the originals, and one is content with the limitations of encodes, great. But here we are talking about tools for people who are encoding their own media (and sadly, from personal experience, I consider backed up ISOs to have a longer shelf life than many of optical discs, I have media I backed up 20 years ago now that still works, while the optical discs have degraded. Hard Disks die as well, but there are effective means of mitigating that).
If one is just download encodes off of usenet so doesn't have the originals, and one is content with the limitations of encodes, great. But here we are talking about tools for people who are encoding their own media (and sadly, from personal experience, I consider backed up ISOs to have a longer shelf life than many of optical discs, I have media I backed up 20 years ago now that still works, while the optical discs have degraded. Hard Disks die as well, but there are effective means of mitigating that).
I had this same problem and I got claude to whip up my own version of this tool built out with makemkv, ffmpeg, imdb api lookups, LLM-selection of the "most likely to be the primary track", and plenty of other features. Really fun time to be building small bespoke tools for yourself.