How long does a 10-minute Instagram Reel take to transcribe — and does it get cut off?

Nothing here cuts it off. Across the 22,349 bytes of app.js there is no duration limit, no file-size limit and no “too long” branch: the clip is decoded to one channel at 16,000 Hz and read in 30-second windows that step forward 20 seconds at a time, so 600 seconds becomes 30 windows and 900 seconds of audio passes through the model — 1.5 times the clip’s own length. The wait follows those windows. Measured in this browser on 27 October 2026, the 600-second clip finished its recognition pass in 251.5 seconds, 0.42 times its own running time, while the tab held a peak of 268,800,000 bytes.

The rest of this page is where those numbers come from: what a 9,147,662-byte file becomes before the model sees it, why ten minutes is 30 windows rather than 20, what the run cost in this browser stage by stage, the three ways a long clip still ends early when length is not one of them, and what the three sites that outrank this one actually say about a long clip across 226,977 characters of their own copy — including the one of them that does cut.

A 9,147,662-byte clip is 230,400,000 bytes inside the tab

The clip used for this test is 600.0 seconds of 48 kHz stereo AAC — the shape of a downloaded Reel — and 9,147,662 bytes on disk. decodeAudioData returns an AudioBuffer, an AudioBuffer sample is a 32-bit float, so the decoded copy is 600 × 48,000 × 2 × 4 = 230,400,000 bytes. That is 25.19 times the file on disk, and it exists before any speech recognition starts.

Two buffers, not one. toPcm() does not transcribe the decoded source; it renders it into OfflineAudioContext(1, frames, 16000) and hands getChannelData(0) to the model. The render is 600 × 16,000 × 1 × 4 = 38,400,000 bytes, and both buffers are alive at the same moment, because the render reads from the source while it writes. Peak: 230,400,000 + 38,400,000 = 268,800,000 bytes.
Ten minutes of 48 kHz stereo is heavier than thirty minutes of 16 kHz mono. Before this run, the largest amount this tool was known to have passed was a 30-minute 16 kHz mono file: 115,200,000 bytes decoded plus 115,200,000 rendered, 230,400,000 in total. This clip is a third of that length and peaks at 268,800,000 bytes, 1.17 times higher — and it passed, which moves the largest known pass up to 268,800,000. The reason a third of the length weighs more is that 48 kHz stereo costs 384,000 bytes a second against 64,000 for 16 kHz mono.
The rejected file in the source comment is this one at twice the length. Twenty minutes of 48 kHz stereo is 460,800,000 bytes decoded and 76,800,000 rendered, a 537,600,000-byte peak, and it came back as EncodingError — the same error a damaged file produces. Halving the length halves every one of those figures, which is the whole distance between this run and that one.

Ten minutes is 30 windows, not 20

The only length-related constant in app.js is chunk_length_s: 30, passed at line 282. The library that consumes it sets the stride to a sixth of the window and steps forward by the window minus two strides: a 5-second stride and a 20-second step. A 30-second window at a 20-second step makes 600 seconds into ceil((600 − 30) ÷ 20) + 1 = 30 windows. Twenty would be the count if the step were the window itself.

900 seconds of audio for a 600-second clip. Thirty windows of 30 seconds is 1.5 times the clip, and that ratio is constant rather than growing: a 60-second clip is 3 windows and 90 seconds, an hour is 180 windows and 5,400 seconds, and both are also 1.5. There is no knee in the arithmetic, so the wait for a long clip is the wait for a short one multiplied.
Each window is 480,000 samples, or 1,920,000 bytes of float32. The 5-second strides mean a window shares 5 seconds with the one before it and 5 with the one after: 10 of its 30 seconds are also inside another window. That overlap is what the 1.5 factor buys, and it is why a word spoken across a boundary is read twice rather than lost.
The clip ends inside the last window. Windows start at 0, 20, 40 and so on, so the 30th starts at 580 seconds and would run to 610 — 10 seconds past the end of a 600-second file, while the 29th already covered 560 to 590. frames is ceil(600 × 16,000) = 9,600,000 samples exactly, so the page adds no padding of its own and trims nothing; the overlap is where the final 20 seconds get read a second time.

Windows 1 and 2 overlap by 5 seconds, and the step between their starts is 20 seconds. Thirty of those steps reach 580, so the last window is 580 to 610 — ten seconds of it lie past the end of a 600-second file, and the 20 seconds before that were already read by window 29. The whole clip is 9,600,000 samples at 16,000 Hz, of which 900 seconds’ worth passes through the model: 1.5 times the audio you actually have. Nothing is thrown away at either end; the cost is paid in repeats.

What the run cost, stage by stage

The file was chosen 4.8 seconds into the session. “Getting the speech model ready…” replaced “Reading the audio track…” at 13.3 seconds, so decoding the 230,400,000-byte buffer took about 8.5 seconds; “Transcribing on this device” appeared at 25.4 seconds, so fetching and initialising the 79.7 MB model took 12.1 seconds; the transcript panel appeared at 271.9 seconds. The recognition pass, as the page itself reports it, was 251.5 seconds. It finished without an error, which is the answer to the truncation question: the whole 600 seconds came back.

The decoder reports a slightly longer clip than the container does. ffprobe puts the file at 600.000 seconds; the browser’s AudioBuffer came back as 600.3 seconds, because AAC frames are padded, and that is the number the panel prints. frames is ceil(600.3 × 16,000) = 9,604,800 samples and the render is 38,419,200 bytes rather than 38,400,000 — a 0.05 per cent difference, which is why every figure here is quoted for the round 600-second case.
The figure in the panel is smaller than the wait. t0 is set at line 276, after the model has loaded, and elapsed is read at line 285, straight after the recognition call; the 8.5 seconds of decoding and the 12.1 seconds of download sit outside the timer. On a first run of a 10-minute clip that gap is 20.4 seconds, and it closes only on a second run in the same tab, where the model is already in memory.
Per window and per second of audio. 251.5 ÷ 30 = 8.38 seconds a window, and 251.5 ÷ 600 = 0.42 seconds for every second of audio. The same machine measured 112 seconds for a 161.175-second clip on 6 October 2026 — 0.69 seconds per second of audio — which is the same order, as a fixed cost per window should be.
The output side, measured. The run returned 1,194 words in 111 segments across the 30 windows — 3.7 segments per window and 10.76 words per segment — and the transcript on screen was 8,173 characters, 28,204 times smaller than the 230,515,200-byte buffer it came out of. That ratio is the reason a long clip is a waiting problem rather than a storage one.

The measured run, drawn twice. Top: the 271.9 seconds between choosing the file and reading the panel split into 8.5 seconds of decoding, 12.1 seconds of model download and 251.5 seconds of recognition — so the model is 92.5% of the wait and the file handling is 3.1%. Bottom: 251.5 seconds of recognition against 600.3 seconds of audio is 0.42 seconds of work per second of speech, which is why a clip four times longer is not four times the wait in any hidden way, only four times the windows. The numbers come from one run on this machine on a 600-second, 9,147,662-byte file; 22,349 bytes of app.js contain no length limit and no size limit, so nothing is cut at either end.

Three ways a long clip still ends early — none of them length

Memory, and it is the only real ceiling. 268,800,000 bytes is the number to watch, and it is the sum of two buffers that are alive together rather than a limit written anywhere in the code. This machine has 3.9 GB of RAM, so the peak is about 6.4 per cent of the 4,227,313,664 bytes it reports; a phone tab holding the same clip has a smaller budget, which is why a long Reel is a desktop job in practice rather than a phone one.
A decode failure costs nothing, because it happens first. If the browser will not read the audio, it fails at decodeAudioData on line 268 — before the model is fetched on line 273 — so a 10-minute file the tab cannot hold costs 0 bytes of download. That ordering is deliberate: the source comment says decoding first turns “a minute of waiting ending in an error” into an error in a second.
Closing the tab ends the run, and there is no copy to return to. The page makes 2 network requests in total, one for the library and one for the model; the audio is never part of a request. Nothing is uploaded and nothing is queued on a server, so a 10-minute run that is interrupted at minute 8 has produced nothing at all — the 22,349 bytes of app.js contain no resume, no cache of the transcript and no partial save.

What the three sites that outrank this page say about a long clip

Across the 33 pages held in this site’s benchmark directory — 226,977 characters of visible body text, measured after the scraper’s heading lists are stripped — the phrase “processing time” appears 0 times, “takes about” 0 times and “wait” 0 times. On their 111,530 characters of Instagram pages specifically, “minute” appears 28 times on wayin.ai, 6 times on speakapp.com and 2 times on getthescript.app. Two of those uses matter.

speakapp.com is the one that truncates, and it says so twice. Its Instagram transcript page states “We support all public Reels up to 2 minutes long”, and its video page states “We pull the audio directly from Instagram and trim long videos to 2 minutes for the free preview.” A 10-minute Reel is 5 times that cap — 600 seconds against 120 — and both sentences sit inside the 14,805 characters of Instagram copy this site holds from it. If you are comparing tools on a long clip, that is the line that decides it, and it is a sentence about input length rather than a performance claim.
wayin.ai promises no cap and gives no time. Its Instagram page says “Our tool handles every Instagram format. Paste the public link from a Reel, a Story, or an hour-long Live replay—WayinVideo transcribes every spoken word with precise timestamps, no matter the length.” That is a statement about accepting the input; 0 of the 226,977 characters gives a figure for how long the job takes.
getthescript.app publishes one timing claim, in a comparison table. Its summariser page puts “Time Required” at “5 - 10 seconds” for its own tool, “5 - 15 minutes” for manual watching and “1 - 3 minutes” for “Generic Transcribers”, with no clip length attached to any of the three. Its Instagram transcript page contains 0 uses of “minute” and 0 of “hour” across its 9,251 characters of body text.
None of the three answers the question this page is about. No page in the 111,530 characters of Instagram copy pairs a clip length with a processing time, so the only way to know what ten minutes costs is to run ten minutes — which is what the measurement above is.

Before you start a long one

Cut it, if you only need part of it. The model reads 1.5 times the audio you give it, so trimming a 10-minute clip to the 3 minutes you need takes 180 seconds of audio down to 270 seconds of work — and 230,400,000 bytes of decoded source down to 69,120,000, with an 80,640,000-byte peak instead of 268,800,000.
Run it on the machine that has the memory, and leave the tab alone. There is no server copy to fall back on, so a 10-minute job interrupted at minute 8 returns nothing. On this 3.9 GB machine the peak was 6.4 per cent of RAM; on a phone it is a much larger share of a smaller number.
Expect the wait to scale, not to jump. 30 windows for 10 minutes and 3 for a minute is the same 1.5 factor, so a clip twice as long takes about twice as long — there is no threshold past which the tool behaves differently, because there is no threshold in the code.

Will a 10-minute Reel be cut down to the first few minutes?

Not by this tool. app.js contains no duration check of any kind, and the file is processed end to end: 600 seconds is 9,600,000 samples at 16,000 Hz and 30 windows of the model. The tool that does cut is speakapp.com, whose own page says “We support all public Reels up to 2 minutes long” — a fifth of a 10-minute clip.

So how long will I actually be waiting?

The recognition pass was 251.5 seconds for 600 seconds of audio on this machine, plus 8.5 seconds to decode and 12.1 seconds to fetch the model on a first run — 271.9 seconds from choosing the file to reading the transcript. The scaling rule is 1.5 seconds of audio processed for every second of clip, so the wait is proportional: half the clip is half the wait.

Does the bigger model make a long clip twice as slow?

The download is the part that is measured: 79.7 MB for the default model against 43.6 MB for the smaller one, and 79.7 MB is 1,245.3125 seconds of 16 kHz mono, or 20.76 minutes, so the model is worth more than the clip you are transcribing. The recognition speed difference between the two was not measured on a 10-minute file here, so this page gives no figure for it; what the source says is that they “differ only in size, speed and accuracy”, which is a description rather than a number.

Can I do a 10-minute clip on a phone?

Not measured here, and the arithmetic is the reason to be careful. A 10-minute 48 kHz stereo source decodes to 230,400,000 bytes and the 16 kHz render adds 38,400,000 more while the first is still held, for a 268,800,000-byte peak — 6.4 per cent of this desktop’s 3.9 GB and a far larger share of a phone tab’s budget. A shorter cut of the same file is the cheap test: if 2 minutes works and 10 does not, the ceiling is memory rather than length.

Last checked: 27 October 2026. Everything measured here was measured on this machine: Windows 11, Chrome 156.0.8078.48 in headless mode, one AMD EPYC 9754 core with 2 threads and 3.9 GB of RAM. The clip was 600.000 seconds of 48 kHz stereo AAC, 9,147,662 bytes, built for this test from a recording already on this machine; the browser decoded it as 600.3 seconds, which is the duration the panel printed, and the run reported 251.5 seconds, 1,194 words, 111 segments and 8,173 characters of transcript on screen, with the decode and model-load times read from the page’s own status messages at 4.8, 13.3, 25.4 and 271.9 seconds. Everything else is arithmetic on constants in app.js and on the Web Audio specification: RATE = 16000, one channel, a 32-bit float sample, chunk_length_s: 30 at line 282, a 5-second stride and a 20-second step read from the library that consumes it, t0 at line 276 and elapsed at line 285. The byte figures were printed and re-checked before they were written down: 600 × 48,000 × 2 × 4 = 230,400,000; 600 × 16,000 × 4 = 38,400,000; the sum 268,800,000; 268,800,000 ÷ 230,400,000 = 1.17; 230,400,000 ÷ 9,147,662 = 25.19; ceil((600 − 30) ÷ 20) + 1 = 30; 30 × 30 = 900 seconds of audio, 1.5 times the clip. The 48 kHz stereo figure describes this test file; a file recorded at 44.1 kHz stereo would decode to 211,680,000 bytes and peak at 250,080,000, which is arithmetic rather than measurement. The competitor figures come from the 33 pages in this site’s benchmark directory, 226,977 characters of body text after the heading lists were stripped, and the quoted sentences are reproduced as they appear there. The 2-minute cap is speakapp.com’s own statement about its own product; whether it applies to every plan is not stated on the pages held here.

If the clip is long because it is a Live replay, transcribing an Instagram Live replay works through the hour-long case and the 5,400 seconds of audio its 180 windows carry. If it is long enough to worry about the platform’s own ceiling, the Reel length limit page covers where the platform stops and where memory does. The timestamps page explains the 12 characters in front of every line, the SRT and VTT page covers what those cues become as files, and the upload page covers the two requests this page makes and the one it does not.