[feature request] custom mpv extraction arguments about mpvacious

[tatsumoto-ren]

Yes, it makes sense. We have custom commandline options available for the WebP anki add-on, so something similar could be added here as well.

[cyphar]

Ah, you can't pass an array in script-ops -- mp.read_config is limited to strings, booleans, and numbers...

[tatsumoto-ren]

Yes, but I guess you can pass a string and split it later.

[cyphar]

Yeah, that's what I'll probably do -- I was hoping to avoid splitting strings on spaces because then the next problem is how to deal with escaping of strings. I'll cook something up later this week (for the moment I've just hard-coded the filters I wanted to add to mpvacious).

[cyphar]

So I have a patch for this now, but I've run into a problem -- mpv applies the --start and --end flags after the filter has been applied, which means that if you have a filter like silenceremove where the timestamps of the audio will shift after the filter is applied, the audio clip is misaligned. Because mpv appears (unsurprisingly) to only apply the filter to the rough area of the clip, this ends up only causing minor misalignments but it's a bit of a shame (it's more noticeable if the subtitle line contains a long pause -- but it's exactly in that case where you'd want to use silenceremove).

To fix this we could add an (optional) custom post-processing stage where users could specify an mpv command (or any arbitrary command) to run before we add the file to Anki. This would remove the need to add anything to the exist mpv command-line but it would mean double-encoding the audio. What do you think @tatsumoto-ren?

[tatsumoto-ren]

If speech contains a long pause, it makes more sense to create two cards and then join them if necessary. We have an add-on for that, it's called mergenotes.

[cyphar]

I'm not sure I agree -- for instance the opening line of Dr. Stone is 「その日世界中の人間は全て―」 but there's a ~1-2 second pause after その日 (but it is still one subtitle line). To use mergenotes you'd need to manually split the line then re-merge them when silenceremove would solve the problem entirely.

[eshrh]

I think double encoding audio is absolutely fine, as long as the user knows what they're getting themselves into and is not enabled by default. This is annoying though, because it also slows down every other command line double encoding that doesn't affect timings; maybe an mpv patch is order...

[cyphar]

@tatsumoto-ren 39d9c59 added silenceremove to the default extraction settings but (unless mpv has changed their behaviour) this has the same issue as the one I mentioned above which might cause misaligned audio clips for a lot of users -- IMHO that option should be removed unless we want to add a two-pass method.

I still reckon it'd be useful to at least be able to specify loudnorm since videos can have wildly varying volumes and tie_volumes has its own issues.

[cyphar]

c5739bc implemented most of this -- though as mentioned above there is still a minor issue with silenceremove. But I'm happy with closing this, and thanks for writing the patch for me (I was a bit busy with other things to get around to it).