Can other-transcode directly accept a standard DVD VOB structure (VIDEO_TS Folder etc.)?

[muesic]

I did take a look at the documentation, but it wasn't clear to me if this was possible. I know a likely response will be to simply first convert the VOB to MKV using something like MakeMKV, but that has issues (that I can get into later if needed).

[skj-dev]

Your assumption is correct, the tool doesn't process VOB or BDMV structures. There is an expectation that your source material is a discrete video file. In practice that is typically generated via MakeMKV.

[muesic]

I've found MakeMKV to be too unreliable. Several of my ripped DVDs likely had a couple scratches etc. Those VOB file structures still play just fine in VLC (and there might be some visible glitch where the scratch was) but when converted to MKV using tools like MakeMKV (or MKVToolnix or AVIDemux) they often yield an MKV that has very noticeable audio/video sync issues. When that is subsequently input to a compression tool those AV sync issues carry forward. Using a tool like HandBrake to directly take the VOB structure and compress it to MKV means that wherever those scratches were there might be a small glitch in the output but audio/video sync is maintained. I infer from this that HandBrake isn't first converting to MKV and then compressing, it's doing both simultaneously. That's why I want to operate directly on the VOB files - to avoid the audio sync issue that comes from making this a two step process. I'm in the process of experimenting around, but I was successfully able to take the command line generated using other-transcode's --dry-run option on an MKV file generated using MakeMKV and editing the command line to reference the input file as one of the VOB files and it did work. There are some issues I'm ironing out and I report back shortly.

[skj-dev]

To be fair, media damage is always going to be a problem regardless of the software used, and shouldn't reflect on the reliability of the software. A player like VLC is likely to address the issue by dropping data. An extractor like MakeMKV is going to try its best to maintain the fidelity of the original bits, and consider dropping data an error condition. Sometimes the mitigation techniques aren't able to work around the error conditions as well as one might wish, which can lead to sync issues, etc.

ffmpeg does have more facilities than those used by other-transcode, as Don's tool isn't supposed to be a general purpose front end to ffmpeg. We like Don, and am glad he's not trying to do such a thing, as it would drive anyone to a premature state of insanity. It's absolutely fair to use --dry-run to produce an ffmpeg command that acts as a starting point for your own ffmpeg commands.

Also, if HandBrake is doing what you need, there's no reason not to use it. 😸

[muesic]

I would use HandBrake in a heartbeat - but I get the best results using other-transcode and I'm darned if I can coax HandBrake into doing what other-transcode does either via the GUI or the HandBrakeCLI tool. I know transcode-video uses HandBrakeCLI, but Don has said that's deprecated and I should stick with other-transcode - hence the hard tethering to ffmpeg. I have a 20TB library of VOB structure movies etc. to compress and I want to do it all via scripts and I want to make sure I do it right this time (unlike the last time where I wasted months of my time). The curious thing is that Don started out wanting to compress his DVD/Blu-ray collection, so he (like me) must have started out with VOBs too (for the DVDs anyway).

[skj-dev]

I never assume that anyone starts with VOBs, or BDMVs, but maybe that's just me.

Perhaps working up your own script that basically uses other-transcode --dry-run to produce an ffmpeg command that you then programmatically adjust based on your needs would be the best approach. A lot of folks do exactly that, and basically construct transcode pipelines that have various logics baked in that can adjust for a variety of conditions ranging from specific title needs to formatting, etc.