Audio is not a document: why transcription needs its own pipeline

Most translation tools treat audio as an afterthought: transcribe it somehow, then push the text through the same machinery as a Word file. The output is a wall of words — technically a transcript, practically unusable for the people who need one.

What a real transcript deliverable needs

• Speaker diarization — who said what, labeled consistently across an hour of interruptions.
• Fidelity modes — a marketing interview wants clean readable text; a deposition wants every “um”, false start, and pause preserved, because verbatim is a legal requirement, not a style choice.
• Per-speaker translation with context — translating turn by turn with surrounding context, not sentence by sentence in isolation.
• Word-level timestamps — so subtitles respect reading speed and courts can cite a moment.
• The client's template — transcripts that land inside the DOCX the end client requires: logo, case number, signature block, footer.

Why we built it as a branch, not a bolt-on

Audio fails differently than text: crosstalk, accents, phone-line compression, a recorder on the far side of the room. So the audio branch has its own ASR stack, its own QA checks, and its own delivery formats — and then joins the same glossary enforcement and reporting as every other job. Same guarantees at the end, different road to get there.

That is also why bilingual transcript delivery — source and translation, diarized, timestamped, in the client's own template — is a single upload here and a three-vendor relay everywhere else.