Just wrapped up a massive project—transcribed 100 hours of old team interview recordings with Descript. Career-switcher here, used to staring at Grafana graphs all day, so this was a deep dive into a different kind of data processing.
Wanted to share the raw accuracy numbers I logged. I manually checked a random 10-hour sample.
**Overall word accuracy:** ~92%
**With speaker detection enabled:** Accuracy dropped to ~88%. It struggled a lot with cross-talk and identifying 4+ voices in older, noisy recordings.
The big surprise was how it handled very technical jargon. Our interviews were full of DevOps and cloud terms. Example from a log:
```text
Original: "We had to kubectl apply the manifest after the Prometheus scrape interval was adjusted."
Descript: "We had to cube cuddle apply the manifest after the Prometheus scrape interval was adjusted."
```
So it's great for clear, conversational audio. For niche terminology, you'll need to budget time for corrections. The editing workflow is fantastic, though—fixing those errors directly in the transcript is super intuitive.
Has anyone else run it through a large batch of technical content? Curious if you tuned any settings for better results.
92% for clean audio is about the industry baseline now, nothing revolutionary there. The speaker diarization hit is expected with legacy recordings, but a 4% drop is significant if you're paying per minute for "premium" features.
Your "cube cuddle" example is the real story. That's not a minor correction, it's a domain-specific failure that undermines the transcript's utility. If you're using this for any kind of archival or analysis, you've just outsourced your data integrity to a tool that doesn't understand the subject matter. The editing workflow is a band-aid on a broken process.
Did you calculate the additional time/cost for manually verifying and correcting the technical terms across all 100 hours? That's the real ROI, not the initial accuracy percentage.
Show me the TCO.
Your focus on the editing workflow is interesting, but I find that approach only viable at low volume. For 100 hours, manually correcting "cube cuddle" to "kubectl" across dozens of occurrences is a massive, hidden time sink.
I've found that pre-processing the audio with a custom vocabulary or glossary file, if the service supports it, is a better initial filter. Some transcription engines allow you to upload a list of domain-specific terms with preferred pronunciations. It won't catch everything, but it can reduce those catastrophic failures.
Have you considered a post-processing script? You could run a simple pattern replacement for known jargon after the initial transcript is generated, saving manual editing time.
"cube cuddle" gave me a laugh, but that's such a perfect example of where automated transcripts go sideways. I've hit the same thing with "Terraform" becoming "terror form".
You mentioned budgeting time for corrections, and for 100 hours, that's the real metric. I've found it's not just the glossary terms, it's also acronyms. Something like "SLA" often gets transcribed as "slaw" or similar.
For batches that size, I usually run the raw transcript through a post-processing step in Make or a simple Python script. You can set up a lookup table for your team's common jargon. It won't catch everything, but it can automatically fix dozens of instances of "kubectl" and "Prometheus" in one pass, saving a ton of manual editing. Descript's editor is good, but you don't want to be the find-and-replace bot for 100 hours worth of files.
Integration Ian