Entries that name lip-sync and leave the driver out
Four entries name lip-sync and stop. One puts it in a translation sentence, one in the name of an endpoint, one as a capability of the model, and one only in a warning about where it stops holding. As of 2026-09-22.
| Model | How the claim is made | And what holds a voice to a character |
|---|---|---|
| HeyGen | Named, alongside translation | On a stored clone |
| Kling AI | Named, with nothing driving it | On the element |
| PixVerse | Named as the endpoint's purpose | On the request |
| Sora 2 | Named only where it fails | On the prompt |
Inclusion rule. Entries whose documentation names lip-sync, or names where it fails, without naming what the mouth follows. Entries with a named driver are on a separate route page. Order. Alphabetical by model name.
1Three mechanisms, three visibly different artefacts
Sound and picture made together tends to produce soft or approximate movement. Animating to a supplied track produces tight movement on a face that may not match the rest of the shot. Repairing afterwards produces a mouth that can look pasted on. A claim that names none of these predicts none of them.
That is why the register grades a driver above a feature. The grade is about how much a reader can plan from a sentence, not about how good the product is, and a well-aligned model with a thin page lands in this group.
2One of these names only the failure, and that is more useful
A warning that long, complex speeches are unlikely to sync tells a writer to break a speech into exchanges. It is not a mechanism, so the field stays unstated, and it is the most actionable sentence in the group.
Being told where something stops working is often worth more than being told that it works. It converts directly into a rule for a shot list, which a capability claim never does.
3An endpoint name is the weakest claim of the four
A product can call an endpoint whatever it likes. Treating the name as documentation would put it on the same footing as a described mechanism, and the two cannot be compared because a name cannot be tested.
That entry does pass a speaker id described as the lip-sync speaker, which at least identifies whose mouth is involved. Half of the two-speaker problem answered by a routing detail is still more than the other three manage.
4The entries on this route, one page each
Each of these links to that entry on the field this route groups by. The wording behind every cell, and the date it was read, sits on the page it links to.
- HeyGen — named, alongside translation.
- Kling AI — named, with nothing driving it.
- PixVerse — named as the endpoint's purpose.
- Sora 2 — named only where it fails.
- Lip-syncLip-sync is documentedstated without a mechanism
- LanguagesVideo translation is documented for thirty or more languages, with voice cloning and lip-synccounted on the translation endpoint
- Per-character bindingThe chosen speaker id is passed as the lip-sync speaker on the generation requesta speaker id per call
- Dialogue timing against clip lengthA four-second shot is said to accommodate one or two short exchanges and an eight-second clip a few more, with long speeches unlikely to sync
- Per-character bindingVoices are bound to elements, so a character carries its voice between generationstied to the element system
5Sources
Membership of this route is decided by the wording in the field it groups by, read from the documentation each vendor publishes. The column itself is on the field note, all five columns are on the speech table, and what counts as documented is on how read. Other routes: The subject skipped, Sound in the same pass.