Why We Built Crisp
I was spending more time editing the 'um's out of product demos than I spent recording them. So I built a macOS app that does it locally, in minutes, without uploading anything.
I record a lot of screen recordings — product demos for EnvPilot, tutorial clips for docs, the occasional loom-style walkthrough for a customer who asked "can you just show me." The recording itself takes five minutes. The editing used to take forty, and almost all forty of those minutes were the same task: finding the silences and the "um"s and cutting them out, one at a time, in a timeline editor that wasn't built for this.
That ratio is what made Crisp happen. Not a grand insight about content creation — just a very specific, very repetitive fifteen-minutes-a-day annoyance that I finally got tired enough of to fix properly.
The problem, specifically
Screen recordings for product demos have a particular shape that generic video editors handle badly. You're narrating while you click through a UI, which means you pause constantly — to find the next thing to click, to remember what you were going to say, to let a page load. None of those pauses are intentional. They're not "let this beat land" pauses. They're "I lost my train of thought for 1.4 seconds" pauses, and a 10-minute demo recording easily has 60-90 of them.
Editing them out manually means: scrub to the silence, mark an in-point, mark an out-point, ripple-delete, repeat, and — the part that actually eats the time — do it while keeping the video in sync with the audio, because if you cut the audio track and not the video track (or cut them at slightly different points), you get a visible stutter or a lip-sync-style desync between what's on screen and what's being said.
I tried the obvious things first. Auto-silence-removal plugins for existing editors exist, but most of them only touch the audio track, leaving you to manually re-sync video, which defeats the purpose. Cloud-based editing tools that promise "remove filler words automatically" mostly work by uploading your recording to their servers — which is a hard no for anything that has a staging URL, an API key, or a customer's data visible on screen, which is most of what I record.
What we built
Crisp is a native macOS app that does two things: it finds silence and filler words ("um," "uh," and similar) in a recording, and it cuts them out of both the audio and video tracks together, so what's left is tight and still in sync. Everything happens on-device.
The pipeline is two tools doing what they're already good at, stitched together instead of reinvented:
ffmpeg'ssilencedetectfilter finds the actual silent stretches in the audio — this is a solved problem and ffmpeg solves it well, so there was no reason to write a custom audio-analysis routine.whisper.cpptranscribes the recording locally to find filler words. Because it runs on-device (no API calls, no upload), a ten-minute recording never leaves your machine. This was the part I cared about most — I record demos with real customer data in staging environments often enough that "upload your screen recording to our servers to process it" was disqualifying for anything I'd actually use myself, so it had to be disqualifying for what we shipped too.
Crisp merges the two signals — silence and filler-word timestamps — into one cut list, applies it to both tracks simultaneously, and exports. The original file is backed up first, unconditionally, before anything is touched. That's a deliberate, slightly paranoid choice: destructive automated edits on your only copy of a recording is the kind of mistake you make exactly once, and I didn't want anyone — including me — to make it even once.
It's for macOS 14+ and it's open source under GPL-3.0.
The honest tradeoffs
Filler-word detection isn't perfect, and I don't think it can be. Whisper is good at transcription; it's not a purpose-built filler-word classifier, so it occasionally flags a legitimate short word as filler or misses a drawn-out "uhhhh" that doesn't transcribe the way a clean "uh" does. Crisp shows you the proposed cuts before committing rather than auto-applying blind, specifically because I don't trust any filler-word heuristic — including ours — enough to run it unsupervised on something I can't easily undo.
Local processing means local compute, which means it's not instant. Whisper.cpp on a MacBook Air handles a 10-minute recording in well under the length of the recording itself, but it's not "click a button and it's done in a second" the way a marketing page about "AI editing" might imply. That's the honest cost of the on-device promise, and it's a cost I'll take over uploading footage every time, but it is a real cost.
We didn't build a general-purpose video editor, on purpose. Crisp does one job — cut silence and filler words — and stops there. Early on I was tempted to add trimming, captions, transitions, the whole feature list a "real" editor has. I didn't, because the moment Crisp tries to be iMovie, it stops being the fast, boring tool I reach for between recording and uploading. If you need real editing, do that in a real editor afterward — Crisp's job is to save you the tedious first pass, not replace the rest of your pipeline.
Where it's useful, and where it isn't
Crisp is good for exactly the thing that made me build it: solo screen recordings where you're narrating live and don't want to hand-edit out your own pauses. It is not trying to be a podcast editor, a multi-camera editor, or a captions tool. If your recording has one speaker and a lot of natural pauses baked into a live narration, it'll save you most of an editing pass. If it doesn't fit that shape, it's probably not the right tool, and I'd rather say that than pretend otherwise.
It's free, it's open source, and if you've got a filler-word detection idea or a codec Crisp doesn't handle well, the repo is open at rafay99-epic/Crisp — contributions welcome, especially around wider format support.
Ask AI