Home › How we test › Proof: long recordings

Proof: WhipScribe transcribes long recordings

A 9.3-hour recording transcribed in 17 minutes (95,578 words), checked 4 Oct 2026: a public-domain LibriVox audiobook run on WhipScribe's production service, with the transcript public below. In the 90 days to 4 October 2026, WhipScribe finished 334 recordings of 2 hours or longer, and 99.2% of 2–4 hour recordings succeeded, counting every failure on our side.

Three test runs on 4 October 2026, and WhipScribe production job records, 6 July to 4 October 2026 (UTC). Raw data: /proof/long-files.json.

Three public-domain recordings, run on 4 October 2026

Production service, English, 4 October 2026. Time to finish is the processing time on the job record, 32 to 48 times faster than real time; waiting in the queue and downloading the link come on top. All three are public-domain LibriVox audiobooks on archive.org, linked from the title. The 2.48-hour file failed twice earlier that morning, and the 9.31-hour file's first attempts failed too, both on a GPU out-of-memory fault (3–4 October) that was fixed on 4 October 2026: the engine now releases GPU cache after every request, a piece that runs out of memory is retried at a smaller batch, and a watchdog restarts the engine if idle memory stays high. The 9.31-hour run finished after the fix. The service titled that transcript after a chapter in it; the archive.org title is the one above.

Every number on this page comes from our own production records: all 4,229 finished and 549 failed transcription jobs in 90 days, grouped by how long the recording was. We show the weak spots too. Recordings of 1 to 4 hours are the proven range; above 8 hours the record is not good enough to promise.

• Up to 10 hours or 5 GB per file
• 2,591.5 hours transcribed in 90 days
• Longest finished: 10.9 h

Drop a file or paste a link. The summary is free to read; a pack from $4 (500 minutes) opens the full transcript.

Results by recording length

Success rate is jobs finished divided by jobs finished plus jobs that failed on our side. Turnaround is wall-clock time from submission to finished transcript, so it includes waiting in the queue and, for links, the download.

6 July to 4 October 2026 (UTC). Bands include their lower bound. *Under 30 minutes, the per-hour figure is inflated by fixed per-job overhead: a 2-minute clip that finishes in 13 seconds works out at 390 seconds per audio hour. 14 finished jobs had no measured duration and are in the totals only.

What the table says

• 1 to 4 hours is reliable. 774 recordings finished and 8 failed on our side; outside the incident windows, 1 failed.
• 4 to 8 hours mostly works. 82 finished, 2 failed, neither during an incident.
• 8 hours and over is weak. 6 finished and 7 failed. Before a change on 23 September 2026 in how we process recordings over 90 minutes, 4 finished and 4 failed; after it, 2 finished (10.0 h and 10.9 h) and 3 failed on the per-job time limit (9.7 h, 10.3 h and 12.2 h, 28 to 30 September). We do not claim reliability above 8 hours. On 4 October 2026 we fixed the GPU memory fault behind the recent long-file failures, and the 9.31-hour run above finished in 17 minutes after the fix, well inside the per-job time limit; new runs will show in this table at its next refresh.
• Speed. The transcription stage alone took a median of 94 to 123 seconds per audio hour for recordings over 30 minutes, which is where our "about 2 minutes per hour of audio" comes from. End to end, a 1–2 hour recording took a median of 128 seconds per audio hour; for 2–8 hour recordings it was 273 to 344 seconds per audio hour (about 5 minutes), because the wall clock also counts queueing and downloads.

All jobs, all lengths

Finished jobs by input: 2,170 file uploads, 1,004 links, 989 through the API, 66 microphone recordings.

Method

What was counted

Every transcription job created on the production service between 6 July 2026 07:05 and 4 October 2026 07:05 UTC whose final status is finished or failed. Cancelled jobs are left out. A recording's length is its measured audio duration. Visitors turned away by the paywall never become jobs, so they are not in this data. The query was run on 4 October 2026 and returns counts and durations only: no titles, owners, links or job identifiers.

What counts as a failure

Counted against us: any failure in our own processing, whether a GPU server ran out of memory or was unreachable, the job hit its time limit, a worker stalled, the file could not be decoded, or an internal error.

Not counted against us: links whose source was gone, private, DRM-protected, a live stream, on an unsupported site or without audio (303 jobs). Links where the platform refused our download, with a 403, a sign-in wall or a rate limit (126 jobs), are also left out of the headline rate but shown separately: counting them gives 94.5%.

Most failed link jobs fail before any audio is measured. Our-side failures without a measured length were placed in a band using the size estimate made before transcription (22 jobs, all under 30 minutes); source and download failures without one appear only in the totals.

Incident windows

The "outside incidents" column removes four periods when our GPU servers were in trouble. We list them so you can judge the exclusion yourself:

Outside these windows, the only day with 4 or more failures on our side was 13 August 2026 (4, of which 3 were files we could not decode). No other day had more than 3.

Limits

• 5 GB per file. Larger uploads are refused.
• 10 hours per file. This is the most we can honestly state. No check refuses a file for its length, but each job has a fixed processing time limit: recordings of 10.0 and 10.9 hours finished, while 9.7, 10.3 and 12.2 hour recordings failed on that limit.
• Over 10 hours: split the recording into parts of 10 hours or less at a natural break and upload each part. Each part spends only its own minutes.
• Live streams that are still running cannot be transcribed; submit the recording once the stream has ended.

How to reproduce it

You do not have to trust our records. These are the three public-domain LibriVox audiobooks from the runs above, each a single MP3 well under 5 GB, chosen to cover the range up to the 10-hour limit. Read our transcripts, or paste a link into the box above, or into whipscribe.com, and time it yourself.

Length from ffprobe on the file, size from the server's Content-Length header. All three are LibriVox recordings, public domain (CC0 1.0 on archive.org). The 9.3-hour file is in the band the 90-day records do not yet show as reliable; it finished on 4 October 2026 after the GPU memory fix.

To check the numbers, download long-files.json: it holds every figure on this page, the three test runs with their transcript links, the band definitions, the failure classes and the incident windows.

Questions about long recordings

Related pages

• Transcribe long audio
• Transcribe long video
• How we test
• Cheap transcription services: what an hour of audio costs.
• WhipScribe pricing