is there an AI tool for automatically fixing the timing of the lines

[cns00]

I have subtitle files for movies and the timing is bad and lines show before someone starts speaking and they stay after a person stops speaking. I need the lines to show exactly when someone starts speaking and go away exactly when a person stops speaking. Currently I am manually editing the timing of the lines and it's tough work.

is there an AI tool that can automatically fix the timing? I found AutoSubSync and I tested it. The lines are still showing for some time after the person stops speaking. I need something which is more accurate.

[videoAI]

try this first
https://github.com/kaegi/alass

[cns00]

try this first
https://github.com/kaegi/alass

AutoSubSync has ALASS and I tried it. It ruined the subtitle file and put negative times so a bunch of lines started at 0:00:00.00. What happened?

[Simon_Haddad]

try this first
https://github.com/kaegi/alass

AutoSubSync has ALASS and I tried it. It ruined the subtitle file and put negative times so a bunch of lines started at 0:00:00.00. What happened?

ALASS isn't great, but frankly I haven't really found any other program that even attempts an automatic line-by-line synchronization.

Get to know the ALASS.bat command-line. Mess with the split-penalty.

Or maybe mux the video file together with the subtitle file using MKVToolnix.
Then, also using MKVToolnix, break up the newly-multiplexed *.mkv video into smaller pieces, say 10-20 minutes each.
Pull the shorter subs out with gMKVextractGUI.
Use ALASS on them.
Append them back together again into a new file after you've tested and are satisfied with them.

[M.Whale]

The tools you have been trying are the right class, but they are not failing for the reason
you think, and what you are describing is not the job ALASS does.

Three different problems all get called "bad timing":

1. Constant offset - every cue is off by the same amount (say everything is 1.5 s early). One shift fixes
the whole file.
2. Rate mismatch - the first cue is fine, the last one is badly off, and the error grows steadily. That is
a multiply, not a shift (24 vs 25 fps is about 2.4 s per minute).
3. Per-cue mismatch - starts and ends are individually sloppy against the speech, with no single rule
relating them. That is the one you have, and it is the only one that needs speech-based alignment.

You can tell them apart in about two minutes: take a cue roughly one minute in and a cue near the end, and
compare both against the audio. Same error at both = case 1. Error at the end about ten times the error at
the start = case 2. Errors of a few hundred ms scattered in both directions = case 3.

ALASS is not speech recognition. It aligns by comparing the subtitle file against the audio (or against
another subtitle file) and then shifts or splits whole blocks to minimise a penalty. It is good at cases 1
and 2 and structurally cannot do case 3.

The pile-up at 00:00:00 is a clamp, not corruption: ALASS decided a block had to move earlier and the first
cues had nowhere to go. Check the first cue of your input - if it starts at 00:00:02 while the audio's first
line is at 00:00:00, you are asking for a negative shift. Shift the file forward by hand first so every cue
has headroom, keep a backup (ALASS rewrites in place), then run it. VideoAI's 10-20 minute chunk trick is the
other standard workaround: it keeps each alignment local so one bad block cannot drag the rest.

One warning about the goal itself. "Show exactly when speech starts, hide exactly when it stops" is not what
delivery specs ask for, and that is why no tool does it: a cue has to stay up long enough to be read (for
Netflix, a minimum duration and a cap on characters per second), and it must not overlap the next cue. So an
end time slightly past the last syllable is usually correct rather than sloppy. Aim for speech-anchored
starts and reading-time-satisfied ends, then run the file through minimum-duration / CPS / gap checks. If you
fix boundaries by hand, work from the waveform rather than listening - your ear is the least repeatable tool
you have for this.

[Nikse]

Subtitle Edit v5.3.0-beta17 has a tool for exactly this: https://github.com/SubtitleEdit/subtitleedit/releases/

Open the video and subtitle, then go to Tools → Improve time codes (forced alignment)… and press Align. It listens for each line in the audio and moves its start and end to where the words are spoken. You can compare old and new times.

Tick Check with speech-to-text too. It first syncs files that are far out (offset, drift, cut scenes) by matching words rather than silence, so no pile-up at 00:00:00 like with ALASS (I hope).

The subtitle must be in the spoken language, and the first run downloads the models. A faster PC/GPu is probably best...

Feedback welcome, it's a beta.

[fred_abila]

For fixing line timing rather than translating, the practical free path today is Subtitle Edit with its Whisper / CPP / forced-alignment tools under the Audio menu, pointed at the same media file as the .srt. That often beats ALASS on messy dialogue because it re-fits each line to the speech instead of only shifting blocks. If Whisper over-splits or merges lines, run it once for timing, then clean punctuation in SE afterward. Paid options like CapCut auto captions or Descript also retime from speech, but they rewrite text and you have to export and re-import. Disclosure: I build Vidmoat, a hosted AI video editor, and the captions path is meant for this case. You upload the video, ask it to generate or retime captions from the audio, then fix wording in chat before export. It will not beat a careful Subtitle Edit pass on a dense feature-film subtitle file, but for talking-head and course videos it saves the manual drag-every-line step. Subtitle Edit forced alignment remains the best free starting point if you already live in .srt files.

[M.Whale]

Subtitle Edit v5.3.0-beta17 has a tool for exactly this: https://github.com/SubtitleEdit/subtitleedit/releases/

Open the video and subtitle, then go to Tools → Improve time codes (forced alignment)… and press Align. It listens for each line in the audio and moves its start and end to where the words are spoken. You can compare old and new times.

Tick Check with speech-to-text too. It first syncs files that are far out (offset, drift, cut scenes) by matching words rather than silence, so no pile-up at 00:00:00 like with ALASS (I hope).

The subtitle must be in the spoken language, and the first run downloads the models. A faster PC/GPu is probably best...

Feedback welcome, it's a beta.

Nikse - thanks, and good timing on the beta. That is the case 3 tool this thread started out missing.

Two things I would want to check before trusting it on delivery files.

Where a line is delivered quickly, aligning its start and end to the speech is not automatically a legal
pair of boundaries: the cue can end up under the minimum duration or over the allowed reading speed, and two
adjacent aligned lines can end up overlapping or with less than two frames between them. So alignment wants a
trim pass after it - minimum duration, max characters per second, no overlaps, minimum gap - and it would be
useful to know whether the tool does that itself or leaves it to the user.

The other one is lines with no speech to match: signs, on-screen text, forced narrative, songs. Those have
authored times that have nothing to do with the dialogue, so I am curious whether the pass leaves them alone
or re-fits them along with everything else.

On the pile-up: if the new times come from the detected speech rather than from shifting the old file, then
cues cannot land below zero by construction. That matches what you describe.

Happy to run a batch through the beta and report before/after numbers - duration distribution, characters per
second, overlap count, sub-two-frame gaps - if that would be useful feedback.