PixVerse: a speaker id, passed on the lip-sync request
A speaker id returned by the voice list travels on the lip-sync request beside the text to be read. It is short, stable and easy to keep, and nothing published says it belongs to a character rather than to a call. From 3 source pages, read 2026-10-25; no maker pays to be listed.
| What the documentation settles | What it leaves to a take |
|---|---|
| A speaker id taken from the TTS list is passed on the lip-sync request, beside the text | Whether a custom speaker id persists between projects |
| A custom voice is created from an uploaded audio resource, and the call returns its speaker id | Whether a custom id is versioned when the recording changes |
| The speaker list returns built-in voices and the account's custom voices | How a scene with two speakers keeps each one across calls |
Inclusion rule. Only statements found on the vendor page named in the caption, and only ones bearing on this one field. Nothing here is filled in from generated output. Order. In the order the statements arrive on the vendor's page.
1The id sits in the lip-sync request itself
Most entries that pass a voice describe it as a voice. Here the id is a field of the lip-sync call, so the same identifier decides who is heard and whose mouth is moved. In a shot with two figures that is exactly the pairing a production wants made explicit.
It is also a limit. One speaker id per request suggests one speaking part per generation, which pushes a conversation into alternating calls rather than a single two-hander.
2A stable id with no stated lifetime
An id is a much better basis for consistency than a clip, because it cannot drift. What is missing is any statement about how long it lasts, whether a custom voice can be edited, and whether editing it changes the id or the voice behind it. The reference also offers a call that deletes a custom voice, which makes the lifetime something the account controls and the page does not describe.
For a production the cheap habit is to treat an id as immutable: never re-point one at a new sample, always create another. That keeps the record honest even where the platform makes no promise.
3The others that re-establish the voice on each call
Four more entries put the voice on the request. Two pass audio, which can drift; this one and two others pass an identifier, which cannot.
- Per-character bindingA speaker id taken from the TTS list is passed as the lip-sync speaker id on the request, beside the text to be reada speaker id per call
- Voice sourceThe speaker list returns the built-in voices and the account's custom voices, and can be filtered to either kindcatalogue or supplied sample
- Voice sourceA custom voice is created from an uploaded audio resource, and the call returns a speaker id for ita supplied sample
4Voices in a drama pipeline
For the speech side of “PixVerse, per-character binding”, SceneMixer's guides describe how lines are spoken:
Lip sync is the default: the picture stays frame for frame, every line is voiced again and the mouths are moved to match; the original ambience is dropped.
SceneMixer, Lip Sync or Re-perform: Choosing How to Redub a Clip (read 2026-10-13)
A line lives inside the shot where it is spoken, in four parts: the speaker chip, the delivery note in round brackets, the words after the colon, and the voice chip after the words.
SceneMixer, Dialogue in the Storyboard: How to Write a Line, and What Save Tidies Up (read 2026-10-13)
5Sources
Read from the lip-sync reference and voice pages at docs.platform.pixverse.ai on 2026-10-25. The same column across every entry is on per-character binding; everything this vendor publishes about speech is on PixVerse. What counts as documented is on how read.