Why a Transcript Sometimes Runs for Two Minutes and Then Fails
A short video transcribes instantly, a long one grinds and then gives up. It usually isn't the length — it's how much of the video got downloaded to reach the audio. Here's the mechanism.
Short answer
Two different causes produce the same symptom. Either the platform publishes no audio-only version, so the tool downloads a large video file to reach the audio, or the video's length could not be read and the job was given a small time budget it could never meet. Retrying helps only the second.
There's a specific failure that feels worse than an instant error: the tool accepts your link, works for a minute or two, and then fails anyway. You've waited, and you have nothing.
Short videos on the same platform work fine. Long ones don't. It's tempting to conclude the tool has a length limit — but usually it doesn't, and the real cause is more fixable than that.
Transcription only needs the audio, but not every platform will hand it over
To turn speech into text you need the sound. You don't need the picture at all, and the difference in size is enormous: an hour of speech is a few megabytes as audio, and can be several gigabytes as high-definition video.
Most platforms make this easy by publishing an audio-only version alongside the video ones, so a transcription tool asks for that and downloads a few megabytes.
Some platforms publish no audio-only version. Every option they offer is picture and sound welded together. To reach a few megabytes of speech you're obliged to download a video file — and then it matters enormously which one you pick.
Picking the wrong file is the whole bug
When a platform offers no audio-only option, the natural fallback is to ask for "the best available". That's exactly wrong here. "Best" means the largest, highest-resolution file on the page — and the audio inside it is byte-for-byte identical to the audio inside the smallest one. Same microphone, same recording, same words. The only difference is picture quality that gets thrown away seconds later.
Some real measurements from our own platform, all of them the same video compared against itself:
- A ninety-minute Rumble interview: 897 MB at highest quality against 89 MB at lowest. Ten times.
- A Dailymotion clip: 18.5 MB against 1.4 MB. Thirteen times.
- A Wistia business video: 10.5 GB against 87 MB. A hundred and twenty times.
That last one is not a typo. A single video was pulling over ten gigabytes to reach an audio track smaller than a photo album.
Which is where the two-minute failure comes from
Downloads get a time budget. They have to — without one, a single stalled video would occupy a server indefinitely and everyone else would queue behind it.
If you're downloading 89 MB, the budget is irrelevant; you finish comfortably. If you're downloading 897 MB, you need to sustain roughly 7.5 MB per second for the entire two minutes to make it. Sometimes the network delivers that. Usually it doesn't, and the download is cut off partway.
This explains the pattern that makes it feel random:
- Short videos work. Even at silly quality, a two-minute clip is small enough to finish.
- Long videos fail. Same quality setting, ten times the runtime, and now it can't finish in time.
- The same video fails repeatedly. It isn't luck. It's arithmetic, and the arithmetic doesn't change between attempts.
So a platform in this state looks flaky — half its videos work — when it's actually misconfigured in a completely consistent way. That's a much more useful thing to know, because a flaky platform is something you wait out and a misconfigured one is something that gets fixed.
What we changed
Every platform that publishes no audio-only version now takes the smallest version that still carries sound, rather than the largest. The audio is the same either way.
On that ninety-minute Rumble interview, the same link went from failing repeatedly at the two-minute mark to completing in twenty-nine seconds, with an audio track that transcribes identically.
What this means for you
If a transcript is slow and then fails, particularly on a long video, it is worth simply trying again — but the honest answer is that the fix belongs on our side, not yours. There is nothing about your link to correct.
The genuine length limits are much further out than people expect. Multi-hour recordings and full livestream replays transcribe fine; they were never the problem. If you would rather not wait at all, exporting just the audio and uploading the file directly skips the download entirely — your machine sends a few megabytes instead of a server fetching hundreds.
Related Reading
- Why a video transcript fails — and what each error means
- What each transcript error message actually means
- Transcribing very long videos and full livestream replays
A second cause, measured 2026-09-15: the tool never learned how long the video was
Everything above is about a download that is too big. There is a second route to the identical symptom, and it is stranger: the tool downloads something perfectly reasonable and still runs out of time, because it budgeted for the wrong video.
Most tools scale their patience to the length of the video. Before downloading anything they ask the platform how long it is, and a two-hour video is given more time than a two-minute one. That is sensible right up until the platform declines to answer.
Some platforms rate-limit that question. Not always — intermittently, which is the worst kind. Here is the same link probed three times in a row from the same machine on 15 September 2026:
- attempt 1 — answered, 1438 seconds
- attempt 2 — answered, 1438 seconds
- attempt 3 — HTTP 403 Forbidden
Nothing about the video changed between attempt 2 and attempt 3. The wall closed because we had asked three times.
Now follow what happens to a job that lands on attempt 3. The length is unknown, so the duration-scaled budget never applies and the job falls back to a default. In our case that default was 120 seconds. The video was 24 minutes long and, had the probe answered, would have been given 479 seconds. It was killed at 120.9 seconds and the person who submitted it waited two minutes to be told the download took too long.
The failure is real but the diagnosis in the error message is wrong. The download was not too slow. It was given an eighth of the time it had earned, because one metadata request lost a coin flip.
We had the rule backwards. An unknown duration was treated as a reason to be stingy, when it is the one case where you cannot rule out a long video — and the platforms that hide a duration are disproportionately the ones with a wall in front of them, which is to say the ones hosting long-form video. Unknown now gets a generous budget rather than the smallest one, capped by the same whole-job ceiling as everything else.
What this means if you hit it elsewhere. If a tool fails on a video that is not especially long, and a retry a few minutes later sails through, you are probably seeing this rather than a size problem. The tells are different: a size failure is consistent for that video and scales with its length, while this one is a coin flip on the same link. Why a TikTok transcript fails and then works covers the underlying rate-wall behaviour in more detail, and what each error actually means covers whether retrying is worth your time.
Frequently asked
How do I tell a size problem from a timing one?
A size failure is consistent for that video and scales with its length — short clips on the same platform work, long ones never do. The other is a coin flip on the same link: it fails, then a retry a few minutes later sails through. If your own repeated attempts change the outcome, it is a rate limit rather than a size problem.
Does the tool having a length limit explain it?
Usually not. Most tools have no hard length limit, and the failures cluster by mechanism rather than by duration. We measured a 24-minute video failing on a 120-second budget purely because one metadata request was refused, while multi-hour recordings on the same platform finished normally.