How accurate is an Instagram transcript — and how do you check one?

Nobody can hand you a percentage that means anything, so check the three places errors actually collect. On one clean 161.2-second recording — one speaker, no music, no crosstalk — this tool returned 338 words in 27 segments, and 19 of those words were wrong: 5.62%, which is 94.4% right. The mistakes were not scattered evenly. Four were proper nouns, three were homophones, and seven were one phrase repeated at a chunk seam. So: read every name once, listen to the twenty-second marks, and count the words yourself — the panel’s count is not the count in the file you download, and none of the 22,349 bytes of app.js contains a confidence score you could read instead.

The rest of this page is the working behind that answer: the full error list from that 161.2-second run and where each error came from, the arithmetic that says a seam falls every twenty seconds and that seven of the eight in this recording landed inside a segment rather than between two, the three counts that disagree on one screen and why, the two model files whose sizes differ by 1.88×, and what the three pages that outrank this one say about accuracy across 111,530 characters of their own Instagram copy — which is a badge and a heading, and no method at all.

What the number looks like when you actually count it

I ran a public-domain recording of a speech through this page on this machine: 161.2 seconds, one speaker, studio-quiet, English, no music bed. The panel came back with “338 words · 27 segments · transcribed in 71.4s”. Then I put the transcript beside the text that was read and counted, word by word, every place the two disagreed. Nineteen words of 338 were wrong — 5.62% — and the run itself took 0.443 seconds per second of audio.

• 19 wrong words out of 338 is 94.4% right, on the easiest material there is. That is not a benchmark score and it is not a word error rate from a scored test set — it is one recording, counted by hand against the text that was read, with the reader assumed to have used the standard wording. 161.2 seconds of clean speech produced 338 words, and 19 of them had to be changed before the transcript could be quoted.
• The errors arrived in 11 places, not 19 places. Twelve words were substituted, dropped or inserted one at a time — 3.55% of the document — and one place repeated 7 words in a row, which is the remaining 2.07%. That shape matters: a transcript that is 94.4% right is not uniformly 94.4% right, it is a clean document with eleven specific holes in it, and eleven is a number you can check in a few minutes.
• The cost per second of audio was 0.443 seconds here, and 0.419 seconds on a 600-second Reel. 71.4 seconds of work for 161.2 seconds of speech is 2.26× faster than real time; the long run took 251.5 seconds for 600.3 seconds. Two different files, both on this machine, both on the larger of the two checkpoints — the per-second cost barely moves with length, so a two-minute clip and a ten-minute clip are equally worth checking.
• The audio itself was 10,316,800 bytes of PCM. 161.2 seconds at 16,000 samples a second, one channel, a 32-bit float per sample, is 64,000 bytes a second — fixed by the Web Audio spec rather than chosen here. Every one of those 10,316,800 bytes went through one decode of the model, and there was no second pass to compare it against.

Check one: the names, and the words that sound the same

Four of the twelve substituted words were proper nouns and three were homophones, which is 7 of 12 from two categories you can scan for deliberately. The model has never seen the name of your guest, your product or your client, and it has no way to ask. It has also, in this recording, been unable to tell “here” from “hear” in either direction — twice, 60.18 seconds apart.

• A brand the model had never met came back wrong three times, the same way each time. The recording opens by naming a publisher and its website. The model wrote both with the same wrong vowel, and wrote the domain with it too — three errors, one cause, and 15.8% of the 19 wrong words in the file. The consistency is the tell: a name it half-knows gets the same wrong spelling everywhere, so one correction fixes all three.
• “Address” became “Addressed”. The title of the speech ends in a word that is both a noun and a verb form, and the model chose the verb — 1 of the 4 proper-noun errors, at 27.82 seconds. It is one character of difference and it makes the sentence unquotable, which is why titles belong on the list beside names rather than with ordinary words.
• “here” became “hear” twice, 60.18 seconds apart. Once in “those who hear gave their lives” at 66.82 seconds, where the text says “those who here gave their lives”, and once in “we hear highly resolve” at 127 seconds, where the text says “we here highly resolve”. Both are homophones, both survive a spell-check, and neither changes how the sentence sounds when you read it back — which is exactly why reading the transcript aloud to yourself does not catch them.
• The date came back right, and that is the point of checking numbers one at a time. “November 19, 1863” was transcribed correctly in the same run that turned “Four score” into “For four”. A blanket rule like “the model is bad with numbers” would have had you re-checking a date that was already correct while the two-word phrase that was wrong sat three lines further down.

Check two: the seam, every twenty seconds

The recogniser does not read your file in one pass. app.js asks for chunk_length_s: 30 at line 282 and never sets a stride, so the library falls back to chunk_length_s / 6 — 5 seconds — and then advances by window - 2 * stride, which is 30 − 10 = 20 seconds. Those three lines are in the library, not in this page: the default is at line 1834 of the pipeline module and the jump is computed at line 1843. The consequence is that every second of your audio is recognised one and a half times, and every twenty seconds there is a join.

• 161.2 seconds is 8 windows and 8 seams. The windows start at 0, 20, 40, 60, 80, 100, 120 and 140 seconds; the last one runs to 161.2. Seven of those eight instants fall strictly inside a segment — 40, 60, 80, 100, 120 and 140 do, and 20 does not because a segment happens to begin exactly there. So the transcript has no visible break at a seam, which is why the seam is invisible until you look for it.
• One seam produced a 7-word repeat. At the 100–110 second overlap the transcript says “say here, but it can never forget” and then says it again, prefixed with two words that turn the earlier “what we say here” into a second, wrong clause. Seven words duplicated out of 338 is 2.07% of the document from one join, and it is the single largest error on the page — bigger than any one wrong name.
• The overlap is 320,000 bytes of audio per window, re-read every time. Five seconds at 64,000 bytes a second. That is the material the stitcher has to reconcile, and it is also why a repeated phrase is the failure mode rather than a missing one: both windows heard those words, and both were allowed to keep them.
• A ten-minute Reel gets 30 windows and 29 seams, and 111 segments came out of it. 3.7 segments per window on the long run against 3.4 on the short one, so the seam density per segment is roughly the same at both lengths: one join for every 3.7 segments you read. On a long transcript the joins are not rarer, there are simply more of them.

Check three: three different counts on one screen

The panel says “338 words · 27 segments”, and neither number is the number of words or lines in the file you download. That is not a bug and it is not hidden — it is three separate filters, each doing something the other two do not, and if you use the panel number as your word count you will be short. On the 161.2-second run no segment and no cue was dropped — the panel’s 27 segments and the .srt’s 27 lines matched exactly, which is why the gap is easy to miss until a file where the filters bite.

• The word count is taken after bracketed annotations are stripped. Before counting, render() runs a 20-character regex — \[[^\]]*\]|\([^)]*\) — that removes both square-bracket and round-bracket annotations. Measured earlier on a music-only clip, the model returned “(smooth music)”, which the old count read as 2 words; the visible text still contains the annotation, so a word count taken from the text and a word count taken from the panel disagree by exactly those 2. On the 161.2-second recording there were 0 annotations, so for once the panel and the text agreed at 338 words.
• Segments are fewer than chunks, because empty ones are dropped. toSegments() skips any chunk whose start is not a finite number and any chunk whose text is blank after whitespace is collapsed. On a four-chunk run measured on this machine, 4 chunks became 3 segments — 1 in 4 gone before a cue existed. On the 161.2-second run the 27 segments that survived averaged 5.97 seconds each.
• Cues are fewer than segments, because zero-length ones are dropped. subtitleCues() keeps only cues whose end is after their start, and toSegments() clamps a missing end to the start. The same 3 segments produced 2 cues, so the .srt has one line fewer than the panel has segments — a difference of 1 line that looks like a lost sentence and is not. On the 161.2-second run 0 of the 27 segments had a zero-length span, so that .srt kept all 27 lines and the three counts only disagreed on the shorter file.
• A timestamp is only good to one millisecond, which is 16 samples. stamp() rounds the total to whole milliseconds before splitting it, so every timestamp is 12 characters and the smallest step it can express is 1 ms. At 16,000 samples a second, 1 ms is 16 samples — so a cue boundary read off a subtitle file is accurate to 16 samples at best, and any measurement finer than that is measuring the stamp rather than the speech.

Why the tool cannot just tell you how accurate it was

There is no confidence number to read, because the code never asks for one. Across the 22,349 bytes of app.js, no_speech_prob appears 0 times, avg_logprob 0 times, confidence 0 times, score 0 times, temperature 0 times, beam 0 times and word_timestamps 0 times. return_timestamps appears once, at line 281, set to true — sentence-level timings, not word-level. There is one decode, no second attempt at a different temperature, and nothing to compare the first attempt against.

• The only accuracy lever you control is which checkpoint loads. The larger one is 76,894,612 bytes of q8 weights — a 23,201,297-byte encoder plus a 53,693,315-byte merged decoder — and the smaller one is 40,844,231 bytes, a 10,124,990-byte encoder plus a 30,719,241-byte decoder. That is 1.88× the weights for the larger model, and it is the difference between the two menu entries labelled “better accuracy” and “smaller download”.
• The two figures the page already quotes reconcile to the byte. The progress bar’s measured total for the larger model was 79.7 MB; subtract the 76,894,612 bytes of weights and 2,805,388 bytes are left for the tokenizer, the configs and the rest. Add that same 2,805,388 bytes to the smaller model’s 40,844,231 and you get 43,649,619 — 43.6 MB, which is the figure this site has been quoting for the smaller checkpoint all along. Two numbers measured months apart, one subtraction, no remainder.
• One decode means one opinion, so a homophone is decided once and kept. With no beam search and no temperature fallback in the 22,349 bytes, the “hear”/“here” choice is made by the same single pass that produced the other 337 words. Nothing in the output marks the words the model was unsure about, so the 19 wrong words in that 338-word transcript are indistinguishable from the 319 right ones until a human reads them.
• And the panel gives you one number that is genuinely useful: 71.4 seconds. That is how long 161.2 seconds of audio took on this machine, and it is the only measured quantity in the output that describes the run rather than the text. If a two-minute clip takes far longer than that, the machine is busy rather than the file being hard, and the transcript is not more or less accurate for it.

What the three pages that outrank this one say about accuracy

Across the 10 Instagram pages the three sites publish — 111,530 characters of body text once the heading lists and the scraper’s metadata are stripped, split 87,474 on wayin.ai, 14,805 on speakapp.com and 9,251 on getthescript.app — accuracy is asserted 3 times as a number and explained 0 times.

• speakapp.com puts “99% Accuracy” on all three of its Instagram pages. It is a badge in the row of five beside “50+ Languages” and “Instant Results”, on the Instagram transcript, transcribe-Instagram-video and Instagram-audio-download pages alike. The same page carries the testimonial “The accuracy on names is genuinely surprising” — which is the one place a name is mentioned, and it is praise rather than a check. Across its 14,805 characters of Instagram copy there is no method, no sample and no failure case.
• speakapp.com asks the question and does not answer it. Its FAQ block lists six headings, one of which is “How accurate is the transcription?”. In the body text captured from that page, all six appear as headings with no answer beneath any of them — the 14,805 characters contain the question and the badge, and nothing that tells you what to do about a wrong word.
• wayin.ai uses “verify” once, and not about accuracy. The sentence is “WayinVideo even includes timestamps and direct quotes, so you can click to jump straight to the original position to verify the details” — a way to find the moment, on the summariser page, not a way to decide whether a word is right. Its Instagram transcript page says “you will receive a highly accurate text output” and stops there. One use of the word across 87,474 characters, and it is about navigation.
• getthescript.app puts no percentage on its Instagram pages at all. The word “accurate” appears 2 times across its 9,251 characters and both are inside the same boilerplate sentence, “instantly converts Instagram Reels, YouTube Shorts, TikTok, and more into accurate text transcripts”. Its 95%+ figure lives on a different page, about a different input.
• 0 of the 111,530 characters tells you where the errors are. No page names the chunk seam, the homophone, or the difference between the count on screen and the count in the file. A badge says how good the tool is on average; it cannot tell you which eleven words in your transcript are the wrong ones, and that is the only question that matters when you are about to quote somebody.

Is 94.4% good enough to publish?

For a first draft, yes; for a quotation, no. 19 wrong words in 338 is a document you can fix in about the time it takes to read it once, and the eleven places are findable because they cluster: names, homophones and one seam. The test is not the percentage, it is whether the sentence you plan to quote contains a proper noun, a here/hear, or a phrase that repeats itself — those three account for 12 of the 19 wrong words, 5.62% of the document.

Does the smaller model make the errors worse?

It changes which errors you get, and it is 36,050,381 bytes smaller — 40,844,231 bytes of weights against 76,894,612. The 19-word count above is from the larger checkpoint; the smaller one is the entry labelled “smaller download”, so if accuracy is the thing you care about, that is the wrong menu item to pick, and the panel will tell you which one ran in the line under the transcript.

Can I check a transcript without the original audio?

Partly. Two of the three checks work on the text alone: a repeated phrase is visible without hearing anything, and a proper noun you already know the spelling of is visible too. The homophones are the ones that need the audio, because “those who hear gave their lives” reads perfectly well until you play the eight seconds around it — and the timestamp in front of that line tells you exactly which eight seconds: 66.82 seconds into the file, on a line whose stamp is 12 characters long.

Why does my transcript repeat a phrase that was said once?

Because two windows both heard it. The recogniser reads 30 seconds at a time and steps forward 20, so ten seconds of every window are transcribed twice, and the stitcher is what decides which copy to keep. In the 161.2-second recording that produced a 7-word repeat at the 100–110 second overlap — the largest single error in the document, and the only one you can find by searching for a phrase that appears twice in a row.

How long should a transcript take to make?

About 0.443 seconds per second of audio on this machine with the larger checkpoint: 71.4 seconds for 161.2 seconds of speech, and 251.5 seconds for 600.3 seconds on a longer file. A two-minute Reel is therefore a minute or so of waiting, and the model download is a separate cost that happens once, at 79.7 MB for the larger checkpoint.

Last checked: 28 October 2026. The error list is from a 161.2-second public-domain recording transcribed by this page on this machine, then compared word by word against the text that was read: 338 words, 27 segments, 71.4 seconds, 19 wrong words in 11 places, of which 4 are proper nouns, 3 are homophones and 5 are single substitutions, plus a 7-word repeat — counted by script here, not estimated. The 0.443 and 2.26 figures are that division; 0.419 is 251.5 ÷ 600.3 from the separate 600-second run recorded on 27 October. The window arithmetic is read from the pipeline module: stride_length_s defaults to chunk_length_s / 6 at line 1834 and jump = window - 2 * stride at line 1843, with chunk_length_s: 30 set at line 282 of app.js. The 8 windows, 8 seams, 7-inside-one-segment and 3.7-segments-per-window figures were computed from the timestamps in that run’s own output, not assumed. The source counts are from the 22,349-byte app.js as deployed: no_speech_prob, avg_logprob, confidence, score, temperature, beam and word_timestamps 0 times each; return_timestamps 1 time at line 281. The model byte sizes are the q8 encoder and merged-decoder files listed by huggingface.co for both checkpoints on 28 October, and the 2,805,388-byte remainder is 79.7 MB minus those weights — an inference from two measured totals, not a file listing. The 111,530 characters of competitor copy cover 10 Instagram pages in this site’s benchmark directory, measured after the heading lists were stripped. The 0.443-second rate is this machine with the larger checkpoint; a phone will be slower.

If the words came back empty rather than wrong, the no-captions page covers the two files that produce nothing at all. If you want the timings that make check two possible, the timestamps page covers the 12 characters in front of every line, and the SRT and VTT page covers why the cue count is lower than the segment count. The long-Reel page has the full 600-second run quoted above, and what to do with a transcript covers the exports this page counts.