Sending a five-minute recording to a speech-to-text API is easy. Sending a two-hour meeting and getting back a transcript that is complete, ordered, and safe to retry is a different problem.
The model is only one part of the system. A production pipeline also has to deal with upload limits, long processing times, chunk boundaries, repeated text, timestamp drift, speaker labels, partial failures, and users refreshing the page while the job is still running.
This article describes a provider-neutral architecture for handling those problems. The examples use TypeScript-like pseudocode, but the same design works with most queues, object stores, databases, and transcription providers.
A long transcription should not depend on one browser connection remaining open.
The upload endpoint should store the media, create a job, and return a stable identifier. A worker can then continue even if the user closes the tab.
The UI can poll GET /transcriptions/:jobId or subscribe to status events. Either way, the job state belongs in the backend rather than in the browser.
Users upload unpredictable files: stereo video, quiet voice notes, variable frame-rate recordings, and formats that a transcription provider may not accept directly.
For spoken audio, a common intermediate representation is mono PCM audio at a fixed sample rate. The exact settings depend on the model and provider, so check their documentation rather than converting every file to an arbitrary format.
Normalization is also a useful place to inspect duration, detect a file with no audio stream, and reject corrupt media before spending money on inference.
Store the normalized file separately from the original. The original may be needed for exports or debugging, while the normalized version should be treated as a reproducible processing artifact.
Long recordings usually have to be divided into smaller sections. A fixed split every 30 seconds is simple, but it can cut through a word or sentence.
A better strategy is: choose a target chunk length; search near that boundary for a suitable silence; add a small overlap on both sides; keep the exact source start and end time for every chunk.
The overlap gives the model context at the edges. It also creates duplicate text, which must be removed during the merge step.
This is a known long-form ASR problem. The original Whisper paper describes buffered transcription over consecutive windows, while the OpenAI speech-to-text guide discusses carrying context from a previous chunk and supplying uncommon names or acronyms.
Before processing a chunk, the worker checks whether a completed result already exists. If it does, the worker exits without calling the provider again.
Retry temporary failures with exponential backoff and jitter. Do not retry permanent errors such as an unsupported codec forever. A dead-letter queue is useful for jobs that need investigation.
Idempotency matters here. Queue systems commonly deliver a message more than once, and workers can crash after the provider completes but before the database update succeeds. Reprocessing must not silently create duplicate transcript sections or duplicate charges.
Most providers return timestamps relative to the beginning of the uploaded chunk. Users need timestamps relative to the complete recording.