PixVerse and D-ID: one id, two supply chains

Two entries put an identifier on every generation. One passes a speaker id covering both built-in voices and custom ones made from an uploaded recording. The other passes a voice id drawn from five named speech providers. From 4 source pages, read 2026-09-22 to 2026-10-25; no maker pays to be listed.

Inclusion rule. Two entries are given a page together when at least one column puts them at opposite grades of answer. Pairs that agree on every column, or that are both blank throughout, do not get a page. Order. Fixed field order, identical on every side-by-side page.

1A stable id is most of what persistence needs

Neither platform holds a pairing between a character and a voice, and neither needs to for the voice itself to stay put. An id cannot drift, so a production that writes it down gets consistency without storing audio anywhere.

What neither offers is a check. Passing the wrong id for a character produces a perfectly valid call and a different person, and nothing in a returned file records which id spoke. The shot list is the authoritative record either way.

2Where the ids come from changes the dependency

One platform's ids are its own, covering a catalogue it controls and voices a user made from a recording. The other's belong to five outside services, each with its own deprecation schedule, licence terms and language codes.

Five suppliers is a wide net and a wide surface. A voice withdrawn upstream takes a character with it, and the talk reference is not the document that would announce that.

3One id also decides whose mouth moves

One of these puts its identifier on the lip-sync request itself, which quietly says the same handle governs the voice and the face. That is half of the two-speaker problem answered by a routing detail.

The other never mentions a mouth. Two products passing what looks like the same field, and only one of them has said what the field does to the picture.

4Each of them on its own

The column this pair was chosen for is per-character binding, and each entry has a page of its own on it. The full row for either, all five columns with the wording behind each cell, is on its model note.

• PixVerse on per-character binding — on the request.
• D-ID on per-character binding — on the request.
• PixVerse, all five fields — read from the lip-sync reference and voice pages.
• D-ID, all five fields — read from the create a talk reference.

5Where PixVerse and D-ID part, a third entry's answer

Inclusion rule. The columns on which the two entries above give different answers, each with SceneMixer's answer from its own model note. Order. Fixed field order, identical on every side-by-side page.

• Per-character binding
  A 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 callPixVerse, Lipsync reference / recorded 2026-10-25
• Voice source
  The speaker list returns the built-in voices and the account's custom voices, and can be filtered to either kindcatalogue or supplied samplePixVerse, Get TTS Speaker List reference / recorded 2026-10-25
• Voice source
  A custom voice is created from an uploaded audio resource, and the call returns a speaker id for ita supplied samplePixVerse, Create Custom Voice reference / recorded 2026-10-25
• Per-character binding
  The voice is a voice id selected from the list of available voices, with an optional language field beside ita voice id on every requestD-ID, create a talk reference / recorded 2026-09-22
• Voice source
  Five speech providers are named for the voice: Microsoft, ElevenLabs, Amazon, Google and Azure OpenAIoutside catalogues named on the pageD-ID, create a talk reference / recorded 2026-09-22

6Sources

Every cell above is read from the documentation each vendor publishes, on the dates carried by the two model notes. The whole register on one column is on the field note; entries grouped by the shape of their answer are on the routes. Other pairs: Sora 2 and Wan 3.0, Runway and Luma Ray.