CometAPI video trials: preserve the audio starting point before choosing a route

General
1

Before comparing Wan 2.7 and Vidu Q3 through CometAPI, make one field in the trial brief explicit: does this job start with an audio asset, or does it ask the model to generate dialogue and sound? A route that produces audio is not necessarily a route that accepts the audio you already have.

CometAPI’s Wan 2.7–Vidu Q3 comparison, published August 23 and checked September 6, 2026, describes a shared video endpoint, authentication pattern and asynchronous job lifecycle. That is useful integration context. It does not establish that the two CometAPI routes expose identical audio inputs or every control available in the models’ native APIs.

Two briefs, not one interchangeable request

The article describes Wan’s native workflows as supporting custom audio as well as automatic audio generation. It positions Vidu Q3 around video, dialogue/voiceover, effects and music generated together. Those descriptions suggest two different starting points for a CometAPI trial—not a blanket model ranking:

Job brief What to establish before submitting through CometAPI Proposed acceptance check
A supplied recording must drive the clip Does the exact selected route accept supplied audio, and does it use it in the role the brief requires? Check the required relationship between the recording and visible speech or action timing. Producing unrelated sound is not a pass.
The scene needs newly generated dialogue and sound Does the selected route document the required generated-audio behavior and controls? Check whether the requested speech and sound events occur and coordinate with the scene. Do not score this as preservation of an existing recording.

A soundtrack to retain and a voice reference to condition generation are also different requirements. Write down which one the asset represents; an “audio supported” label does not resolve that distinction.

Keep CometAPI’s shared job handling separate from the media contract

My recommendation is to add a small eligibility check before a job enters the CometAPI comparison queue. Record the selected route and variant, the audio starting point, the required role of any supplied asset, and the current route documentation that confirms support. If that confirmation is missing, leave the job out of the trial until it is resolved. Do not silently drop the recording and turn it into a generated-audio request just to make both candidates run.

Only compare results within the same brief once both selected routes can represent it. Shared authentication and polling can simplify the surrounding integration; they cannot make different media requirements equivalent.

This is a trial design, not a report of working CometAPI audio parameters. The cited article supplies the workflow distinction, but no live route, upload format, voice-reference control, latency or listening result has been verified here. The useful decision is therefore narrower than “which model sounds better”: which documented CometAPI route can preserve the audio starting point this job actually requires?

2

For a tutorial, I would add a deliberately unsupported case before the first successful-looking clip. Otherwise a reader can follow every step, get a playable video, and learn the wrong definition of success.

Consider a fictional brief: “Use this supplied recording unchanged; animate a speaker around it.” Once current documentation establishes which route, if any, can represent that requirement, the walkthrough could teach three separate checkpoints:

  1. Before submission: give the application a route configuration that lacks confirmed supplied-recording support. The expected behavior is a local “unsupported requirement” result, with no video job submitted—not a fallback that puts the transcript into a prompt. This is a proposed application guard, not a claim about CometAPI error behavior.
  2. After job completion: obtain the output and check that an audio track is present and playable. Label this only as a media-integrity check. It does not establish that the recording was retained.
  3. Before acceptance: compare the output against the original recording for the required words, speaker characteristics and timing, then inspect alignment with the visible speaker. If “unchanged” means exact audio preservation, define an appropriate signal-level check separately; listening alone cannot prove it.

That sequence gives readers distinct failure labels: unsupported brief, unusable media, or content mismatch. I would keep polling completion and “brief accepted” as separate statuses in the example application. None of these checks has been run here; the teaching point is that a completed asynchronous job is an artifact to inspect, not yet evidence that the audio requirement was met.