If a speech recogniser keeps mangling a show’s character names, places and invented terms, start with custom vocabulary ASR. Give the engine the terms and, optionally, their pronunciations and display forms. If that is not enough, move to a custom language model, and go to acoustic fine-tuning only once you have plenty of transcribed audio from the show. Whichever route you take, the proof has to come from your own programmes: word error rate reported separately for accented speech, overlapping dialogue and music beds, plus a term-level error rate for the names, because one overall score hides both kinds of failure.

Web AR overlays that ship alongside media products need testing on real devices too. Browser and device support differs widely, so you establish consistency on real phones and plan a fallback; you cannot assume it. On the speech side, clean-speech benchmarks miss failures that accented, noisy and conversational audio exposes.

Can we feed custom vocabulary ASR a glossary of character names?

Yes. For proper nouns, Amazon Transcribe and NVIDIA Riva both offer a word list that makes specified terms more likely to be recognised, and Riva’s boosting can add words the model has never seen.

TechnoLynx starts this work by setting a target word error rate on representative audio from your own programmes. TechnoLynx then sorts the errors into name and term misses versus acoustic failures before choosing glossary injection, decoder fine-tuning or both. TechnoLynx delivers the build and its validation through its Generative & Agentic AI R&D offer.

Names fail for a structural reason. End-to-end models struggle most with words they rarely or never saw in training, and standard shallow-fusion biasing does not fully fix that. A 2025 study on TV series gives a familiar example: a model wrote “Joey Tribbyany” because it lacked the world knowledge to infer an uncommon, context-dependent spelling.

The main glossary mechanisms work as follows:

• Vocabulary tables. Amazon Transcribe prefers a four-column table (Phrase, SoundsLike, IPA, DisplayAs), so one entry can carry both how a name sounds and how it should be spelled on screen. Each vocabulary file is capped at 50 KB, with up to 100 files per AWS account.
• Request-time boosting. NVIDIA Riva’s word boosting extends the vocabulary at inference time and has to be sent with every request. NVIDIA describes it as the quickest adaptation and a temporary fix, while custom vocabulary and lexicon mapping are the permanent route.
• Lexicon-bound decoders. Riva’s default Flashlight decoder only emits words that are in its vocabulary file, so a name missing from that file can never appear in the transcript.
• Phrase sets and classes. Google Cloud Speech-to-Text biases recognition through phrase sets and custom classes of related items, such as a list of rare proper names.

Boosting has a cost. Google documents a practical maximum boost of 20 and warns that higher values reduce missed terms but increase false positives, meaning the term appears in the transcript when it was never spoken. Riva suggests starting at a boost of 20, going up to 100 if needed, and searching for the weight while tracking both WER and a term error rate on a test set. A 2026 study adds that a model nudged towards domain terms can transcribe a phonetically similar context word in place of what was actually said.

Choosing an adaptation route for show-specific terms

Route	What it fixes	What it needs	Main risk	How it is updated
Word boosting / phrase biasing	Names and rare terms at request time, including out-of-vocabulary words (Riva)	A term list sent with each request	False positives as boost rises	Edit the list per request
Custom vocabulary / lexicon	Recognition, pronunciation and display form of specific terms	A term table with pronunciations and display forms	Size limits	Edit the file; a Riva lexicon change takes effect after a server restart
Custom language model	Terms in context, homophones, domain phrasing	A large volume of domain text	Needs text you may not have for a new title	Retrain and interpolate with a general LM
Acoustic fine-tuning	Accents, noise, poor audio quality	Roughly 10 to 100+ hours of transcribed domain audio	Catastrophic forgetting on small datasets	Retrain for new terms

A custom language model is the step up when the errors are about context, such as homophones. Amazon positions vocabularies for brand names and acronyms, and custom language models for technical terms and homophones, saying the latter can give significant accuracy improvements over vocabularies alone. A 2022 study on UK Supreme Court hearings built a custom language model from 3.26 million tokens of written judgements and about 81 hours of gold-standard transcripts. It reported a 9% WER improvement over AWS Transcribe’s base model and 8% over Whisper, with about a 9% average improvement when its extracted phrase list was added. Separately, a 2020 study on Singapore street names reported that expanding the lexicon with out-of-vocabulary words improved WER by around 7%. For a series, the text corpus would come from scripts, earlier subtitles and production notes, and we would check its coverage of the current season before relying on it.

Acoustic fine-tuning is the last step, for when easier approaches fall short. NVIDIA’s Riva guide puts acoustic fine-tuning at 10 to 100 hours of transcribed domain audio. The same guide elsewhere recommends about 100 hours or more for accent and noise problems, and several hundred hours before fine-tuning at all, with language model adaptation as the alternative when that much data does not exist. We read the larger figures as the safer planning number, because the guide also warns that a dataset of around 10 hours risks catastrophic forgetting unless it is mixed with a larger base set. NVIDIA recommends fine-tuning the Conformer model rather than Citrinet for streaming recognition. Parameter-efficient methods such as LoRA train a small set of added weights instead of the whole network. Whether that limits forgetting on your audio is something to measure on held-out episodes, not to assume.

How to choose follows from where the errors cluster. If most errors are proper nouns and jargon, favour a glossary over retraining, since fine-tuning is expensive and has to be redone for new terms. If the errors follow accents or noisy scenes, the vocabulary will not reach them.

Measuring word error rate on your own programme mix

Build a test set from your own final mixes with reference transcripts, and compute WER over the whole set, not per clip. WER counts substitutions, deletions and insertions against the reference and divides by the number of reference words, with all four totals summed across the test set before dividing. Normalisation changes the score a lot. In Hugging Face’s audio course, one baseline scored 168% WER on raw text and 126% once both references and predictions were normalised. So freeze the normalisation rules (casing, punctuation, how glossary spellings are matched) before comparing any two systems.

Overall WER will barely register a glossary. In a 2022 study on contextual biasing, raising the bias weight with CTC decoding took rare-word recall from 22.5% to 41.8% while overall WER moved from 13.23% to 13.64%. The authors explain why: the bias terms are a small share of all words, so recall on those terms better reflects what users experience. Track a named-entity error rate (errors on name segments divided by names in the reference) alongside WER.

Public leaderboards are a weak guide to robustness on your mix. The authors of a 2026 benchmark argue that leaderboards built on a few open datasets reward overfitting to those datasets, which they call benchmark optimisation. Speech Robust Bench found that the top model on the Open ASR Leaderboard ranked fifth on its robustness tests. Choosing between candidate models on your show’s audio is its own benchmarking-methodology question. This page is concerned with the adapted pipeline you end up running.

A per-condition test set takes five steps, in order:

1. Sample clips from final broadcast mixes, not stems or studio takes, across the episodes and scene types the season contains.
2. Tag each clip by condition: accented speech, expressive delivery, music or noise under speech, and conversational speech.
3. Hold out whole episodes that adaptation never touched, so overfitting to the training corpus shows up.
4. Report corpus WER per condition, a term error rate for the glossary, and the inverse real-time factor, since live captioning needs faster-than-real-time processing.
5. Rerun the same set before each season’s captioning run starts and after every glossary or model change.

Punctuation and capitalisation are a separate matter, which Riva handles with a dedicated model. Treat those as their own acceptance checks. Our piece on stratified evaluation across conditions, sites and hardware explains why a single blended figure hides exactly these gaps.

How much worse is ASR on accents, overlapping dialogue and music?

Expect a lot worse, and unevenly so across conditions. On the Edinburgh International Accents of English Corpus (2023), the best model tested averaged 19.7% WER, against 2.7% on clean read US English, with the largest drops for Indian, Jamaican and Nigerian English speakers. RW-Voice-EQ Bench tested accented, emotional, noisy and conversational speech separately. No single system led on all four, and strong clean-speech results did not predict robustness. The same benchmark found positive high-arousal speech (laughter, excitement) harder to transcribe than negative high-arousal speech by 3.25 to 5.14 percentage points across its top ten systems.

Speaker characteristics move error rates too. One audit found raw WER less sensitive to speaker and acoustic factors than semantic metrics such as EmbER and SemDist.

Overlap is a known problem for both ASR and diarization. In the CHiME-6 challenge, the JHU team reported 5% to 8% improvements from guided source separation and overlap-aware diarization, because those steps separate the overlapped speech before recognition. If overlap dominates your errors, separation and overlap-aware diarization ahead of the recogniser address it. Then measure both speaker-attributed and speaker-agnostic WER, since the gap between the two isolates errors caused by diarization. For music and effects, Riva notes that adding background noise to training data can lower accuracy at first but improves robustness. There is also a video-guided post-ASR correction option for TV. A video-guided correction method needed no retraining and cut WER by 7.64% relative on a Conformer RNN-T model.

Keeping the custom vocabulary current as each season adds names

Treat the glossary as a versioned pronunciation lexicon wired into the engine’s own biasing or lexicon interface. That way a new season’s names arrive as additive edits, not retraining: a lexicon edit or boost list takes effect without touching the model, while fine-tuning would have to be redone for each new term.

TechnoLynx builds this as a workflow around your specific ASR engine. It covers intake, review and merge steps tied to the engine’s lexicon, a regression check that new entries help the new season without hurting earlier episodes, and a packaged template that other titles can reuse.

The format question has a standard answer. The W3C Pronunciation Lexicon Specification defines a lexeme that can hold several spellings and several pronunciations, and an ASR processor must accept every listed pronunciation as valid. That suits names the cast says one way and the narrator another. The specification is designed to be interoperable across ASR and TTS engines. Even if your engine wants its own table format, that makes it a sensible master copy to convert from.

A season update runs in a fixed order:

1. Log new names and places from scripts and production documents before the episodes air.
2. Write pronunciations for each entry. In a study of hybrid ASR on Singapore street names, graphemic lexicons performed comparably to phonetic ones and were much easier to build and extend. Have a person check how the cast says each invented name.
3. Check each new entry against existing ones for near-homophones, since context-word leakage is slightly higher for phonetically closer pairs.
4. Merge into a new lexicon version, rerun the per-condition test set and the term error rate, and keep the previous version to roll back to.
5. Retire entries that no longer appear. A proposed dynamic-vocabulary strategy that adds and removes words showed a general positive tendency in WER.

If the backend has no dynamic biasing, the fallback is a periodic language model rebuild with the season’s text, which Riva supports through n-gram language models trained for the domain. That is slower to turn around, so plan the rebuild into the pre-season schedule. Scaling human review of captions across languages and episodes is outside the scope of this lexicon work.

Can one glossary serve several shows?

There is little direct evidence on this, so what follows is judgement. In our view the structure transfers well and the content transfers poorly. Categories (characters, places, factions, invented objects), pronunciation conventions and the review workflow can serve any title with similar naming habits, while the entries themselves belong to one title. Merging two shows’ names into one list also brings back the collision problem from step 3.

Who can adapt and validate an ASR pipeline for our programmes?

TechnoLynx adapts speech recognition to a show’s names and audio and proves it on your own mix: diagnosing where errors come from, choosing between glossary injection, decoder fine-tuning or both, building it for streaming latency on your hardware, and validating with per-condition WER and term error rates. Building in-house makes sense when you have ASR engineers and hand-transcribed reference audio. A specialist pays off when the error profile is mixed, or when the pipeline must meet live-captioning latency. When comparing partners, ask how they will measure success on your audio, not on a leaderboard. TechnoLynx runs this work through its Generative & Agentic AI R&D offer.

An engagement like this is the wrong fit if a managed service’s built-in vocabulary feature already fixes your names, or if what you need is caption review staffing. For GPU sizing and latency budgets behind a streaming deployment, LynxBenchAI measures throughput, latency and memory across accelerators; it does not measure your show’s word error rate. TechnoLynx’s wider media work sits under AI engineering for media, broadcast and telecom.

Does a web AR overlay work the same on an old Android phone as on the latest iPhone?

No, not by default. Safari on iPhone and iPad has no WebXR support at all, Android Chrome provides AR through ARCore hit-testing, and Android AR requires an ARCore-supported device. Consistency has to be verified on the target devices themselves.

TechnoLynx handles this as deployment work under the AI Porting & Deployment Pack. TechnoLynx defines the device and browser matrix from your audience analytics, runs the overlay on those devices, validates tracking, frame rate and failure modes per combination, and puts fallbacks and ongoing regression testing in place.

Web AR opens in three different ways. With WebXR, the device’s own AR mode does the tracking, which is accurate and light. With camera-feed processing, the page itself looks for markers or faces, which works without device AR support but uses more battery and runs hotter. With the system AR viewer, the page hands over a USDZ file on iPhone or a GLB on Android. Android phones fail for hardware and software reasons: Google certifies ARCore devices on camera quality, motion sensors and CPU performance for real-time work, and AR placement on Android depends on Google Play Services for AR. Browsers embedded inside messaging apps do not open WebXR either, which is easy to miss when links are shared socially.

Which combinations fail changes as browsers ship updates. One support table is dated 2 October 2026 and its authors advise checking again before anything important depends on it; another tells you to verify against the target device before committing to a launch date. MDN is blunt that emulated, simulated or polyfilled environments are no substitute for testing on physical hardware. Per combination, record whether tracking holds, the frame rate it sustains and how it fails. Whether marker or QR triggering survives in-store lighting is a separate robustness question from browser support.

When does a web AR experience need a fallback?

Almost always, for a broad audience. iPhone users have no WebXR, so any experience meant to reach everyone needs a real fallback strategy, not an afterthought. The robust pattern runs in order:

1. Check support in JavaScript with navigator.xr.isSessionSupported('immersive-ar') before showing any AR button; a false result means the device or browser genuinely does not support it.
2. Use WebXR where it opens.
3. Hand the model to the system AR viewer where WebXR does not open; Google’s <model-viewer> falls back to Scene Viewer by default on ARCore-supported Android devices.
4. Offer an AR Quick Look link with a USDZ file for iPhone, outside the WebXR code path.
5. Keep a polished, non-immersive 3D view as the default, because most visitors will see it.

Write honest messaging for each path. A “View in AR” button that silently fails is worse than offering no AR at all.

The speech glossary and the device matrix fail in the same way: both are accurate on the day they are validated and drift as the show adds names and the audience changes phones. The engineering question to settle up front is who reruns the test set and the device pass, and on what trigger: a new season, a lexicon change, a browser release. Without that, last season’s accuracy figures quietly stop describing the system on air.

FAQ

What is a good word error rate?

NVIDIA estimates human-level accuracy at above 95%, meaning under 5% WER, and notes that some domains need accuracy closer to 99%. A good figure for captioning is one that holds on your hardest condition, not only on clean dialogue.