How fast is Whipscribe? Real-Time Factor (RTF), the speed tiers, and our production numbers

What Real-Time Factor measures

Real-Time Factor (RTF) is the ratio of processing time to audio duration:

RTF = transcription_seconds / audio_seconds

An RTF of 1.0 means transcription takes the same wall-clock time as the audio runs in real time. An RTF of 0.10 means the engine processes audio ten times faster than real time. Lower is better. The metric is independent of file length, which makes it the right way to compare a 30-second voice memo against a two-hour podcast on the same scale.

RTF is the standard speed metric used in speech-recognition research, in production benchmarking, and in vendor documentation. When a tool advertises “10× faster than real time” it is reporting an RTF of 0.10.

The speed tiers

RTF values cluster into well-understood tiers. The thresholds below are the ones commonly cited in the speech-recognition literature and in production engineering writeups.

Anything below 0.10 is meaningfully faster than the listener experience, and once you are below 0.05 the file is effectively ready almost as soon as you finish uploading. The difference between 0.20 and 0.05 is the difference between “wait for it” and “it is already done.”

Where Whipscribe lands

These numbers come from real Whipscribe production traffic between mid-April and mid-May 2026 — files uploaded by real users, no curated benchmark set, internal test runs excluded. We measure RTF on every job and surface it on the job page, so you can re-derive these numbers yourself the moment you start using Whipscribe.

Median RTF lands inside the Exceptional tier on real Whipscribe traffic, not on a vendor-curated benchmark suite. The window covers clips as short as six seconds and files as long as one hour forty-four minutes, across roughly twenty languages and a wide range of recording quality — phone-call audio, studio podcasts, conference recordings, voice memos, video exports.

Whipscribe RTF by audio length — flat across the range

A common failure mode in transcription pipelines is RTF degradation as files get longer. Short clips look great; long files quietly run two or three times slower because of batching limits, memory pressure, or queue contention. Whipscribe was designed to not have this drift — and the production data shows it.

Across the four length bands, Whipscribe RTF stays within a narrow window centred on 0.04 – 0.05. There is no growing tail on long files. That is the property to look for when you are evaluating any transcription tool: not the best number on a single short clip, but the consistency of RTF as duration scales.

High-bitrate video on Whipscribe

One area where RTF legitimately rises is high-bitrate source material — typically video exports that pack more than 10 MB of data per minute of audio. The decoder has to do more work before transcription begins, and that decode cost shows up in the end-to-end RTF.

On Whipscribe, a sustained run of high-bitrate video sessions across the same production window stayed in the 0.093 – 0.145 RTF range. That is higher than the standard-audio band, but still inside the industry-standard ceiling of 0.20, and importantly the numbers held under consecutive uploads — not just isolated single-file tests. We routinely process three or four heavy video exports in a row without queue backup, error, or degradation.

Whipscribe queue time: under two seconds

RTF only covers the active processing phase. The other half of perceived speed is queue time — the gap between your upload finishing and transcription actually starting. A pipeline can have a beautiful RTF and still feel slow if jobs sit in a queue for thirty seconds before anything begins.

Whipscribe’s average queue start is under two seconds. At that latency you do not perceive a queue at all — the progress indicator moves immediately and processing is already in flight by the time the upload-complete toast clears. Cumulatively, this is where most of the “feels fast” impression comes from: not from squeezing the last hundredths off RTF, but from removing the dead air between phases.

Gigabyte-scale files, handled in a single shot

The largest single file Whipscribe processed in the window was just over one gigabyte — one hour forty-four minutes of audio, transcribed in six minutes twenty-six seconds at RTF 0.060. Several additional files in the 600 MB – 900 MB range went through without queue backup or error. We mention this because many general-purpose transcription tools impose hard caps in the 200 – 500 MB range, or show meaningful RTF degradation above that ceiling. If your workflow involves long-form podcast episodes, multi-hour interviews, or raw video exports straight from your editor, file-size ceilings are usually the binding constraint — not speed. Whipscribe is built for those files.

How to read RTF claims from any transcription tool

If you are comparing Whipscribe against other tools, here is what to look for when speed numbers get quoted:

• Is it a single number or a distribution? A median or P50 across real audio is much more meaningful than a best-case single-file number.
• What was the test corpus? Clean studio audio inflates RTF claims. Real production audio includes phone-quality calls, noisy field recordings, accented speech, and short voice memos.
• Does it hold on long files? Ask for the RTF curve by audio length band. A flat curve is the signal you want.
• Is queue time included? End-to-end perceived speed includes the wait before processing starts, not just the processing itself.
• Was the test run under sustained load? Single-file numbers and three-in-a-row numbers can diverge significantly on pipelines that lean on burst capacity.

Whipscribe at a glance

Frequently asked