Vendor decks for AI dubbing all look similar: large language counts, natural-sounding demo clips, and turnaround claims measured in minutes. The problem is that most of the failure modes only appear after signing, when your legal team asks who consented to a cloned voice, when a two-person interview comes back with one voice, or when the "supported" language turns out to support subtitles but not speech synthesis.
This AI dubbing procurement checklist works through ten claims that deserve verification before contract, using Ollang as the working example. Ollang publishes more of its dubbing architecture than most vendors, order styles, provider routing, deliverable classes, and API behavior are documented, which makes it a useful case for showing the line between what a buyer can confirm from vendor materials and what still belongs in a contract or a proof-of-concept test.
Do Not Equate Platform Language Coverage with Dubbing Coverage
Claim 1 to verify: "We support N languages" means "we can dub in N languages."
Ollang states that its enterprise platform supports 240+ languages and dialects, including right-to-left scripts, and its API publishes an extensive language list for translation and transcription. Those are verified statements about the platform. What Ollang does not publish is a matrix showing which of those languages support speech generation, voice cloning, or lip sync, or which voice providers cover them. Its separate live dubbing product claims 30+ language pairs, a materially different number.
This gap is not unique to Ollang; it is the single most common procurement trap in this category. Translation coverage is cheap to extend. Natural-sounding synthetic voices in a given language are not.
Claim 2 to verify: every stage of the pipeline works in your target languages.
Ollang's dubbing pipeline runs transcription, translation, speech synthesis, optional human review, QC, mixing, and delivery, and it routes speech synthesis through configurable providers, its documentation names ElevenLabs, Gemini TTS, and Azure TTS as examples. That multi-provider design is an advantage: if one provider lacks a voice for a language, another may cover it. But it also means coverage is provider-dependent. Ask for a written language matrix broken down by capability, TTS, cloning, lip sync, human review availability, for your specific target list, and attach it to the contract.
Clarify What Lip Sync Changes
Claim 3 to verify: what "lip sync" actually modifies.
Ollang's API exposes lipsync as a distinct dubbing order style, separate from overdub and audioDescription, and states that dubbing can produce a mixed video with optional lip sync. That is a real, documented product distinction, and it matters operationally: you select the style at order creation, per language, rather than negotiating it as a bespoke service.
What Ollang's documentation does not establish is whether lip-sync mode times the generated audio to the source performance, visually modifies mouth movements in the video, or supports both. An Ollang article describes phoneme mapping and neural synthesis for mouth alignment in general terms, and, notably, warns that fully automated lip sync remains imperfect for high-visibility work and may need human refinement.
For a buyer, the difference is not academic. Audio-timing alignment and visual mouth modification carry different quality risks, different rendering costs, and different talent-rights implications. Have the vendor demonstrate lip-sync output on your own footage, in your target language, and define in the statement of work exactly what the mode changes.
Test Multi-Speaker and Overlapping Dialogue Scenarios
Claim 4 to verify: automatic voice assignment per speaker.
Ollang documents speaker management in its editor and lists WhisperX, which provides speaker diarization and segmentation, among its available speech-recognition options. So the platform can identify who is speaking and lets editors manage speaker assignments and timing at the segment level, then rerun synthesis on just the corrected segments. That segment-level resynthesis is worth noting on its own: it means a misassigned speaker is an edit-and-rerun fix, not a full reprocessing job.
What the documentation does not confirm is that every dubbing workflow automatically assigns a distinct target voice to each detected speaker, or that a speaker's cloned voice is preserved automatically across an episode or a season.
Claim 5 to verify: overlapping dialogue handling.
No vendor claim here should be accepted without a test. Ollang's materials do not document overlapping-dialogue behavior, and this is where most AI dubbing pipelines degrade. Build a test reel: crosstalk, interruptions, a panel discussion, background speech under a narrator. Run it during evaluation, not after go-live.
Claim 6 to verify: cast consistency across episodic content.
Ollang supports bulk upload for episodic libraries and multiple language-specific orders per project, which is the right structure for series work. Whether voice-to-character mapping persists across episodes without manual intervention needs confirmation. If you localize series, make long-form consistency an explicit acceptance criterion.