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.
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).
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
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 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.
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.
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”.
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.
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?
was! Even a plain - non NAS - HDD has increased 40%+ since 6 months ago
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.