Subtitle Sentence Boundary Issues

[u6771]

Thank you for this great tool — it works quite well overall!

However, I've noticed that the generated .srt subtitles (using sync) often break in the middle of a sentence, which hurts readability (especially when it's used to generate Anki cards). This happens in two types of cases:

Case 1: Sentence spans across multiple subtitle entries
Here, the sentence does not end within the subtitle block, and no terminal punctuation appears in the middle:

14
00:01:09,236 --> 00:01:13,256
しかし病弱とは言っても、そこに貧弱というイメージ

15
00:01:13,256 --> 00:01:14,416
は皆無だ。

This is relatively easy to fix with a post-processing script that merges subtitle entries until a terminal punctuation mark (like "。" or "？") is found.

Case 2: Sentence ends in the middle of a subtitle
Here, terminal punctuation does appear, but the subtitle block continues into the next sentence:

10
00:00:50,076 --> 00:00:55,576
が活発に動いているという絵をいまだかつて見たことが無い。保健室

11
00:00:55,576 --> 00:01:01,476
の常連で、かかりつけの病院に行くからという理由で、遅刻や早退、あるい

This is harder to resolve automatically, because from the .srt file alone, we can't tell when the sentence ended.

I see two possible directions for improving this behavior:

1. Analyze the audio to find silent gaps and ensure that subtitle breaks fall at or near these points — especially if they align with sentence endings.
2. Ensure that each subtitle ends at a terminal punctuation (e.g., "。", "？"). This could be used to force cuts, though aligning them with audio timestamps would still be important to avoid desynchronization.

Hopefully you would consider implementing these features in a future version.
Thanks again for your hard work!

[kanjieater]

For case 1, there is already a postprocessing script to fix those, but it's certainly not perfect. It could be extended by anyone but I would request a unit test documenting whatever post processing cases we are focing

For case 2, I think this is a side effect of the algorithm that was contributed post stable-ts processing. We are already using vad before it so it should be possible to make the subs more accurate.

While a fix for 1 is feasible with enough sample cases. Fixing 2 would probably fix 1, but require a rewrite of the most complex part (and unmaintainable) part of the code (probably all the more reason it should be rewritten).

You can work around these two issues entirely by using --respect-grouping, which uses the v1 matching algorithm. It only uses full sentences from your source. I don't recommend it though because the downside to it, is if it isn't confident where the split happened between a line it will combine lines, making potentially 2 full sentences as one sub. Given how long a sentence can be in something like Ningen Shikaku, this could be a single sub that is 2 full pages, instead of at natural reader breath points like the current v2 algorithm does.

Long term I'd like to fix and rewrite the matching algo, but it isn't a priority and I welcome others to contribute alternative algos in the meantime. I'll keep this issue open until we have something better.

[gelbziesel]

I have a related question to the original topic as I am trying to achieve the same thing. --respect-grouping works well for me, but it always makes one line out of quotation marks, eg several sentences inside 「」become always one timestamp. Is there any way to mitigate this?