Auto-Generating a Rough Cut From Transcript Timestamps

The rough cut is the least creative part of the edit and the one that eats the most hours. For anything driven by talking, a podcast, an interview doc, a YouTube explainer, the shape of the first assembly lives in the words. If you have the transcript with accurate timestamps, you can generate that assembly programmatically and open it in your NLE as a starting point, then do the actual editing on top of it.

This is text-based editing, the thing Descript popularized, but built from open parts so you control every step and it works with any camera footage. The pipeline is three stages: transcribe with word-level timing, select the segments you want as text, and emit an edit-decision file your NLE understands.

Stage one: a transcript your script can trust

The transcription engine of choice in 2026 is still a Whisper derivative. Plain OpenAI Whisper gives you sentence-level timestamps, which are too coarse for tight cutting. WhisperX is the one to reach for because it aligns output to the audio and hands back word-level start and end times, which is what makes clean cuts possible.

whisperx interview.mov \
  --model large-v3 \
  --output_format json \
  --compute_type float16

The JSON it produces contains segments, and inside each segment a list of words, each with start and end in seconds. That word timing is the raw material for everything downstream. On a machine without a capable GPU, run the base or small model instead; accuracy drops on proper nouns but the timing stays usable for a rough cut.

One honest caveat: automatic transcription is wrong sometimes, especially with crosstalk, accents, and technical vocabulary. For a rough cut that is fine, because you are selecting regions, not publishing captions. If this transcript will later become on-screen subtitles, it needs a human pass first.

Stage two: selecting segments as text

Now you read the transcript like a document and mark what stays. The low-tech version that works surprisingly well: export the transcript to a plain text file with a timestamp on each line, delete the lines you do not want, and let a script turn what remains back into time ranges.

A cleaner approach is to keep the JSON and write the keeper ranges yourself. Say you want the answer that runs from 2:14 to 2:48 and another from 5:02 to 5:20. You express those as a list of in and out points in seconds. The script's job is to read the transcript, let you pick, and collapse adjacent words into contiguous clips.

Here is the core of a Python helper that turns a list of chosen word indices, or a text search, into merged time ranges:

import json

data = json.load(open("interview.json"))
words = [w for seg in data["segments"] for w in seg["words"]]

def ranges_for(query):
    hits = [w for w in words if query.lower() in w["word"].lower()]
    return [(w["start"], w["end"]) for w in hits]

def merge(ranges, gap=0.4):
    ranges = sorted(ranges)
    out = [list(ranges[0])]
    for s, e in ranges[1:]:
        if s - out[-1][1] <= gap:
            out[-1][1] = e
        else:
            out.append([s, e])
    return [tuple(r) for r in out]

The merge step matters. Word-level ranges are jittery; without merging you would get a cut between every word. The gap parameter says "if two kept regions are within 0.4 seconds, treat them as one continuous clip." Widening the gap gives longer, looser selections; tightening it gives you more aggressive trims.

Stage three: emit something the NLE can open

You have a list of in and out points against a source clip. The last step writes that as a file your editor imports. You have three realistic targets, in rising order of how much they carry.

• EDL (Edit Decision List) is the oldest and most universal. Plain text, one event per clip, understood by Resolve, Premiere, and Avid. It is fiddly about timecode format but bulletproof once right.
• FCPXML carries far more, including clip names and multiple tracks, and imports cleanly into Final Cut and Resolve. It is verbose XML, best generated with a library rather than by hand.
• OpenTimelineIO (OTIO) is the modern lingua franca. It is a Python library that reads and writes EDL, FCPXML, and its own format, so you build your timeline once as OTIO objects and export to whatever your editor prefers.

OTIO is the one I reach for because it hides the format-specific pain. Building a timeline from your merged ranges looks like this:

import opentimelineio as otio

fps = 25
tl = otio.schema.Timeline(name="rough_cut")
track = otio.schema.Track()
tl.tracks.append(track)

for start, end in merged_ranges:
    clip = otio.schema.Clip(
        name="interview",
        media_reference=otio.schema.ExternalReference(
            target_url="interview.mov"),
        source_range=otio.opentime.range_from_start_end_time(
            otio.opentime.RationalTime(start * fps, fps),
            otio.opentime.RationalTime(end * fps, fps)))
    track.append(clip)

otio.adapters.write_to_file(tl, "rough_cut.fcpxml")

Change the output filename to rough_cut.edl and OTIO writes an EDL instead. Import that into Resolve, and your selected soundbites are laid end to end on the timeline, in order, ready to trim. The frame rate must match your footage or every cut lands a few frames off, so set fps deliberately.

Where this saves you and where it does not

What you get is a string-out: every keeper region assembled in sequence. For interview and dialogue work that is genuinely most of the assembly done. You skip the tedious scrub-and-mark pass and start from a timeline that already has the good parts in it.

What you do not get is judgment. The script cuts hard on word boundaries, so you will still nudge edit points to breathe, add room-tone handles, catch the moment where someone's best delivery came a beat after the sentence started. B-roll, pacing, music, the actual storytelling, all of that is yours. The tool builds the skeleton; you do the edit.

Two failure modes to watch. First, if the transcript timing drifts, and it can on long files, your cuts land on the wrong words; spot-check the first and last clip after import. Second, hard cuts between selections often clip the first phoneme of a word. Pad each range by a few frames on the in point (start - 0.08) and you will catch far fewer chopped syllables.

Wire these three stages into one script that takes a video file and a list of search terms or a marked-up transcript and produces an FCPXML, and you have turned the rough cut from an afternoon into a coffee break. The creative time you save goes straight back into the parts of editing that actually need a human.