Skip to main content
Glama

Dub Sequence

lab_dub

Dub a sequence into another language: either a ready audio track (en_audio_url — e.g. the one lab_dub_tts just produced) OR a cloned voice reading a line of text (voice_id + dub_text), then a controlled visual lipsync runs over the sequence's own footage (ROI-crop + composite for a long static talking-head shot, or the full-frame veed_v2 path for multi-shot sequences and shots where the mouth is partly hidden). ASYNCHRONOUS: returns a job_id immediately: poll lab_job_status until it completes. Needs a cloned voice first — lab_voice_clone makes one, lab_list_voices shows what a project already has.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seq_idYesSequence id (from lab_create_sequence/lab_list_sequences) — positive integer as string
backendNoLipsync engine. Omit to use the backend default (replicate — ROI-crop, best for one long static talking-head shot). veed_v2 renders the full frame instead and is the pick for multi-shot sequences or a partly hidden mouth. 'inhouse' shares replicate's ROI-crop path.
dub_textNoThe line(s) this cloned voice should read, in the target `language`. Required together with voice_id.
get_costNo`true` reports the price and your balance WITHOUT starting a dub and without spending quota. The number is computed by the same function that later charges you, from THIS sequence: a sound rate per video clip, plus the chosen lipsync engine's own rate over the sequence's running time, plus a surcharge for the cloned-voice reading. `preisbasis` in the answer breaks it into those parts, so you can see which switch moves which share — turning the lipsync pass off removes its whole item. Not drawn from the lab_list_models catalog (that covers image and video models only; the lipsync engine is chosen with `backend` here, and dub has no catalog entry).
languageYesTarget language for the dub, e.g. 'de', 'fr', 'es' — drives the cloned voice's TTS. Required: there is no silent default here.
voice_idNoA cloned voice's id (lab_cloned_voices.id, from lab_voice_clone or lab_list_voices) — positive integer as string. Required together with dub_text, and mutually exclusive with en_audio_url.
einwilligungNoConsent of the person whose mouth this dub re-syncs, when there is no Likeness Register id for them yet. Required together with einwilligung_notiz if likeness_ref is not given — a dub always alters a real person's mouth in existing footage, so one of the two consent forms is mandatory, checked before anything is spent. This is a caller attestation, not a registry check like likeness_ref — logged, not verified against likeness.thefilmradar.com. Do not set it to be rid of the error — set it because the consent exists.
en_audio_urlNoURL of a READY dub track to lay under the sequence — typically the audio_url lab_dub_tts just returned. Mutually exclusive with voice_id+dub_text: a dub has exactly one audio source, and picking one silently would throw away the other after it was paid for.
likeness_refNoA Likeness Register consent id (likeness.thefilmradar.com) for the person whose mouth this dub re-syncs. Checked live against the register before anything is spent; a revoked or unknown id refuses the call. Mutually exclusive with einwilligung+einwilligung_notiz — one form of consent is required, not both.
enable_lipsyncNoWhether to run the visual lipsync pass at all. Omit to use the backend default (on). Off only swaps the audio track and skips the mouth-sync render entirely.
einwilligung_notizNoFree text: who consented, when, and for what — required together with einwilligung. Goes on record with the generated clip.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the real burden and does: it flags ASYNCHRONOUS behavior with an immediate job_id, the mandatory consent prerequisite checked before spend, and the fact that a dub always alters a real person's mouth. It also notes mutually exclusive audio sources and that a choice is not made silently because the other option may already have been paid for.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and the two input modes, then async behavior and prerequisites — a sensible ordering. It is dense but mostly earns its length; the main waste is that the backend ROI-crop/veed_v2 explanation largely restates the schema's own backend description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with no output schema, the description covers the lifecycle (async job_id then lab_job_status), the cost/quota implications, the consent requirement, and the audio-source decision. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the per-parameter descriptions are already very rich, so the baseline would be 3. The description adds integration-level semantics the schema states only in isolation — the two mutually exclusive audio paths, backend selection heuristics, and that the voice/consent parameters gate each other — which meaningfully helps an agent assemble a valid call, though it does not introduce new syntax or formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Dub a sequence into another language') and immediately clarifies the two input modes (ready audio track vs cloned-voice text). It distinguishes itself from siblings by name, notably lab_dub_tts (which just produces audio) and the async job flow, so an agent can tell them apart without opening the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit branch conditions: use en_audio_url when a track already exists, use voice_id+dub_text for a clone reading; pick ROI-crop/replicate for one long static talking-head shot and veed_v2 for multi-shot or partly hidden mouths. It also states prerequisites (need a cloned voice first, via lab_voice_clone/lab_list_voices) and the follow-up step (poll lab_job_status).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources