Batch STT on archives: where processing breaks
Archive processing of recordings usually starts the same way: a script iterates over files and sends each one for recognition in a separate request. While there are dozens of recordings, the scheme works.
On a corpus of hundreds of hours of audio, it hits the recognition timeout: a long recording does not manage to return within the allotted window, the connection drops, and it is not part of the result that is lost, but the entire file.
Moreover, the failure reproduces on the same recordings — meetings, interviews, long calls, that is, exactly where transcription is needed most.
The second bottleneck is loss of the task queue. When iteration runs in a single process, any restart resets the state: it is unknown which files have already been processed and which have not.
The next pass takes everything again, duplicates completed transcriptions, again runs into the same timeout — and does not move forward.
If files were previously split into parts, merging adds to the problem: fragments of one recording get mixed up, timestamps drift, and the text stops matching the audio.
The remainder of the archive is covered by manual transcription.
This is the most expensive part of the work: it does not scale, ties people to hours of audio, and still does not produce a single corpus — speaker labels, timestamps, and dialogue structure are formatted differently in different files. The result is not an archive ready for search and analysis, but a set of scattered texts with gaps.
Each of these failures is treated by architecture, not patience: splitting long recordings into meaningful segments, enqueuing tasks with a state log, retrying with continuation instead of retrying from scratch, and reassembling segments back into a complete transcription. Next, we look at how this is addressed at the implementation level.
What end-to-end processing of an audio archive provides
Batch transcription changes the problem statement: not a single file on a button press, but the entire archive in one run.
The scheduler breaks accumulated recordings into jobs, distributes them across a queue, and gives handlers as many parallel threads as the infrastructure can sustain.
An archive that would stretch over weeks with manual review is completed in hours — the process is started once and not monitored.
The main difference is in the class of failures. With one-by-one processing, a failure of a single file or a connection drop with the model stops the work and requires a manual restart, while unfinished items accumulate into an unnoticed tail.
In batch mode, a job is marked as failed, goes into retry with increasing delay, and the queue moves on. At the end of the run, there is a report: how many recordings were recognized, how many were rejected, and why.
Predictable load is not a side effect but a condition. Limiting parallelism and launch windows prevents the archive from crowding out other services, so a long array does not turn into a spike in latency for adjacent systems.
This is the answer to the cost of downtime: resources are occupied exactly for the duration of the run, not spread thinly over a week.
What to record in the checklist: archive processing time from launch to report, the share of recordings completed without human intervention, and queue behavior when an external service is unavailable.
These three values show whether the result is reproducible on the next array or whether the previous success was accidental.
Batch STT launch options and their limitations
The batch STT launch scheme is more important than model choice: it determines how much manual work remains around recognition and what happens if processing fails in the middle of the archive.
Below are four options that are chosen between in practice; we work with open models such as Whisper and select the surrounding tooling for the specific scenario.
| Option | When it fits | Limitations |
|---|---|---|
| One-time archive run | An array of recordings has accumulated and the result is needed once: interviews, podcasts, old calls | No schedule and no reprocessing — every new file again requires a manual launch |
| Scheduled job queue | The stream of recordings is stable: meetings, call center, branch voice recorders | Queue depth and retries need control, otherwise jobs accumulate silently and unnoticed |
| Hybrid scheme | Some recordings are needed immediately, the rest can be transcribed later | Both branches must write results to the same storage with the same labeling |
| Custom scripts | A simple scenario that is not a problem to rewrite for yourself | All surrounding tooling is on the customer's side: tracking what has been processed, restarting failed files, logs |
The general limitation of the approach: batch recognition does not provide real-time results, and as volume grows, the bottleneck becomes not the model but job scheduling and transcript storage.
During task analysis, we look at archive size, the frequency of incoming recordings, and deadline requirements — and propose a scheme, not a set of scripts.
How we build an audio transcription pipeline
A transcription pipeline is not running a model on a single file, but a stream of tasks with predictable throughput time and repeatable quality. As long as the order of stages is not fixed, each new archive is processed manually, and the result depends on one person. Below is what our work looks like from intake of recordings to handover of the system.
- Archive and sound quality audit. We inventory containers, duration, number of channels, and the share of recordings with noise, music, or telephone compression. On a control sample, we measure intelligibility — it determines where preprocessing is needed and where the model will cope as is.
- Queue scheme. We split long recordings into segments and distribute them across streams: new requests with high priority, archival exports in the background. We select the number of parallel tasks so that the queue does not grow faster than it is processed.
- Retry configuration. We separate temporary failures — storage unavailability, timeout exceedance — from permanent ones: a corrupted container, an empty track. We retry the first with increasing delay and a limit; the second go to quarantine with a reason, rather than being lost silently.
- Recognition quality control. We calculate the share of words with low confidence, compare against a reference transcription on a control sample, and monitor timestamp stability. We agree on the threshold below which a recording goes to manual review before launch.
- Handover to operation. We provide the configuration, queue scheme, restart regulations, and metrics dashboard. Your engineers run their archive independently — after that, the pipeline works without our involvement.
What is included in the delivery: schemes and regulations
We hand over not only a configured pipeline but also everything needed for it to live without us: processing parameters, the recording path scheme, access policies, and failure procedures.
We agree on each artifact at acceptance — the customer's engineer must be able to launch reprocessing and explain why a particular file was recognized incompletely.
- Pipeline configurations — segmentation parameters by silence, model selection by language and channel quality, domain term dictionaries, and confidence thresholds at which a fragment goes to re-recognition.
- Processing scheme — how a recording travels from upload to a finished transcript: enqueueing, loudness normalization, splitting into fragments, assembling the result, and delivery via file storage or a readiness notification.
- Access policies for recordings — roles and visibility scopes, audio and text retention periods, encryption in transit and at rest, and an access log for sensitive materials.
- Output formats — a transcript with timestamps and speaker labels, plus text and subtitle variants; we fix the field structure so it can be loaded into a record system without manual editing.
- Failure handling procedure — a catalog of typical failures (corrupted file, overlapping voices, noise, unfamiliar language), escalation order, and idempotent restart rules so that a retry does not duplicate results.
- Operations documentation — instructions for launching the batch, a component placement diagram, the procedure for updating dictionaries, and a control set of recordings for verification after changes.
- Monitoring and reporting — metrics for the share of successfully processed files, queue waiting time, and volume of manual rework; alerts go to the responsible person before the queue stalls.
Case study: call center archive and transcription time
The customer is a contact center with continuous recording of all lines. At the start, the call center archive contained about 12,000 hours of audio, and no more than 4% was transcribed manually — that is, only the sample that quality control operators had time to process.
The share of automatically transcribed recordings was zero: any search by conversation content meant listening. Processing one recording took tens of minutes, so the reason for the growth in repeat contacts in the accumulated array simply could not be found.
What we changed
We built a batch recognition pipeline (batch STT): files from storage are split into segments, normalized by loudness, and call metadata is pulled in for each one — line, operator, time, campaign tag.
Jobs go through a queue, and the result is written by the recording key, so re-running a segment after a failure does not create a duplicate in the database and does not break the run.
We took the open model family Whisper as a basis and fine-tuned it on labeled calls with industry vocabulary, tariff names, and abbreviations.
What resulted
The entire archive was processed in three days instead of months of selective work, with coverage of 100% of recordings.
The recognition error rate in the stream fell from 11% to 4.5%, and manual interventions dropped to about six dozen per month versus almost two thousand: an operator gets involved only for disputed names, addresses, and numbers.
New calls become searchable within an hour after the conversation. Export now runs by phrases and tags across the entire array at once, and quality control relies on before-and-after metrics rather than random listening.
How archive processing differs from streaming transcription
Streaming transcription and archive processing solve the same task — turning speech into text — but optimize different quantities.
In streaming, a recording is split into short windows, and the result is delivered as it arrives: accuracy and context completeness are sacrificed for minimal processing latency.
Batch recognition (batch STT) works with the file as a whole, so the queue is planned by available resources, not by a stopwatch.
A streaming scheme is needed where text is required at the moment of speech: subtitles, operator prompts, online conversation monitoring.
The price is truncated context at window boundaries, sensitivity to pauses and noise, and the inability to go back and refine an already delivered fragment.
Archive processing has no such limitations: the file is known in full, so repeated passes, audio normalization, speaker separation, and checking against a domain glossary are available.
On accumulated arrays — call recordings, interviews, media libraries, exports for a period — it is batch processing that wins.
What matters here is not processing latency but throughput and reproducibility: the same file on a repeat run produces the same text, and an updated model or term dictionary can be applied to the entire archive at once. A delay of minutes and hours is not critical for reporting and searching recordings.
Applicability criteria come down to three questions. Is the result needed at the moment of speech, or is it acceptable to wait until the batch finishes processing? Is reprocessing required — for example, applying a refined glossary to old recordings?
How homogeneous is the input: long files without clear phrase boundaries are more reliably given to a batch scheme. A hybrid is often chosen: a draft streaming transcription for navigation, and the final one via batch archive processing.
Technical concerns before starting a project
Transcription quality is determined not only by the model but also by what is fed into it.
Batch recognition (batch STT) processes files as a whole, so the work begins with analyzing the archive: noise level, number of speakers, pause duration, and the format and quality of source files.
Some questions come up at almost every technical meeting — we answer them before the start so that the recognition accuracy estimate is based on measurements, not promises.
The recordings are noisy, and some are from a voice recorder in a meeting room. What actually improves accuracy?
The base model Whisper confidently handles clean dictation, but on noisy recordings preprocessing and tuning are what matter: noise reduction, level alignment, silence trimming, channel separation, and speaker labeling.
We separately connect a dictionary of domain terms and names — they account for the main share of errors. We do not declare accuracy: a labeled fragment of your archive gives a measurable share of words that are accepted without manual editing.
The recordings mix languages and dialects — will recognition get confused?
We determine language by segment, not by the file as a whole, so switching within a single dialogue is handled correctly.
For dialects and industry vocabulary, we add dictionaries and fine-tuning on your material — the share of substitutions of "similar" words decreases. We set the primary language explicitly so that short utterances do not lead the model astray.
The archive is partially transcribed, and the audio is sensitive. What about reprocessing and transfer?
We do not recompute anything unnecessarily: we keep a log based on the file checksum and processing settings, so unchanged recordings are skipped, and only new or modified ones are launched again.
On an array of tens of thousands of hours, this is the difference between an overnight run and weeks of computation.
Audio is transferred over a secure channel to storage with restricted access and an access log; if a recording must not leave your perimeter, we deploy the environment on your infrastructure — only transcription results go outside.
Let's discuss the task and come back with a work plan
To make the scope estimate substantive rather than a "rough guess," it helps to receive sample recordings and archive statistics from you at the start.
The analysis takes several days: our engineers listen to fragments, look at duration, number of speakers, and sound quality, and calculate the share of material that will require separate processing.
As a result, you receive a work plan with stages and responsibility boundaries, not a generic "we'll do it."
What to send so the conversation gets straight to the point:
- 5-10 samples from different batches — studio recording, call, noisy room: they show the real complexity
- volume: how many hours of audio per month and how quickly the archive is growing
- requirements for the result — text only, speaker labeling, timestamps, export format
- a list of terms, names, and abbreviations that need to be recognized accurately
- the material intake scheme: one-time archive export, regular folders, exchange with your system
- infrastructure constraints: where batch STT is computed — in your environment or on our side
Then we fix the stages, timelines, and acceptance criteria on a pilot batch, after which we move to the full volume. Describe the task and send the materials — we will come back with a scope estimate and a work plan.