How anchored captions fix the biggest annoyance in shorts editing

If you’ve cut a vertical short in almost any editor, you’ve hit this: you nudge a clip earlier on the timeline, and the captions don’t move with it. Now you’re re-syncing text to audio by hand, clip by clip, every time you reorder something. It’s the single most annoying part of editing shorts, and it comes from a modeling decision most editors get wrong.

Captions as a track vs. captions as a property

The standard approach treats captions as their own timeline track, parallel to video and audio. It looks right in the UI — tracks stacked on top of each other — but it means the caption’s position in time is independent of the clip’s position in time. Move the clip, and nothing tells the captions to move too. They’re only related by coincidence, until you break that coincidence.

We modeled it differently: captions are a property of the video clip, not a separate track. A clip owns its captions the same way it owns its trim points or its volume. Move the clip anywhere on the timeline — earlier, later, onto a different track — and its captions come with it, because they were never a separate object to begin with. There’s no re-sync step because there’s nothing to fall out of sync.

This isn’t a UI trick layered on top; it’s in the project schema itself. The editor can’t represent a clip without its captions attached, so there’s no code path where they drift apart.

Multi-clip timelines

Because clips carry their own captions, you can drop more than one source video onto the same timeline and cut between them without the caption track turning into a mess of overlapping entries you have to untangle. Building a short from three different VOD moments works the same way as building it from one — arrange the clips, each one keeps its own captions and trim state.

Freeze frame, without leaving the timeline

Freeze frame is a moment where the video holds on a single frame while the timeline keeps running underneath it — a reaction beat, a punchline hold. Because the render path is a single deterministic function of time (renderFrame(t)), freezing a frame is just holding t constant for a stretch of the output timeline instead of advancing it. It’s the same render call preview uses, just fed a different time value — not a special-cased effect bolted on separately.

Why this holds up under editing pressure

The reason this matters isn’t the freeze-frame trick by itself — it’s that every editing operation goes through that same one render path, whether you’re previewing live or exporting the final file. There’s no separate “preview renderer” and “export renderer” that can quietly disagree with each other, which is the most common source of “it looked right in the editor but the export came out wrong” bugs in video tools. Anchored captions are the clearest example of what that buys you: the model is simple enough that there’s no seam for the bug to hide in.

What this means for you

Cut a clip from a VOD, drop it on the timeline, trim it, move it next to another clip, freeze a frame on the punchline — the captions never need touching. That’s the whole point: less time babysitting sync, more time deciding what actually makes the cut.