How quickly can an AI-dubbed video become reviewable?

Results by source length

Median first playback ranged from 2.4 to 4.0 minutes across the source-length bands, and 76% of all 1,668 jobs began playing within five minutes. The spread is widest for 5–20 minute videos, where roughly one job in three took longer than five minutes to reach first playback.

For 20–60 minute sources the median full dub took about 0.4× the source runtime in this cohort (0.42× for 20–40 minutes, 0.34× for 40–60). Clips under two minutes took about 3.6× their runtime because fixed setup work—ingest, separation, transcription startup, and model startup—occupies a larger share of a short job.

• Download the table as CSV

What changed since the first snapshot

Our first snapshot (655 jobs, August 4, 2026) reported medians of 2.4–3.2 minutes and about four in five jobs within five minutes. With 1,668 jobs the range widens to 2.4–4.0 minutes and 76% begin within five minutes. The cohort is larger and its mix of source lengths, source types and load differs, so read the two snapshots as two observations rather than a trend.

• A longer source does not require waiting for the full runtime before review begins.
• First playback varied less by source length than full completion did.
• Very short clips are the least flattering case for a pipeline optimized around long-form streaming review.

How to interpret the numbers

The result supports a product-design claim: segment streaming can make a long job reviewable well before it is complete. It does not prove that WaveShift is faster than a named competitor, because this was not a controlled head-to-head test.

The 2.4–4.0 minute range is not a service-level objective. A large upload, poor network, unusually dense dialogue, a cold model, transient retries, or queue pressure can change an individual result. Completion-only sampling also excludes jobs that users cancelled or that failed, so the cohort should not be read as a reliability rate.

Limitations and what we would measure next

This analysis uses one operational snapshot. The mix of URL-based sources (YouTube, Bilibili and other supported platforms) and uploaded files was not held constant, and source-language attribution is often automatic rather than a clean experimental label. We therefore do not publish language-pair rankings from this cohort.

A stronger follow-up would use repeated snapshots, publish percentile bands, separate upload from URL ingestion, stratify by dialogue density and model cold starts, and report cancelled and failed jobs alongside completions. A competitor comparison would require matched source files, equivalent output settings, a declared review protocol, and repeated trials.

• No randomized assignment or matched competitor arm.
• No claim of universal processing time.
• No inference about audio quality from timing alone.
• No language-pair leaderboard from incomplete source-language labels.

Why publish an operational benchmark

Marketing claims become more useful when their denominator and failure modes are visible. Publishing the sample size, observation date, clock definition, and limitations lets a buyer decide whether the evidence resembles their own workload.

We refresh the cohort, the visible date and the methods together; the previous snapshot is summarized above. Until then, this page should be cited as an October 1, 2026 operational observation—not as a timeless speed guarantee.