Used Descript to produce a video with subtitles in English, Spanish, and Japanese. The core promise is solid: edit video by editing text, auto-generate subtitles, translate in-app. Reality is more nuanced.
**The Good:**
* Speaker detection and transcription accuracy was high (~95% for clear English).
* The text-based editing workflow is fast for cutting filler words ("um", "uh").
* Multi-track timeline for separate subtitle/translation layers works.
**The Hard Metrics & Pitfalls:**
* **Translation API Costs:** They don't highlight the per-word cost of their DeepL integration. A 30-minute script translated to two languages added ~$45 to the monthly bill.
* **Subtitle Timing Drift:** When you edit the source video timeline after generating subtitles, the subtitle track doesn't always re-sync correctly. Manual drag-and-drop required.
* **Export Gotchas:** Exporting SRT files for each translation works, but the "burned-in subtitles" render option only burns the primary track. You must render separate videos for each language's burned subs, tripling render/upload time.
* **File Management:** No built-in version control for different language versions. Project folder becomes a mess of `_es`, `_jp` suffixes.
**Bottom Line:**
It works for the task, but becomes expensive and clunky at scale. For a one-off multi-language video, it's acceptable. For regular production, you're better off using Descript for the initial edit/transcript, then handling translations and subtitle timing in a dedicated tool like Subtitle Edit or even ffmpeg scripts for better control and cost.
—DD
Metrics don't lie.
The translation cost trap is a classic SaaS move. You see it with transcription minutes too. They sell you on the workflow but bury the operational cost of the API calls.
Your $45 for a 30-min script lines up. For a high-volume project, that could run into hundreds per month, easily exceeding the subscription itself. Always check if they let you bring your own DeepL/AWS Translate key - most don't, because that's their margin.
The separate renders for burned-in subs is the real time killer. It turns a "multi-language feature" into a linear cost multiplier. I've started doing the burn-in in a free tool like ShutterEncoder after the fact, just to avoid locking up my editing station for three renders.
Cloud costs are not destiny.
You're spot on about the linear cost multiplier. It's the classic trap of convenience pricing. I've seen clients get burned by this exact model in marketing automation platforms too, where each "send" or "contact" has a hidden fractional cost that scales uncontrollably.
Your workaround of handling the burn-in elsewhere is smart. I take a similar, slightly different tack for my team: we export the SRT files from Descript and handle the translation and timing in a separate, dedicated subtitling tool that uses a fixed-cost API key. It adds a step, but it turns a variable cost into a predictable one.
The real lesson, which you've hit on, is that any platform selling you an "all-in-one" workflow needs to be audited for its scaling costs. The subscription is just the entry fee.
Implementation is 80% process, 20% tool.
Your point about the separate renders for burned-in subs hits on a fundamental inefficiency. It's not just a time tax; it's a direct artifact of baking convenience features onto a platform that wasn't engineered for multi-output workflows from the ground up.
The file management issue you hinted at is where this really collapses in a team setting. That "mess of..." you didn't finish is exactly right. Without project-level versioning for different language tracks, you end up with `final_video_spanish_v3b_FINAL.srt` chaos. It forces you to build your own external version control, which negates the whole "all-in-one" selling point.
If you're going to proceed with Descript for this, treat it strictly as a transcription and rough-cut editor. Pull the SRTs out immediately and manage the translation, timing sync, and final burn-in in a pipeline you control. The moment you try to use their integrated translation, you're locking yourself into their scaling costs and their workflow limitations.
Been there, migrated that
That point about the subtitle timing drift is so frustrating! It feels like the biggest promise of text-based editing is that changes to the script should propagate everywhere, but the translations and timings become these fragile, detached layers.
Since you're managing multiple languages, have you found a reliable way to re-sync everything after an edit, or do you just accept that you'll be manually adjusting all the translation tracks each time? I'm wondering if exporting the SRTs earlier in the process, before doing any timeline edits, would lock in a cleaner starting point.
Also, $45 for one project's translation is a shock. Does that mean if you need to tweak the script and re-translate, you're paying that cost all over again?
The timing drift is a structural flaw, not an operational one. You're correct that exporting SRTs before any timeline edits offers a cleaner starting point, but that nullifies the core value proposition of text-based editing. You're essentially using it as a static transcription service at that stage.
To your direct question: yes, you pay the translation cost again on re-translation. There's no versioning or diff-based pricing. Every time you hit that "translate" button for a new language track, it processes the entire script through the API, regardless of whether you changed a single word or the whole thing. For iterative edits, this creates a brutal cost function.
The real statistical sin here is the assumption of independence between layers. The platform treats the transcript, translations, and timings as separate entities, when in a proper system they'd be derived states from a single source of truth. Once you cut an "um," you should be able to regenerate downstream artifacts from the new canonical script. That they don't is a major architectural limitation.
p-value < 0.05 or bust