DEV Community: Toshius Klay

How to Turn Interview Audio into Analysis-Ready Transcripts

Toshius Klay — Fri, 03 Jul 2026 14:10:02 +0000

Last year I transcribed forty hours of developer interviews by hand because I didn't trust the AI tools. My wrists hurt. I missed a deadline. I still botched a quote. One participant said they hated Docker. I typed "loved Docker." That single error skewed my feature priority matrix for a week.

Now I use a workflow that is boring, repeatable, and won't let garbage audio wreck your dataset. It goes like this.

1. Record audio that won't wreck your accuracy

I learned this in a glass-walled conference room with a laptop mic. The echo was so bad that "Git" became "get" for two straight hours. I had to guess context on twelve different lines. Never again.

Use a directional mic or a decent USB interface. Laptop mics grab keyboard clatter and fan hum. Record in a small, carpeted room if you can. Hard surfaces bounce sound and confuse speech engines.

For remote sessions, make participants wear headphones. It stops their speakers from bleeding into your recording. Ask people not to talk over each other. If you need speaker labels later, have them introduce themselves at the top.

If you are pulling audio from a Zoom recording, normalize it first. ffmpeg handles this in one pass:

ffmpeg -i interview.mp4 -vn -acodec pcm_s16le -ar 16000 -ac 1 interview.wav

Mono WAV at 16kHz. Speech engines prefer it. Mono removes stereo separation weirdness, and 16kHz covers the vocal range without bloating your file.

2. Generate the draft automatically

I upload the file to whatever engine I'm using that month. Lately it is Whisper.cpp running locally because I got paranoid about participant data hitting cloud APIs. Last year I burned through Otter credits. The service matters less than the settings.

I pick verbatim mode when I am looking for hesitation or power dynamics. It keeps the ums, false starts, and pauses. I pick clean mode for thematic analysis or when I am handing quotes to a PM who just wants the point, not the verbal stumbles.

If the tool offers auto-detect for language, verify it. I once ran a mixed English-German session and the engine tagged the whole file as Dutch. The gibberish propagated for pages before I noticed.

Do not treat the raw file as final. Automated transcripts hit maybe 85-95% accuracy in ideal conditions. Accents, jargon, and crosstalk drop that number fast.

3. Review like you are being audited

This is the step I used to skip. It cost me.

Open the draft next to the audio. Play it at 1.0x or 1.25x. Fix these exact things:

Misheard domain terms. "React" becomes "reactant." "Kubernetes" turns into phonetic mush. These look tiny but destroy coding accuracy.
Speaker labels. Auto-tools merge speakers during crosstalk. Label each turn yourself.
Crosstalk and drops. When two people talk at once, the transcript may mash both voices into nonsense. Mark gaps with [inaudible] so you do not code silence as agreement.
Punctuation for meaning. A missing comma can flip enthusiasm into sarcasm.
Nonverbal cues only if they matter. I mark laughter or long pauses with a standard notation. I skip them if I am just hunting for feature requests.

Here is the template I paste into my editor:

[00:03:15] Interviewer: Walk me through how you deploy to production.
[00:03:18] Participant: Usually we just run the script, wait for the build, and then... actually, sometimes we check the logs first.
[00:03:24] [pause 3s]
[00:03:27] Participant: If it's a Friday, we don't deploy at all.
[00:03:30] [laughter]

ISO timestamps and bracketed tags. I keep lines under 100 characters so they import cleanly into qualitative tools.

4. Format for your analysis stack

I've imported transcripts into NVivo, Dovetail, Atlas.ti, and plain Git repos. Consistency matters more than aesthetics. NVivo chokes on inconsistent timestamps. Dovetail gets weird if your speaker labels change format between files.

Standardize these before you call it done:

Speaker names. Pick "Interviewer / Participant" or "P1 / P2" and stick with it across every file.
Paragraph breaks. Start a new paragraph when the topic shifts, not just when someone stops talking.
Timestamps. Drop them every 30-60 seconds, or at every speaker turn if your tool requires it.

If your team works async across time zones, timestamps are the only way another researcher can pull the original clip for context.

When I store transcripts in Git for team review, I add YAML frontmatter so we can search later:

---
project: onboarding-research
session_id: 2024-06-12_p5
participant_id: P5
method: semi-structured-interview
transcript_type: clean
duration_minutes: 42
---

This turns a folder of text files into something you can actually query.

5. Export and version your files

Save two copies. Every time.

Raw automated output. This is your audit trail.
Corrected transcript with final labels and formatting.

Export depends on your pipeline:

TXT or MD for coding platforms.
DOCX if your team lives in Word comments.
JSON if you are feeding them into a custom NLP pipeline.

Keep both. Six months later, when a stakeholder asks if that brutal quote is real, you need to trace it back to the source audio without starting from zero.

Verbatim vs. clean: pick one and lock it in

I once switched formats mid-project because I got lazy. I had to re-review every file. Do not be me.

Use verbatim when:

You are studying language patterns, pauses, or interaction dynamics.
Your methodology is discourse or conversation analysis.

Use clean when:

You are hunting for themes, pain points, or feature requests.
A PM or executive will read it and only cares about the content, not the delivery.

Most of my UX work uses clean transcripts. Academic work usually needs verbatim. You can generate both. Keep the verbatim file as your source of truth, then derive a cleaned copy for reporting.

Closing the loop

Good transcription is a quality gate for your whole project. A transcript with mislabeled speakers or missing context will send your coding sideways. You will not notice until you are writing findings at 11 PM and questioning your sanity.

Record clean audio. Generate a draft. Review it line by line with the original playing. Format it consistently. Lock in your raw and edited versions.

Your future self, staring at fifty coded segments at 11 PM, will thank you.

Build a Reliable AI Transcription Pipeline: A Developer’s Field Guide

Toshius Klay — Fri, 03 Jul 2026 14:09:08 +0000

You shipped the feature last Tuesday. Upload audio, hit transcribe, display text. By Friday your users were complaining about garbled timestamps, missing speaker labels, and a bill that made your CFO flinch. Raw API output isn't enough for production. You need a pipeline.

Most speech-to-text tutorials stop at curl. They don't cover audio preprocessing, model selection, or how to clean up the mess that comes back when three people talk over each other in a Zoom recording. This guide walks through what actually works.

How the sausage gets made

AI transcription isn't a black box you lob files into. It's a chain of decisions. Audio gets normalized, chunked, fed to an acoustic model, and reconstructed into text. Then a language model guesses punctuation and paragraphs. If you want speaker labels, a separate diarization model runs alongside it.

The pipeline looks like this:

Audio input and format normalization
Chunking and resampling
Model inference (ASR)
Post-processing (punctuation, formatting)
Speaker diarization (optional but painful)
Export and storage

Skip step 1 or 2 and you'll pay for step 3 twice.

Step 1: Fix your audio before it hits the API

Developers love to send whatever comes out of the browser's <input type="file"> straight to the cloud. Don't. APIs have preferences, and your users upload garbage.

Standardize on these specs:

Format: Mono WAV or FLAC. Stereo confuses some models.
Sample rate: 16 kHz or 24 kHz. Resample if you have to.
Bitrate: 16-bit PCM. No 32-bit float surprises.
Preprocessing: Normalize loudness to -16 LUFS. Strip silence longer than 2 seconds if your ASR bills by duration.

Use ffmpeg. It's ugly but it's everywhere.

ffmpeg -i input.m4a -ar 16000 -ac 1 -sample_fmt s16 output.wav

That one line fixes half the accuracy issues you'll see in production. It converts variable-bitrate user uploads into something the model actually expects.

Step 2: Pick the right engine for the job

Not all transcription APIs are the same. They optimize for different things. Here's the honest breakdown:

OpenAI Whisper (API or self-hosted)

Great accuracy across languages
Cheap on API, cheaper if you run base or small locally on a CPU
No native speaker diarization
Slower than cloud providers on long files

Google Cloud Speech-to-Text

Excellent real-time streaming via gRPC
Good speaker diarization (up to 8 speakers in some configs)
Pricier, especially with premium models like latest_long
Needs audio in specific containers (LINEAR16, MULAW, etc.)

AWS Transcribe

Solid medical and call analytics variants
Speaker partitioning works but lags behind Google
Turnaround is batch-oriented; real-time exists but feels bolted on

Deepgram Nova

Fast. Like, actually fast.
Good at messy audio (background noise, accents)
Speaker diarization is decent but costs extra tiers

For most apps, Whisper hits the sweet spot of cost and accuracy. If you need live captions during a WebRTC call, Google Cloud's streaming API is hard to beat.

Step 3: Code a resilient batch pipeline

Here's a minimal Python worker that handles the full flow. It preprocesses with ffmpeg, sends to an API, and structures the output. Swap in your provider of choice.

import subprocess
import json
import requests
from pathlib import Path

def normalize_audio(input_path: Path, output_path: Path) -> None:
    subprocess.run([
        "ffmpeg", "-y", "-i", str(input_path),
        "-ar", "16000", "-ac", "1", "-sample_fmt", "s16",
        str(output_path)
    ], check=True)

def transcribe_file(audio_path: Path) -> dict:
    with open(audio_path, "rb") as f:
        # Example using Whisper API; swap for Deepgram, AWS, etc.
        response = requests.post(
            "https://api.openai.com/v1/audio/transcriptions",
            headers={"Authorization": f"Bearer {API_KEY}"},
            files={"file": f},
            data={
                "model": "whisper-1",
                "response_format": "verbose_json",
                "timestamp_granularities[]": "word"
            }
        )
        response.raise_for_status()
        return response.json()

def process_upload(raw_path: Path) -> dict:
    clean_path = raw_path.with_suffix(".wav")
    normalize_audio(raw_path, clean_path)

    result = transcribe_file(clean_path)

    # Post-process: rebuild transcript with word-level timestamps
    words = result.get("words", [])
    segments = []
    current_segment = {"start": words[0]["start"], "text": ""}

    for word in words:
        current_segment["text"] += word["word"] + " "
        # New sentence heuristic
        if word["word"].endswith((".", "!", "?")):
            current_segment["end"] = word["end"]
            segments.append(current_segment)
            current_segment = {"start": None, "text": ""}

    return {
        "duration": result.get("duration"),
        "segments": segments,
        "raw": result.get("text")
    }

Here's what actually matters in that snippet. We ask for verbose_json and word timestamps. That granularity lets you rebuild sentences cleanly instead of accepting a wall of text. We also normalize audio before upload. Don't let users foot the bill for weird codecs.

Step 4: Add speaker labels without losing your mind

Speaker diarization is still the hardest part of transcription. Most APIs that offer it charge more, and the accuracy drops when speakers interrupt each other.

If your provider supports it, enable it at the API level. If not, you'll need a separate model like pyannote.audio or AWS's channel-based routing.

A cheap heuristic that works for interviews: force single-channel audio and ask the API to partition speakers. If that fails, fall back to a secondary diarization pass on the normalized file.

# Pseudo-code for dual-pass pipeline
transcript = transcribe_file(clean_path)
diarization = run_pyannote(clean_path)

# Merge word timestamps with speaker segments
for word in transcript["words"]:
    speaker = diarization.find_speaker_at(word["start"])
    word["speaker"] = speaker

It's not perfect. You'll still need manual review for content that ships to customers. But it gets you 90% of the way there.

Step 5: Format for humans, not machines

Nobody wants a raw JSON dump. Your end users want paragraphs, timestamps they can click, and speaker names.

Structure your final output like this:

{
  "segments": [
    {
      "speaker": "A",
      "start": 0.0,
      "end": 4.5,
      "text": "The API returns words, but humans read sentences."
    }
  ]
}

Export to SRT if you're building subtitles:

1
00:00:00,000 --> 00:00:04,500
The API returns words, but humans read sentences.

And always store the raw API response. When a user reports an error, you'll want to replay it without burning more credits.

The tradeoff framework you actually need

You'll face three knobs in production. Here's how to turn them.

Speed vs. accuracy
Fast modes use smaller models. Use them for search indexing and internal notes. Use best-quality models for customer-facing captions and compliance logs.

Cost vs. precision
Batch processing is cheaper per minute than real-time. If you don't need live captions, don't pay for streaming. Reserve premium engines (Google's latest_long, Nova-2) for your highest-value content.

Speaker labels vs. complexity
Don't enable diarization unless someone reads the labels. If it's just a giant blob of text for full-text search, skip it. You'll save money and processing time.

Common gotchas

Timestamps drift on long files over 30 minutes. Chunk at 10-minute boundaries if your API allows it.
Code switching (mixing languages in one file) breaks most monolingual models. Split by language if possible.
Profanity filters in enterprise APIs will asterisk out words in medical or legal transcripts. Disable them if your provider lets you.
WebRTC audio is often sampled at 48 kHz stereo. Downsample before sending.

Wrapping up

Building with AI transcription isn't hard. Building it so it doesn't break in production is. Preprocess your audio, pick an engine that matches your latency budget, and post-process the output into something readable. Treat the API like a component, not a magic wand.

Your users will thank you. Your wallet will too.