Why does my iPhone voice memo transcript have no punctuation?

Open a fresh transcript and the words are usually fine — sometimes strikingly so. Then you notice there is no comma where you paused, no question mark on the one sentence that was clearly a question, and somewhere around the third minute it stops trying altogether and just runs on. That is not the transcript failing. That is the transcript doing exactly what it was built to do, which turns out to be a narrower job than it looks like from the outside.

Two different problems wearing one face

Recognizing which words were spoken and deciding where a sentence ends are not the same task, even though a finished transcript makes them look like one. The first is pattern matching: a stretch of audio maps onto a sequence of words a model has heard a million variations of before. The second is closer to reading someone's mind — punctuation encodes intent, and intent has to be inferred from things audio only hints at: how long someone paused, whether their pitch rose or fell, whether they took a breath.

A recognizer is scored, trained and tuned overwhelmingly on the first problem, because that is the one with a clean right answer. The second problem does not have one. Two people transcribing the same recording by hand would not punctuate it identically either — they would just be better than a model at guessing which reading the speaker meant.

What the recognizer actually has to work with

Pauses, not grammar

Speech recognition does not parse grammar the way a sentence-diagramming exercise does. What it has is timing: silence between words. A long pause after a phrase is the strongest signal it gets that a sentence ended, so that is usually where a period shows up, if one shows up at all. A short pause for breath in the middle of a thought can get treated exactly the same way, or not at all — the model is measuring milliseconds, not meaning.

Pitch and rhythm, imperfectly

A question in English or French usually rises in pitch at the end; a statement usually falls. Some of that intonation makes it into a transcript as a question mark, some does not, and a flat, tired, or rushed delivery removes the cue almost entirely. Read a sentence in a monotone and a human transcriber would struggle to tell it was a question too — the model has the same problem, just more often.

Paragraphs get nothing at all

This is the part people notice most and explain least: transcripts frequently arrive as one continuous block with no paragraph breaks anywhere. That is not a missing feature so much as an absent concept — a paragraph break is a judgment about where one topic ends and another begins, and nothing in the audio marks that the way a pause marks the end of a sentence. Nobody's speech recognizer is inserting those, on-device or off.

Does it matter which recognizer ran?

iOS attempts on-device speech recognition first and only falls back to Apple's server if the local pass comes back empty or errors — the same mechanism behind how well the words themselves come out. Punctuation does not get noticeably more reliable on one path than the other, because both are solving the same guessing game with the same thin evidence: pause length and pitch, not an understanding of what you meant. Do not expect a transcript to read more like prose just because it ran on the server that time.

What actually helps while you are recording

There is no setting that fixes this, but how you speak changes how much the model has to guess with:

• A clear pause at the end of a thought gives the model something to key off. Running straight from one sentence into the next removes the one signal it has.
• A deliberate pitch drop at the end of a statement, or lift at the end of a question, is the same cue a listener uses — and the model is trying to use it too, just less reliably.
• One person at a time. Overlapping speech does not just cost the recognizer words, it destroys the pause pattern it needs to guess sentence boundaries at all.
• Slow down at names, numbers and technical terms specifically — not the whole recording. Those are the words most likely to come out wrong regardless of punctuation, so a small delivery change there is worth more than a small change anywhere else.

Fixing it after the fact, without retyping the whole thing

Punctuation and paragraph breaks are also the fastest things to fix by hand, because you are not correcting a wrong word — you are just placing marks a listener would place instinctively. Read the transcript once at a normal pace, the way you would proofread anything, and drop in a period or a line break wherever your eye expects one. It goes quickly because you already know what was meant; the model was guessing at exactly the thing you already know.

Doing this pass is worth more than chasing a better recording for the sake of punctuation alone. A cleaner room and a closer microphone genuinely help the words come out right — that part responds to quality settings and placement — but punctuation is downstream of pause and pitch, not clarity, so a pristine recording can still come back as one long run-on sentence.

How Voice Studio handles this

Transcription runs through Apple's speech engine, attempting the on-device path first, so whatever punctuation shows up is whatever that recognizer decided on — Voice Studio does not run a separate pass to add or remove it. What it does give you is a transcript that stays editable afterward: fix a comma, drop in a paragraph break, correct a name, and the correction stays without redoing anything else in the transcript.

Common questions

Can I make Voice Studio add punctuation automatically?

No — the transcript reflects whatever Apple's speech recognizer produced, on-device first, and the app does not run a separate pass to add or clean up punctuation. Editing it afterward is the reliable fix, and the transcript stays editable for exactly that.

Does speaking more slowly fix the punctuation?

Speaking more slowly overall does not, but leaving a clear pause between sentences does — that pause is the main signal a recognizer has for where one sentence ends and the next begins.

Is server-based transcription better at punctuation than on-device?

Not noticeably. Both are inferring sentence boundaries from pause length and pitch rather than meaning, so switching which one ran is unlikely to change how the punctuation reads.

Why does my transcript come out as one giant paragraph with no breaks?

Because a paragraph break marks where one topic ends and another begins, and nothing in the audio signals that the way a pause signals the end of a sentence. No speech recognizer inserts them — that structure has to be added by reading the transcript afterward.