How do you transcribe an Instagram Live replay?

A Live replay is not a long Reel — it is a broadcast whose length nobody chose, and the ceiling that decides the answer is this browser tab rather than Instagram. Measured here, a valid 20-minute file was refused before the speech model was even fetched, with the same EncodingError a damaged file gets, so the honest answer to “how long can I transcribe” is a number in minutes rather than hours, and a replay goes through as slices. One hour of replay is 57,600,000 samples at 16,000 samples a second, which becomes 230,400,000 bytes once every sample is 32 bits in a single channel — 64,000 bytes for each second of broadcast. The model that reads those bytes is 79.7 MB, so four hours of decoded replay at 921,600,000 bytes is 11.6 times the size of the thing transcribing it.

What follows is the part that is specific to replays rather than to clips in general: the four properties a replay has that a Reel does not, what each length costs in decoded bytes, where the tab was measured to stop, why the window count for an hour is 180 rather than 120, and what the three pages that outrank this one say about Live in their own words — which, across 373,780 characters of their copy, is one sentence.

What a Live replay has that a Reel does not

The difference is not duration with a bigger number in front of it. A Reel is an edit: you decide where it starts and stops, and the file you end up with is the one you chose. A replay is a recording of something that happened in real time, and four things follow from that, each of which changes what a transcript can be.

• Nobody chose the length. The broadcast ran for as long as the host kept it open, so the input to this tool is whatever the recording happens to be. wayin.ai's Instagram page is the only page in the corpus that names a length at all, and it names it loosely: “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 one hour as an example rather than a limit, and “no matter the length” carries no number, no byte count and no memory ceiling.
• Half the conversation is not audio. A Live has a comment column, and comments are text that was typed, not speech that was recorded. A transcript of the replay contains the host and anyone the host brought on mic, and 0 of the questions in the comment column, because those never entered the audio track that decodeAudioData hands to the model.
• Dead air is normal, and it is not free. Waiting for viewers, reading a comment, a pause while a guest joins: an hour of replay is 180 windows whether or not there are words in them, and a window of silence returns an annotation rather than a sentence. Measured, a clip with music and no speech once came back as 2 words, the two words being (smooth music), which is why bracketed text is now stripped before the word count.
• It arrives as a file, not as a link. This tool's picker has 12 entries — 2 wildcards and 10 named extensions — and 0 of those 12 accepts a URL, a username or a post ID. The paste-the-link route wayin.ai describes is a different route to a different machine; here a replay has to exist as a file you already hold, which is why the slicing question comes before the transcription question.

What a replay costs, by length

Every figure below comes from one multiplication and two constants, both readable in this site's own source: RATE = 16000 on line 236 of app.js, and a decoded sample being 32 bits, which is the Web Audio specification rather than a choice this page made. 16,000 × 1 × 4 = 64,000 bytes a second, and the window count in each line is ceil((L−30)/20)+1, which is what chunk_length_s: 30 on line 282 actually produces once the library's default 5-second stride is applied.

• 10 minutes: 9,600,000 samples, 38,400,000 bytes, 30 windows. This is the slice size the rest of this page keeps coming back to, because it is the largest round number that leaves the tab with room to breathe: 38,400,000 bytes is a twentieth of what four hours would need.
• 30 minutes: 28,800,000 samples, 115,200,000 bytes, 90 windows. The window count is already 1.5 times the 60 you would get by dividing 1,800 by 30, and that ratio does not change with length.
• 1 hour: 57,600,000 samples, 230,400,000 bytes, 180 windows. Before resampling, the same hour at 44.1 kHz stereo is 1,270,080,000 bytes, and both buffers exist at once while the render runs, so the peak is 1,500,480,000 bytes rather than either figure on its own.
• 2 hours: 115,200,000 samples, 460,800,000 bytes, 360 windows. At the source rate the decode alone is 2,540,160,000 bytes, which is 2.5 GB of samples for a recording most phones produced without complaint.
• 4 hours: 230,400,000 samples, 921,600,000 bytes, 720 windows. Add the source-rate buffer at 5,080,320,000 bytes and the peak is 6,001,920,000 bytes, or 6.0 GB, against a speech model that is 79.7 MB — a ratio of 75 to 1 between the audio and the thing that reads it.

Where the tab was measured to stop

The one hard measurement in this page's records is a refusal, and it is worth quoting precisely because it was not a size check: a valid 20-minute WAV was rejected by decodeAudioData with EncodingError, the same error object, the same message and the same code 0 that a 77-byte text file renamed .mp4 produces. That 20 minutes is 76,800,000 bytes at 16 kHz mono; the AudioBuffer that failed was at the file's own rate, which for a 44.1 kHz stereo WAV is 423,360,000 bytes, and with the 16 kHz render alongside it the tab was holding 500,160,000 bytes when it gave up.

• Four hours is 12 times that length, not 4 times. 14,400 seconds against 1,200 seconds is a factor of 12, and the peak scales with it to 6,001,920,000 bytes, so the question is not whether a full replay fits but how many pieces it has to become.
• What does pass is small. A 43-second clip — 688,000 samples, 2,752,000 bytes, 2 windows — ran to completion a dozen times. Between that 43 seconds and the 1,200 seconds that failed there is no measurement in this page's records, so the true ceiling sits somewhere in that gap and this page will not put a number on it.
• The refusal is silent about which of three things went wrong. The same error covers a damaged file, a file larger than the tab can hold, and a file with no audio track at all — a WebM with a picture and no sound plays in a video element and still fails here. For a replay that means a failed run is not automatically a too-long run, and the size shown next to the file name is the only clue the page gives you.

Why an hour is 180 windows rather than 120

Cutting audio into 30-second windows sounds like dividing the length by 30, and it is not, because consecutive windows overlap by 10 seconds: the stride is a sixth of the window on each side, 5 seconds, so each window advances by 20 seconds and every second of a replay is processed by 1.5 windows on average. The count is ceil((L−30)/20)+1, and at 3,600 seconds that is 180 calls rather than the 120 a plain division gives.

• An hour is 5,400 seconds of audio work for 3,600 seconds of broadcast. 180 windows of 30 seconds each is 5,400 seconds pushed through the model, and the extra 1,800 seconds is the overlap being transcribed twice.
• Four hours is 720 windows and 21,600 seconds of work. The overlap cost stays proportional, so no length is cheap: a replay twice as long is 2 times the windows, never 1.9.
• The wait follows the windows, not the megabytes. Measured, the 2-window clip took 18 to 42 seconds across a dozen runs on a two-core, 4.2 GB machine, which is 9 to 21 seconds a window; 180 windows at that rate is 27 to 63 minutes for one hour of replay. That is an extrapolation from one measurement, not a stopwatch reading on a replay, and it assumes the machine does not start swapping — which, at 6 GB for four hours, it will.

How to cut a replay into pieces that fit

Every route below ends in the same place — a file on disk that the picker will take — and the only decision that matters is where the cuts go. Ten-minute slices are the size this page recommends, because 38,400,000 bytes and 30 windows is a job the tab finishes rather than fails, and because a cut on a round number is easy to re-join later.

• Record it in slices while it plays. A screen recording stopped and restarted every 10 minutes produces files the tab can hold, and 30 windows each. The cost is that the joins are approximate: a sentence crossing a cut is transcribed twice, once at the end of one file and once at the start of the next.
• Save the whole replay, then split it before picking. If you already have the file, the split happens outside the browser, so the tab never sees 230,400,000 bytes for an hour or 921,600,000 bytes for four. This is the route with the fewest unknown quantities, and the only one where the audio reaching the model is the audio that was recorded.
• Ask the host for the original. Slower, and often the only way to get a clean track rather than a capture of a playback, which matters most on a replay where music played under speech for an hour — the band that survives resampling stops at 8,000 Hz, so anything above it was never going to reach the model anyway.

What the three best-known tools say about Live replays

The three pages that outrank this one for instagram transcript were fetched on 21 October 2026, and the counts below are over the copy held in this site's benchmark directory: 373,780 characters across 48 files, of which 24,623 characters are the four Instagram transcript pages the three sites publish.

• One of the three mentions Live at all, and it does so five times. The phrase “Live replay” occurs 5 times in 373,780 characters, all 5 on wayin.ai's Instagram page: twice because its section heading is captured both in the extracted heading list and in the body, then once in the sentence quoted above, once in its three-step instructions and once in its FAQ answer. getthescript.app never uses the word; speakapp.com uses “live” twice across its two Instagram pages and both times as the verb in “live in the feed”, never as a format.
• Their own format list does not agree with itself. The section heading reads “Transcribe Instagram Reels, Stories & Live Replays”, while the FAQ answer on the same page reads: “WayinVideo supports transcription of Instagram Reels, Live replays, and standard video posts. The only requirement is that the profile and post must be set to public.” Stories is in one list and missing from the other, and both lists include Live.
• Their route needs the post to be public, and that is stated five times in 8,698 characters. That same FAQ sentence makes public visibility the only requirement; the word “public” appears 5 times on the page and “profile” once. What the page never says is what happens to a broadcast that was never shared to a profile: “archive” occurs 0 times there, so the case where a replay is reachable at no address at all is not covered by the route that requires an address.
• 0 of the three gives a length, a byte figure or a memory ceiling. Across 373,780 characters there is no statement of how long a Live can run, no decoded-audio figure and no mention of what a browser tab can hold; “no matter the length” is the entire answer the corpus contains, and it is a promise rather than a measurement.

What to do with an hour of text once you have it

A replay transcript is long in a way a Reel transcript never is: at the measured rate of 54 words in 43 seconds, an hour of continuous speech is about 4,521 words and four hours is about 18,084 — extrapolations from one clip rather than counts of a replay, and both assume the host never stopped talking, which no Live does. What that changes is not the reading but the file: 180 windows of output, joined into one document, is a thing you search rather than a thing you read.

• The silent thirds are why the word count looks low. A 4-hour replay is 720 windows and 21,600 seconds of model work, and every window of dead air contributes 0 words, so a replay that ran four hours may carry the words of a one-hour conversation. Judge the transcript against the talking, not against the runtime.
• Keep the slices, not just the joined text. Six 10-minute files give you six transcripts whose boundaries match the recording, so a quote you cannot place can be found by re-running 38,400,000 bytes rather than 921,600,000. That is the practical argument for slicing beyond the memory one.

Can I paste a Live replay link into this tool?

No, and there is no field to paste it into. The picker's 12 entries are 2 wildcards and 10 named extensions and 0 of them is a URL; the strings live and replay occur 0 times between them in the 22,349 bytes of app.js, so there is no Live branch and no replay branch to reach. The only three network destinations in a run are the recognition library, the model weights and one generation_config.json for the language list, and 0 of those three takes a link from you.

How long a replay can this transcribe in one go?

Longer than 43 seconds and shorter than 20 minutes, and this page will not narrow it further because it has no measurement in between. What is measured is that a 43-second clip — 2,752,000 bytes, 2 windows — completes, and that a valid 20-minute file — 76,800,000 bytes at 16 kHz, 500,160,000 bytes of peak with the source buffer — is refused with an EncodingError. The safe slice is 10 minutes, which is 38,400,000 bytes and 30 windows.

Does a Live replay have to be downloaded before it can be transcribed?

Yes, in the sense that it has to exist as a file first, whether that file is the recording the app saved or a capture you made of the playback. The decode runs before the model is fetched, so a file with no audio track is refused in about a second instead of after a 79.7 MB download — which for a replay is the difference between a quick no and a long wait for the same no.

What comes back from the silent stretches of a replay?

Nothing that survives the word count. The model answers silence and music with an annotation — [Music], or in round brackets (smooth music) — and bracketed text is stripped before counting, so a window of dead air adds 0 words rather than 2. When every window comes back that way the panel reads “No speech found” rather than showing a transcript of nothing, which on a 720-window replay is the outcome worth knowing about before you start.

How long will an hour of replay take?

27 to 63 minutes at the rate this machine measured, which is 9 to 21 seconds a window across 180 windows. The measurement behind it is a 2-window clip taking 18 to 42 seconds on a two-core, 4.2 GB machine, so the hour figure is arithmetic on that spread rather than a stopwatch reading, and it does not include the 79.7 MB model download that the first run of a session also carries.

Last checked: 22 October 2026. The byte figures are arithmetic from two inputs, both re-checked by printing them on this machine before they were written down: RATE = 16000 on line 236 of app.js and a decoded sample being 32 bits, so 16,000 × 1 × 4 = 64,000 bytes a second, 3,600 × 64,000 = 230,400,000 bytes for an hour, 14,400 × 64,000 = 921,600,000 bytes for four hours, and 14,400 × 44,100 × 2 × 4 = 5,080,320,000 bytes for the same four hours decoded at 44.1 kHz stereo. The window counts are derived from chunk_length_s: 30 on line 282 plus the library's 5-second default stride, recomputed window by window rather than assumed: 180 for an hour, 720 for four, 30 for ten minutes. The source counts were read from the deployed files on this machine — app.js is 22,349 bytes, live and replay occur 0 times in it, and the picker's 12 entries are 2 wildcards and 10 named extensions. The measured figures are this tool's own records from an ordinary browser tab on a two-core, 4.2 GB machine: a valid 20-minute WAV refused with EncodingError, a 43-second clip completing in 18 to 42 seconds, 54 words from that clip, and a music-only run once returning 2 words. No Instagram page reachable from here states a maximum length for a Live broadcast, so this page asserts none; the only length claim quoted is wayin.ai's “hour-long Live replay”, reproduced exactly from its Instagram transcript page, and the competitor counts are over 373,780 characters of the three sites' copy held in this site's benchmark directory.

If the clip you have is a Reel rather than a replay, the Reel length limit covers the ceiling that decides whether a long one transcribes at all, and transcribing a Story is the page for a post that expires instead of one that ran for hours. Private Reels is where to go when the post is behind a login, which is also the case wayin.ai's public-link requirement excludes. If a run comes back empty, the five failure modes separates a silent recording from a refused one, and what to do with a transcript covers the four outputs and what each costs. For a queue of files rather than one long one, bulk transcription explains why there is no batch button and what the 79.7 MB download costs on the first file against every file after it.