Transcribing an Instagram Reel in Hindi — do I have to pick the language myself?

Yes, and the picker is the only thing that decides it. There is no “Hindi mode” and nothing reads the audio to work the language out: Hindi is one entry in a list of 99, token id 50276, and whatever entry is selected is handed to the model once at line 279 of app.js before the first window of audio is cut. The audio cannot add a language to that list or remove one from it — only the picker can. Pick Hindi for Hindi speech and it transcribes in Hindi; leave it on English, which is what the page opens with, and the same audio comes back as fluent English-shaped text rather than an error.

None of this has anything to do with where the Reel came from, so uninstalling nothing and signing into nothing changes it either. What follows is the list itself: the 99 ids and where Hindi sits among them, what the picker carries into the decoder on each window, the one shape of Reel that a single language cannot cover, the failures that look like a language problem and are not, and what the three sites that rank above this one say about language across 263,728 characters of their own Instagram copy.

The picker is a list of 99 ids, and Hindi is the 18th

The list is not typed into the page. languageCodes() fetches generation_config.json from the model repository, reads the keys of lang_to_id, and settles them into the <select> as the picker’s 99 options, in id order. Fetched on 5 November 2026, both checkpoints this page offers — onnx-community/whisper-base and onnx-community/whisper-tiny — returned the same 99 keys spanning 50259 to 50357.

• Hindi is 50276, which is the 18th entry. English is 50259, the first. Hindi is 17 ids above it, so in this browser every language before Hindi writes 51 bytes into the picker and Hindi itself writes bytes 52 to 54 — three bytes for hi, drawn from the 297 bytes that the whole list adds up to, or 1/14 of the total text of the control. It is a one-word item in a 99-word list, and that is the entirety of what “Hindi support” is on this page.
• Telugu and Tamil are in the same list, and closer to it than the tag would suggest. Tamil is 50287, the 29th entry in the list, and Telugu is 50299, the 41st. All three are options in the same picker, so a set of Reels in Hindi, Telugu and Tamil needs the picker changed twice between runs, not a different tool.
• Nothing detects anything: no auto, no unknown. Line 279 passes language: lang on every run, and lang is $('lang').value read at line 257. There is no branch that passes null, which the recognition library documents as the value that turns detection on. The 99 keys contain no entry for letting the model decide, so the picker can never express it either.

What the chosen language actually reaches

The picker is read once per run, not once per window. app.js hands the same language to the pipeline beside task: 'transcribe', return_timestamps: true and chunk_length_s: 30, and those four arguments are spread into a single generation config before any audio is cut. That is why the language question and the Reel-length question are the same arithmetic.

• Each window is 480,000 samples, and there is one token per window. 30 seconds × 16,000 Hz = 480,000 samples, which at 4 bytes a sample is 1,920,000 bytes of float32. The 30-second Reel is the only length where there is no repeat, because it is 1 window and 1 token; a 60-second Reel is 2 windows and 2 tokens, so the Hindi token is put in 2 times for the same setting.
• A Reel of 2 minutes is 4 windows by the 30-second cut. 120 ÷ 30 = 4, and the audio that has to live in memory to get there is 1,920,000 frames × 4 bytes = 7,680,000 bytes of 16 kHz mono before the first chunk is decoded. The same minute of the same Reel, kept at 48 kHz stereo, is 23,040,000 bytes — 6 times the mono copy — which is why the decode step to 16 kHz mono happens before the model is even loaded.
• The second Reel is cheap; the first is not. The Hindi token does not cost a download; the model around it does. First run on a new browser pays 79.7 MB for the better-accuracy checkpoint or 43.6 MB for the smaller one, then the second Hindi Reel pays nothing extra. Three or four Reels in a row is the cheapest way to spend that download.

The one Reel shape where one language is not enough

A Reel that stays in one language — Hindi commentary, Hindi interviews, Hindi monologue with English brand names dropped in — needs one setting and nothing else. The case that breaks is a Reel that switches language mid-file while the picker holds a single value for the whole run.

• Half and half is the same failure as the wrong one, only shorter. The model does not get a second chance at the part it heard in the other language; the same token is at the front of every window, so the second half is decoded as if it were Hindi too. The output is continuous, timestamped and confidently wrong in exactly one half, and nothing in the .txt, .srt or .vtt records which half that was.
• The repair is arithmetic, not a setting. Run the file once as-is, note where the language changes, then run the two halves separately with the picker changed between them. On a 2-minute Reel that is 4 windows in the first pass and 4 more across the two half-runs, so 8 windows in three runs instead of 4 in one — twice the compute for a transcript you can trust line by line.
• Hinglish is not this case and is not Hindi. A Reel whose Hindi is written out in Latin letters is already in the alphabet the English entry expects, which is a different problem from a Hindi Reel: the deliverable changes, and a Devanagari transcript is not what was asked for. Treat it as its own question rather than as a Hindi one with the picker set wrong.

What looks like a language problem and is not

Four failures get blamed on the language picker and only the first is the language picker. The other three are recognised by where they break and what the page says about them, and none of them can be fixed by choosing a different entry.

• Wrong entry, fluent output. This is the one that is the picker. It produces a transcript with a word count and a timestamp on every line, and the panel heads it “Transcript” because it is not empty. The site’s own recorded measurement: an English clip with 54 words, run with the picker set to Spanish, came back as 404 words of repeated Spanish — 7.481 times the count of the speech and 350 words that were never said. Nothing in that panel is flagged, so the check is a check you do, not one the page does.
• Nothing to decode is not the same as nothing spoken. A file the browser cannot read at all stops before the model is ever loaded, because toPcm() decodes first and only then calls loadModel(). Three different problems — a 77-byte text file renamed .mp4, a valid 20-minute WAV that is larger than the tab can hold, and a WebM with a picture and no audio track — all reject with the same EncodingError and code 0, so the message names all three rather than guessing which one you have.
• Music with no voice is stripped before it is counted. A 20-character expression, \[[^\]]*\]|\([^)]*\), deletes both bracket styles, which is why a clip that only carried a music bed is reported as “No speech found” rather than as a transcript of “(smooth music)”. A Hindi Reel with the track loud and the speech quiet does the same thing, and no language entry brings those words back.

The picker labels are in English, whatever your browser speaks

The 99 options are named by new Intl.DisplayNames(['en'], { type: 'language' }), and the 'en' in that call is hard-coded. Every visitor gets the same English labels, so the entry you are looking for reads “Hindi”, “Tamil” and “Telugu” on a Hindi phone, a Tamil phone or an English one. That is a deliberate trade: the label has to match the file the model ships with, since the same call is what builds the list.

• The label can be traded for the code. Before the list arrives from the repository — and permanently, if that request fails — the picker holds only the English option that is written into the markup, and a warning says so in as many words. Once it arrives, the raw codes can be shown in place of names. Either way, what reaches the model is the id, and the id does not depend on the label.
• The empty picker is not a Hindi problem. The picker fills from a network request to the model repository, so a blocked or failed request leaves English only until the page is reloaded. The transcript will run — in English — and nothing about the audio will tell you the list is short.

What the three sites that rank above this one say

Their Instagram copy is 263,728 characters across 33 pages as of 5 November 2026. “Hindi” appears once in all of it, in a list of four example languages. “Telugu” and “Tamil” appear 0 times. “Auto-detect” appears 3 times and every one of them is a feature claim rather than a method.

• speakapp.com, on its Instagram transcribe page, sentence as printed: “The tool supports over 50 languages, so it works whether the Reel is in English, Spanish, Portuguese, or any other language. Auto-detection means you don’t even need to specify the language.” The 50 is stated and not derived, and no named non-English example is given.
• speakapp.com, on its Instagram transcript page, sentence as printed: “The model handles 50+ languages and detects them automatically, so a video in Spanish, Portuguese, Hindi or Japanese works exactly the same way an English one does.” This is the single occurrence of “Hindi” in 263,728 characters, and it says nothing about what the transcript looks like or what happens when the guess is wrong.
• getthescript.app: “detect” does not appear on its Instagram transcript page at all. It describes its output and never describes how a spoken language is chosen.
• What is missing from all four is the same thing: nobody says which language a wrong choice produces in place of the right one, and nobody gives a cost for getting it wrong. That is why the 54-word measurement matters more than any list of supported languages, and why it is worth writing down in the picker’s own words before you judge a transcript.

Last checked: 5 November 2026. The 99 keys, the id range 50259 to 50357, and the specific ids for Hindi (50276), Tamil (50287) and Telugu (50299) were read from generation_config.json of both onnx-community/whisper-base and onnx-community/whisper-tiny on this machine on that date, as were the forced_decoder_ids of [[1, null], [2, 50359]] and decoder_start_token_id 50258. The byte counts — 3×99 = 297, 1/14 of the list in three bytes, 480,000 samples and 1,920,000 bytes a window, 7,680,000 bytes for a 2-minute Reel, 23,040,000 bytes for the same minute at 48 kHz stereo, and the 6-to-1 ratio between them — are derived from the Web Audio rule that a sample is 32 bits and printed and re-checked before they were written here, with the 16,000 Hz rate, the 30-second chunk and the 4-bytes-a-sample figure taken from app.js’s own RATE = 16000 and chunk_length_s: 30. The 79.7 MB and 43.6 MB model sizes, the 54-word and 404-word measurement, the 7.481 ratio and the 350-word difference are this site’s own recorded runs in an ordinary browser tab on a two-core, four-gigabyte machine. The 33 competitor pages and 263,728 characters are this site’s own benchmark copy, not the internet. Nothing here is a search-volume or difficulty estimate — none was available and none was invented.