Long Reels: What Breaks at 5, 10, 15 and 30 Minutes

The four lengths, as measured

One recording, looped to length, cut at 5, 10, 15 and 30 minutes. Each length went up twice - once as 16 kHz mono audio at 48 kbps, once inside a 540x960 MP4 with the same audio track. Same content both times, so any difference comes from the container and the duration, not the words.

• 5 min audio, 2,032,541 bytes - HTTP 200 in 34.8 s, 817 words.
• 5 min video, 2,555,086 bytes - HTTP 200 in 23.2 s, 817 words.
• 10 min audio, 4,062,862 bytes - HTTP 500 in 121.6 s, then 500 / 500 / 200 on three retries.
• 10 min video, 5,044,938 bytes - HTTP 200 in 104.5 s, 1,613 words.
• 15 min audio, 6,092,159 bytes - HTTP 200 in 94.1 s, 2,421 words.
• 15 min video, 7,533,765 bytes - HTTP 500 in 124.0 s, and 500 on all three retries.
• 30 min audio, 12,177,792 bytes - HTTP 500 in 127.9 s, and 500 on all three retries.
• 30 min video, 15,055,039 bytes - HTTP 500 in 126.3 s.

Read that list twice, because the order makes no sense at first. Ten minutes of audio failed while fifteen minutes of audio passed. Ten minutes of video passed while fifteen minutes of video failed. If length were the variable, the results would march in one direction. They don't.

The retries are the useful part

A single failure tells you almost nothing. So every failed file went back three more times, unchanged, same bytes. The 10-minute audio came back HTTP 500 at 121.7 s, 121.2 s, and then HTTP 200 at 70.8 s with 1,613 words - the full transcript, nothing missing. Four attempts, one success, three failures, identical input.

That kills the obvious explanation. A file that sometimes works is not too long. It is too slow, and it is racing a clock you can't see.

Where the clock sits

Every failure in this run landed between 121.2 and 127.9 seconds of wall time, which is close enough together to be a budget rather than a coincidence. The successes matter just as much: the same 10-minute audio finished in 70.8 s when it went through, and a 12-minute video earlier today finished in 123.4 s.

So the line isn't a round number and it isn't a duration. It behaves like a processing budget near two minutes. Finish inside it and you get the whole transcript. Run long and the job gets killed with a generic message. A 720-second file squeaked through at 123.4 s. A 900-second file died at 122.7 s. Both sit on the same side of a very thin margin, decided by how loaded the machine was that second.

Words per minute stays flat, so length isn't degrading anything

Every successful run returned words at the same rate: 817 words from 5 minutes, 1,613 from 10, 2,421 from 15. That's 163, 161 and 161 words per minute, against 162 expected from the source recording. Nothing gets quietly dropped as the file grows - the transcript is complete right up to the point where the job gets killed.

That's worth knowing because it changes what you do about a failure. You are not looking at a tool that gets worse on long audio. You are looking at a tool that either finishes or doesn't, with no partial output in between. There's no 80 percent transcript to repair.

Video buys you nothing and costs you seconds

Compare the matched pairs. At 5 minutes the video run came back faster than the audio run, 23.2 s against 34.8 s - both well inside the budget, so the gap is noise. At 15 minutes the video run took 124.0 s and died, while the audio run of the same content took 94.1 s and passed. The picture doesn't get read, but decoding it and throwing it away still spends time, and at the margin that time is the difference between a transcript and a 500.

Same rule as a short clip, with more at stake: send the audio track, not the video.

What to do at each length

Five minutes: send it whole, in either shape. Expect 23 to 35 seconds of waiting and no drama. This is the shape that has never failed in any test we've run.

Ten minutes: send the audio, not the video, and expect a coin flip. In four attempts on one file we got one success. If it fails, re-send the same file - don't re-encode it first, because the bytes weren't the problem. The retry that worked was byte-identical to the three that failed.

Fifteen minutes: cut it. Five-minute chunks at 48 kbps are the shape that has never failed here. Three of them cost about 105 seconds of waiting, against a single 15-minute attempt that mostly doesn't come back. Audio-only passed once at 94.1 s, so it's possible, but you're gambling a minute and a half on it.

Thirty minutes: don't send it in one piece. Eight attempts across both shapes, zero successes, all dying near 126 seconds. Six chunks of five minutes is the same audio with eight times the odds. If you want one call and no chunking, instagram transcript generator lays out what the response actually contains. Read that before you start, so you know what you're waiting on.

The one thing not to do

Don't re-encode a failed long file and send it again as your first move. The 10-minute audio that eventually passed was the same 4,062,862 bytes that had just failed three times. Re-encoding changes the bytes and costs you a minute of your own time without touching the clock that killed the job. Retry as-is first, once. If two retries fail, the file is over the budget for today - chunk it.