How to Transcribe an Instagram Voice Note From a DM

Why the route starts with a recording

A voice note you received sits inside the conversation, and nothing there hands you an audio file. We cannot test the Instagram app from here, so read this page as being about the file rather than about the app: whatever you upload has to exist on your device first, usually by playing the note back and recording the screen. Everything measured below is what happens after that file exists.

Three notes in one recording: what comes back

We built a 21.37-second, 131,573-byte file holding three notes - two different speakers, each about 2.5 seconds of speech with a second of quiet either side and four seconds of gap between notes - encoded as 48 kHz stereo AAC, which is the shape a phone screen recording hands over. Uploaded twice, it returned the same 110 characters and 22 words both times.

• The whole thread as one file: 110 characters, 22 words, 2.24 s and 1.24 s on the repeat.
• Note 1 alone, 4.57 s and 45,318 bytes: 41 characters, 8 words, 1.93 s.
• Note 2 alone, 4.48 s and 43,281 bytes: 40 characters, 9 words, 1.11 s.
• Note 3 alone, 4.32 s and 40,805 bytes: 29 characters, 5 words, 0.75 s.
• The three separate uploads add up to the same 110 characters and 22 words, and cost 3.79 s of waiting instead of 1.24.

So one upload is faster and loses no words. What it does lose is the boundaries: nothing in the text says which sentence belonged to which note.

The text has no boundaries in it

Every upload today came back as a single run of sentences. Zero line breaks in all sixteen of them, no speaker label, no marker where one note ends and the next starts. Two people taking turns in the same thread come back as one uninterrupted voice, and if you need to know who said what, you have to know it before you upload.

Six notes in one file: order survives, repetition does not

We then built a 46.31-second, 258,147-byte recording holding six different notes from two speakers. It returned 218 characters and 44 words, in 3.09 s and 1.80 s on the repeat, and all six notes were in it. We checked the order two ways: silence detection on the recording found six separate speech blocks, and cutting a single note back out of the finished file returned only that note's sentence. The text came back in the order the notes occur in the file.

A second recording of the same length, 46.73 seconds and 264,592 bytes, held the same three sentences twice. It returned 112 characters and 22 words - three sentences, not six - identically on three uploads, even though silence detection shows six speech blocks in that file. If a thread recording contains the same note played more than once, do not expect it more than once in the text. That is the first way a thread recording loses words.

Re-encoding changes the file, not the words - except for one

The same 21-second thread re-encoded four ways returned the identical 110 characters every time.

• 48 kHz stereo AAC at 128 kbps, 131,573 bytes - 110 characters, 2.24 s and 1.24 s.
• 16 kHz mono MP3 at 64 kbps, 171,980 bytes - the same 110 characters, 2.06 s. It is larger on disk than the stereo file it was made from.
• AAC at 256 kbps, 235,840 bytes - the same 110 characters, 2.34 s.
• MP4 holding the same audio with a blank 720x1280 picture, 167,444 bytes - the same 110 characters, 1.31 s.

Playback level did not change it either: the thread at 40, 15 and 5 percent volume returned the same 112 characters in 1.51, 3.56 and 1.89 s. Neither did the interface - a 1.2 kHz notification sound at 0.2 s and a tap click at 6.0 s mixed into the recording still returned 112 characters in 2.21 s.

One word did move. The closing note came back as "Thanks top to you tomorrow" in five of the nine runs of that thread, and as "Thanks taught to you tomorrow" in all three runs of the six-note file. Uploading the same file again always gave the same text; changing the encoding could change that word. That gives you a cheap check: if one word matters, re-encode the recording, upload both, and diff the two texts.

The note nobody spoke into

A five-second note recorded with nothing said on it came back with 1,829 characters and 338 words - "Thank you very much" repeated, then "I'm sorry" repeated - in 9.44 seconds, with success:true. The same thing happened three times over when we cut silent stretches out of the six-note recording: each one returned the same 1,829 characters, in 15.37, 15.46 and 16.46 seconds. Those silent pieces took longer than any real note and came back longer than any real note's text. This is the second way a thread recording loses words, and it is the one that looks like a success.

The practical rule follows directly: trim the recording to where the voice is before you upload. A note that runs long because you left the recorder going is worse than a short one, not better.

Cutting a thread into one file per note

If you need to know which note a sentence came from, the recording has to be cut before it goes up, because the response will not tell you. Silence detection finds the boundaries for you.

• Run: ffmpeg -i yourfile.m4a -af silencedetect=noise=-40dB:d=0.3 -f null -
• It prints silence_start and silence_end pairs. The stretches between them are the notes.
• On our 21-second recording it found three speech blocks: 1.25 to 3.32 s, 9.79 to 11.95 s and 18.30 to 20.13 s.
• Cut each one out: ffmpeg -i yourfile.m4a -ss 1.25 -to 3.32 -c copy note1.m4a
• Upload the pieces separately. Each comes back on its own, which is the only way to keep note 1 and note 3 apart in the text.

What the response does not contain

All sixteen uploads today returned the same six fields: success, transcript, language, engine, fileSize and fileName. The language field read unknown in every one, the engine was Cloudflare Workers AI (@cf/openai/whisper), and there were no timestamps, no speaker labels and no line breaks. If your notes are in another language, the words come back in that language - but the language field will not tell you which one.

Where your file goes

The recording is posted over an encrypted connection to /api/transcribe, held in memory while the model reads it, and dropped once the response goes back. There is no account, no file library and no stored copy - which also means we cannot hand you the text again next week, so copy it out before you close the tab.