Ditto (mentioned now and again here before), though transcoding into media files is also crucial for me (I have a projector/rasbpi-kodi setup that is only wifi-connected, so a lot of artificial-noise-filled blurays *need* transcoding and often vapoursynthing before I can squeeze them into the available bandwidth: for simplicity I simply transcode everything). I'm not sure I can call what I wrote a scripting language so much as a transcoding script which takes a bunch of options and catalogue files that let you vary options on a track-by-track basis without having to repeat yourself too much. The script *can* take a directory-full of MKV files named as makemkv names them and work from those, but can also call makemkvcon to extract individual tracks or sets of tracks -- it would be nice to be able to say "give me tracks 2, 5, and 9" and get them out named with _02, _05 and _09 in the names without pyaing the substantial makemkvcon initialization cost more than once. (The "default mode" of my transcoding script just uses direct handbrake CLI invocations, but it *can* use makemkv, and for some workflows, e.g. when throwing things through vapoursynth, this is mandatory because I need the video stream before it is retranscoded by handbrake.)drxenos wrote: ↑Sat Nov 28, 2020 5:19 pmI've written my own scripting language, specifically tailored to transcoding discs into mkv files. My automation goals seem different than most. Most people seem interested in quickly and easily extracting or transcoding Blu-rays or DVDs into media files. I'm more interested in repeatability. I realized long ago that there is a lot of research that goes into processing discs (determining title numbers, tracks, forced subtitles, etc.). I wanted to preserve this knowledge, so reprocessing discs in the future (e.g., errors, newer formats, change-of-mind, etc.) would be easy.
I agree with all of these (and though this doesn't cover my biggest single annoyance, that is unfixable: handbrake and makemkv simply use different track numbering schemes, and that's all there is to it). I might note that the makemkv drive number thing is a bit silly. I should not have to do this:My main wishes for MakeMKV are:
makemkvcon -r info | grep '^DRV' | sed 's,^DRV:,,; s,",,g' | awk -F, '{ if ($7 != "") { print $7 " " $1;} }'
to map a device file to a drive number! (Among other things this hangs if a drive is in exclusive use by something else, and takes forever with massive numbers of slow seeks if another makemkvcon instance is extracting from any drive, even if it's not the drive I was planning to extract from). Just take device file names on the command line like everyone else. Rolling one's own device naming scheme was annoyingly alien with cdrecord and is just the same here.
But really what I'd *expect* from experience with Unix tools is that anything you can do from the gui is also doable from the command-line tool, including things like picking specific things to extract within a given track, and that the gui uses the public options to the command-line tool to do what it does, so the options never rust and are automatically tested. makemkvcon is clearly capable of doing everything makemkv can since makemkv uses it, but it looks like it only knows how to do most of what it can do via the somewhat-opaque shared-memory protocol between makemkvcon and makemkv. If I was writing this I'd redo that protocol as a serialized command language rather than a bunch of shared memory stuff (maybe as simple as throwing some sort of instruction sheet at makemkvcon in JSON over stdin or something), then publicize that protocol so I didn't have to come up with a pile of horrible makemkvcon command-line options for obscure things like turning on track 4's second Spanish DTS track or whatever, and didn't have to worry about maintaining a pile of stuff that makemkv-the-GUI wasn't even going to use. But of course I'm not writing this so there's probably a very good reason why it's not done that way.
Oh, and a simple one: --help output which actually lists the valid command-line options. Half of them seem to be documented only in random forum posts, and since makemkvcon is closed-source I can't look and see what it can actually do...