Why an Instagram Captions File Comes Back With No Timings

What came back from three lengths

We looped one spoken clip to 15, 30 and 60 seconds at 16 kHz mono and sent each one.

• 15 s / 121,004 B: 235 characters, 42 words, 3.49 s
• 30 s / 241,100 B: 492 characters, 89 words, 5.65 s
• 60 s / 481,004 B: 806 characters, 145 words, 5.58 s

All three returned HTTP 200 with success true. All three carried the same 6 fields, reported language as unknown, named the engine, and contained 0 line breaks. The text is one unbroken paragraph, so there is nowhere in it for a time to live.

What the caption files actually weigh

We ran the page's own download code in a browser on each of those three transcripts and measured the file it writes.

• 235-character text: TXT 235 B, SRT 268 B, VTT 274 B
• 492-character text: TXT 492 B, SRT 525 B, VTT 531 B
• 806-character text: TXT 806 B, SRT 839 B, VTT 845 B

SRT runs 33 bytes over TXT in all three cases, and VTT runs 39 over. The overhead doesn't grow with the transcript, and that's the tell. A real caption file's size is driven by how many cues it holds and how long each one runs. A flat 33 bytes means one cue, added once.

The cue says zero to zero

Here is the whole SRT the page writes for the 235-character transcript: an index line, then 00:00:00,000 --> 00:00:00,000, then every word of the transcript as one block. Start and end are the same instant, so the cue is on screen for 0 seconds.

That isn't a bug we can quietly patch. The model returns text, and we don't get word timings from it. Splitting the text evenly across the clip's length would produce timings that look right and are wrong, so we don't do it.

We proved it with a media container, not by eye

Numbers in a text file are easy to argue about. So we put both files into a real MP4 and asked a player how long the subtitle track lasts.

• Our SRT muxed into a 60-second MP4: subtitle stream duration 0.000000 s
• Three hand-written cues ending at 25.66 s, same container: 25.660000 s, 6 packets

Same container, same muxer, same command. One track has no duration at all. The other reports 25.66 seconds across 6 packets. That is the gap between a caption file and a transcript with a header on it.

How many cues a real file would need

Our 60-second clip came back with 806 characters and 145 words - more text than fits on a phone screen at once. A caption file for it would need several cues of two or three seconds each, every one with a start and an end.

Our file has one cue holding all 145 words, and it sits on screen for zero seconds. So the file isn't 90% of the way there. It's a container with a header and the text, and the timing work is all of it.

What to do with it

Use the TXT when you want words - a quote, notes, a script, a blog post. Use the SRT or VTT as a starting block in a subtitle editor and set the cues yourself. If you need captions burned into a published video, the timing has to come from somewhere, and today it isn't from us.

One thing does hold up: the words are the words. All three lengths came back with the same opening sentence in the same order, so what you're fixing is timing, not text.