We are making a fifteen-episode animated series, in Arabic and English, and no person cuts it. There is no editor, no timeline anyone scrubs, and no approval step between the last shot rendering and a finished episode existing. The series is 3917 shots, averaging 261 an episode, and because a speaking shot is rendered once per language that comes to 6,181 separate pieces of video to place, trim and mix. That is not a thing you want to do by hand, and it is also not a thing you want to automate badly, because a bad automatic edit fails quietly and identically six thousand times.
This is how the edit works, what it gets right, and the two failures that taught it the most — both of which were invisible until something measured them.
The dead air problem
Start with what the edit is actually for. Each shot is planned with a length before anything is rendered, and the rule that sets it is words × 0.55 + 2.5 seconds. The voice model speaks a six-word line in about 3.2 seconds. So the formula is roughly right about the line and then adds two and a half seconds of nothing on the end of every speaking shot.
Rendered, that looks like a character finishing their sentence and then standing there. Measured across two finished episodes, here is where the time goes:
Episode one plans 8.1 minutes of speaking shots and keeps 4.4. Episode two plans 19.7 and keeps 12.1. That is 46% and 39% of all speaking time removed — and in episode one the speech itself is only 38% of what was planned for it.
Cutting a shot without re-rendering it
The obvious fix is to render shorter shots. The cheap fix is to cut the shot you already have, and it turns out to be the correct one.
A voice-driven video model locks the mouth to the audio at the offset it was given. If you keep the window that holds the line, the lip sync survives frame for frame — you are not re-timing anything, you are ending the shot earlier. So the trim needs no GPU at all, and it can be re-run with different settings as many times as you like.
Two details do most of the work. The window is taken from the picked voice take’s measured start and duration, not from the plan — the plan is the thing that was wrong in the first place. And the trim is applied to the segment, so picture and sound are shortened together and cannot drift apart no matter what the trim decides.
There are two floors. A shot never goes below 1.5 seconds, because under that it reads as a glitch rather than a cut. And a shot with no line is never touched — a wordless beat is the story breathing, and shortening it is a directing decision, not a cleanup. The automation is deliberately not allowed to make that one.
The bug that made us rebuild the sound
The first version did the obvious thing: encode each shot to an MP4 with its own audio, then join them. It worked, in the sense that it produced a file. What it also did was drift.
Every AAC segment carries a small encoder delay. Join them and the delay accumulates — about thirty milliseconds per join. On a twenty-four shot pilot that was audible: the sound was a tenth of a second late by shot three and seven tenths of a second late by shot twenty-three. Nothing errored. Nothing logged a warning. It just slowly stopped being in sync, and the first report of it was a person watching and saying the audio placement was not proper.
An episode is around 412 segments, not twenty-four. The same code would have drifted the end of an episode by tens of seconds.
So the video segments are now encoded silent — that is the whole point of them — and the dialogue is assembled separately as one continuous PCM timeline, mastered once to −16 LUFS with a constant-gain two-pass normalisation so it does not pump between lines, then muxed on at the end. One timeline cannot accumulate anything.
The other half of the fix is smaller and matters as much: each segment’s audio is cut to the segment’s measured frame count, not to its planned length. A clip that rendered one frame short used to push everything after it out of step. Now it cannot, because nothing downstream trusts the plan.
What has to be true before you can remove the human
Automating the edit is the easy half. The hard half is that nobody is watching, so every defect a person would have caught by looking has to be caught by something that measures. Four checks stand between a rendered shot and a finished episode, and each one exists because something shipped without it.
- Black bars. Some renders come back letterboxed. Bars of ten to eighty rows reached seven finished episodes before anything measured them. Worse, the first version of the check sampled twelve frames spread through a clip, and a bar covering only the first thirty-one frames slipped through it. Every clip is now measured, including its first and last three frames specifically.
- Frozen picture. When a line runs longer than its clip, the cut holds the last frame to keep the words. That is working as designed and it is also how one shipped episode came to freeze for six seconds — thirty per cent of what the viewer sees. The check now reads every frame of the assembled cut and compares each held run against the hold the layout actually planned.
- Every frame of every clip, on a vision model. Clips are decoded at 24 fps and every frame is read — about 27,000 an episode. This check used to sample three frames per clip, which on one episode was 3.4% of it. A hand that deforms for six frames lives entirely inside the other 96.6%. Faults are reported as runs with a start and a length, never as a count: one odd frame in 27,000 is the model blinking, forty in a row is something a viewer sees.
- The finished cut, second by second. Picture, on-screen text, whether the shot matches what is being said, and whether the speaker is named.
The vision work runs on a 24 GB card that cannot render anything, so the hour it costs is free against the render farm. At twelve concurrent requests it reads about 6.3 frames a second — which is the card’s measured knee, not a guess. Sixteen, twenty-four and forty-eight concurrent requests are all no faster; they only make each call slower.
The thing automation found that people had not
The best argument for building it is not the time it saves. It is this.
Re-cutting the pilot meant rebuilding its soundtrack, and rebuilding it exposed that the soundtrack had only ever contained dialogue. The traditional chant the film is partly about measured −91 dB — digital silence — in every version ever cut, even though twelve takes of it had been sung and one had been chosen. So had a faint second chant, and a music bed. Nobody noticed, across many viewings, because the picture was right and the dialogue was right and the missing thing was a thing that was supposed to be quiet.
A person watching for an hour did not catch it. A script that compared the assembled track against every input caught it immediately.
What is still not automated, honestly
The real fix is upstream and is not done. Trimming afterwards recovers the running time but the GPU still rendered those frames. Shot lengths should be planned from the recorded line rather than from words × 0.55 + 2.5. Until that changes, roughly forty per cent of the speaking frames this farm renders are thrown away by the edit — which is an argument for fixing the boarding rule, not for keeping the trim.
How long a held frame may sit is a human call and has not been made. The check measures every hold and reports it. What the limit should be is a judgement about pacing, so the automation states the number and stops there.
Nothing publishes itself. The pipeline renders, cuts, checks and moves a finished episode into a folder. It has no path to anywhere public, which is deliberate: an upload is the one action that cannot be undone, and no amount of green checks is the same as a person deciding to release something.
“Fully automated” is a claim worth being precise about. Every mechanical decision is automated, and each one is made from a measurement rather than a default. The taste decisions — how long a silence should be, when a thing is ready to be seen — are still ours, and the system is built so that those are the only ones left.


