The obvious way to cut a 90-minute recording into short clips is to hand the whole thing to a model and ask it to find the good parts.
I tried that. It's expensive and the output degrades as it goes.
Why the obvious way fails
90 minutes of transcript is an enormous amount of context, and long context degrades judgement. The model starts confusing similar passages, loses track of what it already flagged, and its picks get worse the further in it goes.
So you pay the most for the least reliable output. Worst possible shape.
Most of this work doesn't need a model
Here's what I didn't expect: the majority of the pipeline is local analysis that costs nothing per call.
video_downloader # pull source from YouTube/TikTok/Reels/Shorts
transcribe # word-level ASR, with on-disk caching
transcript_pack # fold word-level into phrase-level markdown
scene_detect # content-aware shot boundaries via ffmpeg
snap_to_words # align cut points to word edges, 30-200ms padding
silence_cutter # detect and concat-cut around silence
Two of these deserve attention.
transcript_pack is the one that makes it viable
Word-level transcript for 90 minutes is huge and mostly noise — a timestamp on every token. Folded to phrase level it becomes something a model can read in one pass.
This is the pattern that makes agent pipelines affordable:
Reduce before the model sees it.
The same principle shows up everywhere once you look for it. Grepping ERROR lines out of a log before pasting it. Extracting changed functions instead of the whole diff. In every case the model doesn't need the haystack — it needs the needle, and finding the needle is often a local operation.
snap_to_words looks like a detail and isn't
Cutting on a scene boundary is visually correct and frequently lands mid-word, which sounds broken.
Snapping to word edges with a small padding window is the difference between a clip that sounds edited and one that sounds clipped. The 30–200ms padding exists because a cut placed exactly on a word boundary still clips the consonant.
This is the kind of thing that only gets built by someone who shipped a batch of clips and then read the complaints.
The order that works
1. Transcribe, then pack to phrase level.
2. From the packed transcript, pick candidate segments by topic.
← the only step where model judgement earns its cost
3. Run scene detection; snap chosen cut points to word boundaries.
4. Cut silence out of the selected windows.
5. Render, then run audio-pop and A/V sync checks.
Exactly one step involves paid judgement. Everything else is local.
Checkpoint the selection, not the render
Write the chosen segments — timestamps and reasons — to a file before rendering.
The selection is the expensive artefact. Rendering can be repeated cheaply; deciding what's worth keeping cannot. If the render fails, or you want a different aspect ratio next week, you want to start from the decisions rather than re-derive them.
This generalises to any batch job: parallelise the work, serialise the checkpoints.
A detail that tells you the intent
transcribe caches to disk and skips when the output JSON is newer than the source.
That's a small implementation choice with a large implication: this tool expects to be re-run. Which means the pipeline is designed to be iterated on, not executed once. Re-running after a tweak costs nothing.
Tools tell you how they expect to be used, if you read the small decisions.
If you want to try it:
curl -s https://files.dlazy.com/cdn/cli | bash
dlazy -h
Start with a 10-minute recording rather than a 90-minute one. The pipeline shape is identical and you'll find out where your assumptions are wrong for a tenth of the wall-clock time.
Top comments (0)