A QA Checklist for Dubbed Video Before You Publish

A dub can pass every individual check and still be wrong, because the faults that matter are cumulative or contextual. It can also fail a check that took thirty seconds to run after somebody spent an hour reviewing the language, which is a waste of the one resource in this process that is genuinely scarce.

Both problems are solved by ordering. Cheap, mechanical checks that invalidate everything downstream go first. Contextual checks that require watching the whole thing go in the middle. The native speaker goes last, on material already known to be sound. This guide is that order, with eighteen checks grouped by who can run them.

Stage One: Mechanical, No Language Needed

These take minutes and each one can invalidate everything after it.

Check one is the one that gets missed, and it is the most expensive to discover late. A dub produced against a cut that was subsequently revised will be correct in every line and wrong throughout, and no amount of reviewing the language will reveal it. Confirm the version before anything else.

Stage Two: Sync and Sound

Still no target language required. These need the video playing.

Checks seven and eight together diagnose the most common structural fault in one minute. If the beginning is clean and the end is not, the problem is placement method rather than any individual line, and it is fixed by anchoring — described in why dubbed audio drifts out of sync.

Check eleven is worth doing on headphones. Time-stretch artefacts are audible there long before they are on speakers, and they are the fault most likely to survive into publication.

Stage Three: Content, Verifiable Without Fluency

These need the glossary and the script, not the language.

Check seventeen catches a failure that is invisible in an audio-only review and obvious to a viewer. Where the video contains any text at all — a title, a label, a figure — someone has to watch the dub and confirm the two agree. This is also where a video with text burned into the picture shows its cost, because the graphic is still in the source language.

Stage Four: The Native Speaker

One check, and it takes the runtime.

18. A fluent speaker watches the whole video, in sync, without pausing.

The reason this is one item rather than a list is that the faults it finds are not enumerable in advance. Register that drifts formal, a sentence that is technically correct and nobody would say, a term that means something slightly different in this field, a joke that landed as odd. None of these appear in a document review, and none appear in a spot check.

Two conditions make this check work. The reviewer watches rather than reads, because the picture resolves ambiguity that text does not. And they watch continuously, because register and naturalness are cumulative impressions.

Brief them on what to report: not just errors, but anywhere the speaker sounds like a different person from the original, and anywhere a sentence made them pause.

Running It Across Several Languages

The order matters more, not less, when there are eight versions.

That last point connects to the tracking discipline needed across a multi-language set, which is set out in managing subtitles in eight languages without losing track.

Fixing in the Right Order Too

Finding faults in a sensible order is only half of it. Fixing them out of order is how a QA pass turns into three QA passes.

The dependency is the same one that governs the pipeline. A change to the translated text means the audio has to be regenerated, which means the timing has to be redone, which means the sync checks have to be run again. A change to the mix affects nothing upstream.

So group the findings before acting on them. Everything requiring a text change goes together and is applied in one pass. Everything requiring re-timing goes next. Mix adjustments go last, because nothing depends on them.

The temptation to fix each fault as it is found is strong, particularly when the list is short, and it reliably produces the situation where line forty has been re-timed twice because two separate text corrections arrived after it.

One further note on re-checking. After a text change and regeneration, the mechanical checks in stage one have to be run again on the new file — not because they are likely to fail, but because a regeneration is a new export and exports are where truncation and encoding faults appear. Re-running six quick checks is cheaper than publishing a corrected file that is broken in a different way.

What This Cannot Catch

Two things survive the whole list, and both are decided upstream.

A translation that is fluent, natural and subtly wrong about what the video meant will pass every check here, because the reviewer is checking the target language against itself rather than against the intent. Guarding against that means the reviewer needs the source too, at least for the sections where accuracy matters most.

And a dub that is fine and simply should not have been made — where the speaker's own voice was the reason to watch — is not a quality problem at all. That belongs to a decision made long before production, weighed in the per-market choice between dubbing and subtitles.

Who Signs It Off

A checklist with no owner produces the same result as no checklist, and localisation is particularly prone to this because the work is distributed.

Name one person accountable for each language version reaching publication. Not the translator, not the reviewer — someone whose job is confirming that the list was run and the faults were fixed. In small teams this is the same person for every language; in larger ones it should still be one person per version rather than a shared responsibility.

The reason is specific to this workflow. A dub passes through several hands, and each one reasonably assumes someone else checked the parts outside their remit. The translator assumes the timing was verified; whoever placed the audio assumes the language was reviewed; the person publishing assumes both. Faults survive in exactly those gaps.

Give that person the completed checklist rather than a verbal confirmation. A document showing which checks were run, by whom, and against which source version is what makes a later question answerable, and it takes no longer than saying it was fine.

Next Steps

Take a dub you have already published and run stage one on it. Confirming the source version alone takes two minutes, and it is the check most likely to find something.

Then set up the list as a shared document with a column per language, and use it before the next release rather than reconstructing the checks from memory. For the five stages these checks are auditing, see the dubbing pipeline stage by stage; everything else is on the dubbing hub.