Fix negative subtitle durations in adjust_for_pause (#253)

[happyarts]

Summary

Fixes #253

The adjust_for_pause() function adjusts segment boundaries when they fall within a VAD-detected pause. It shifts segment.start forward (to the end of the pause) and segment.end backward (to the start of the pause) independently. For short segments that lie entirely inside a pause, this can push start past end, resulting in negative durations in WebVTT subtitle output.

Root cause

# start gets pushed FORWARD
if segment.start > pause_start and segment.start < pause_end:
    segment.start = pause_end - pause_extend

# end gets pushed BACKWARD (independently!)
if segment.end > pause_start and segment.end < pause_end:
    segment.end = pause_start + pause_extend

When a short segment (e.g. 5.0s–5.3s) falls entirely within a pause (e.g. 4.8s–5.8s), start moves to ~5.6s while end moves to ~5.0s → start > end → negative duration.

Fix

Save the original segment boundaries before adjustment. After processing all pause chunks, check if start >= end. If so, revert to the original values.

This is a minimal, safe fix — it only changes behavior for the specific edge case that causes the bug.

Note

I was not able to test this fix with a long audio file that reproduces the issue. The fix is based on code analysis only. I would appreciate it if someone with a 7+ hour audio file could verify.

Test plan

• Transcribe a long audio file (7+ hours) to verify no negative durations appear in VTT output
• Transcribe a short audio file to verify pause-adjusted timestamps still work correctly
• Validate VTT output in a subtitle editor (e.g. Subtitle Edit) to confirm no warnings

[kaixxx]

Your new friend Claude produces nice problem reports. I use mostly Codex. The results are also quite good, but not as comprehensive as this. But I have never generated a full PR with it, so I might have to try that.
Anyway, the analysis and the suggested solution are looking good. We will see if this is really the only reason for the negative timestamps in the output. But it might very well be.
Thanks!