How a field here gets filled in

Five fields per model, the same five for everyone: audio source, languages, what a voice can be built from, how one attaches to a character, and lip-sync. Every field comes from the vendor's own documentation. Nothing is inferred from generated output. As of 2026-09-22.

Fig. 1 Filling a cell by listening would produce a finding about one clip. The cells here are meant to be about the product, so they come from documents.

1Why nothing is filled in from output

It would be easy to generate a clip, hear a voice, and write down that the model supports voices. It would also be worthless: one clip is one sample from a stochastic process, and the next clip can differ without anything having changed. A register built from samples would record the sampling, not the product.

So a field is filled only when a vendor states the thing in its own documentation. That makes several cells here read as not documented for products that plainly do the thing, and the absence is the finding. A vendor that documents nothing has left the buyer to discover the behaviour after committing to the tool, which is the opposite of what documentation exists for.

2What the five fields mean

Audio source separates audio generated together with the picture from audio handed to the model or added in a later pass. The distinction matters because the first arrives aligned and the second has to be aligned to something.

Voice source records what a production may hand over so speech follows a chosen voice: a catalogue entry, a clone enrolled from a recording, a clip on the call, or a description in words. Where a vendor publishes seconds and megabytes, those are recorded as published.

Languages records a list where a vendor publishes one and a count where it publishes only a count. A count is not rounded up into a list.

Voice per character records how a voice attaches to a person on screen: bound to a reusable character object, supplied per call as reference audio, or chosen from a library. These are different workflows with different failure modes, so they are written out rather than reduced to yes and no.

Lip-sync records what the vendor says drives the mouth. A claim that lip-sync exists is recorded as a claim; a described mechanism is recorded as a mechanism; the two are not merged.

3Dates and corrections

Every field carries two dates: when it was first logged and when the documentation was last read again. Reading it again and finding it unchanged still advances the second, because on this subject the common failure is not a wrong answer but an answer nobody has revisited since a model shipped.

Page dates follow content and not builds. Where a vendor now documents something other than what is logged here, the documentation is the record and the field is relogged.

4Voices in a drama pipeline

For the speech side of “How read”, SceneMixer's guides describe how lines are spoken:

SceneMixer writes dialogue into the script analysis, assigns each line to a shot with a speaker and a short delivery note, and the video model performs it — picture and audio generated together, so the mouth forms that sentence in the language you chose.
SceneMixer, AI Dialogue Generator (read 2026-10-13)

A SceneMixer segment comes out with its sound already in it: each line spoken in that character’s voice, the speaker’s lips moving with the words, and the ambience of the place — rain, traffic, a clock.
SceneMixer, Dialogue and Sound in One Generation (read 2026-10-13)

How the register is kept. The tables, counts and rankings on this site are computed by script from the register, and every figure links to the page it was read from, with the words quoted. No maker pays to be listed or to change a place, and each ranking states its rule, written before the places were computed. Entries are not edited at a maker's request: a figure that is out of date is fixed on the maker's own page and picked up when the pages are next read, at least every three months.