Why does my iPhone transcript stop partway through the recording?

A transcript that stops is a specific and confusing shape of failure. Unlike a blank transcript, this one clearly worked — the first few minutes read correctly, names are right, the pacing looks normal — and then, part way through, nothing. No error, no retry, just silence where text should be. It looks like the app crashed or lost interest. Usually neither is true.

Why a long recording isn’t recognized as one piece

iOS speech recognition — the same Speech framework every transcription app on iPhone calls into — is not built to hand a ninety-minute file to a model and get one answer back. Long audio gets worked through in sections, and each section is its own attempt at recognition. When a section succeeds, its text lands in the transcript. When a section fails, it simply contributes nothing, and the app moves on to whatever came after it if it can, or stops if it cannot.

That is the mechanical reason a transcript can look complete for a while and then run out. It is usually not one single catastrophic failure — it is one section, somewhere in the middle or near the end, that came back empty.

Why it doesn’t just fix itself with a retry

On-device recognition is attempted first, and only falls back to a server pass if the attempt comes back completely empty or throws an error. That fallback logic is checking the outcome of the request as a whole. A recording that produced fifteen good minutes of text and then nothing is not, from that check’s point of view, an empty result — it produced something. So the condition that triggers a retry never fires, even though the part that failed would have benefited from one.

This is worth knowing because it explains something that otherwise looks like a bug: re-running the exact same transcription on the exact same file usually reproduces the exact same cutoff. The audio has not changed, and the section that failed the first time has no new reason to succeed the second.

What actually causes a section to fail

The recording runs long

The longer a file is, the more individual sections it gets split into, and the more chances there are for one of them to land on something the model cannot handle. A five-minute voice memo has far fewer opportunities to fail this way than a two-hour interview.

A stretch of quiet, noise or silence

A pause where someone gets up to refill a coffee, a burst of background noise, or several minutes of near-silence in the middle of a recording gives that section very little usable speech to recognize. If it comes back with nothing, that gap is what shows up as the transcript ending — even if people start talking again perfectly clearly a minute later in the audio itself.

Distance or volume changes partway through

If the phone stayed in one place but a speaker moved further away, turned away from the microphone, or the room got noisier as the recording went on, the audio quality for later sections can be genuinely worse than for earlier ones — even though it is the same file, same phone, same setting throughout.

What is worth trying

• Play the recording from roughly where the transcript stops. If people are still audible and clear there, the audio itself is fine — the transcript is missing text, not evidence that the recording failed.
• Re-run the transcription. It will often reproduce the same cutoff, but if the first pass happened without a network connection, doing it again while online gives the fallback path a chance to reach a section the on-device pass could not.
• For anything you record regularly at length — lectures, long interviews — treat the second half as worth a manual listen rather than assuming the transcript covers all of it.
• Fill in the missing stretch by ear rather than discarding the whole transcript. The part that worked is still accurate, and it already saved you the work of typing it.

How Voice Studio handles this

Voice Studio transcribes through Apple’s Speech framework the same way described above: on-device recognition first, with a fallback to Apple’s server only when a pass comes back entirely empty or errors. A transcript that stops partway through a long recording means one section did not produce text while the sections around it did — the recording itself is untouched, and the audio for the part the transcript missed is still there in the .m4a to play back or transcribe again.

Common questions

Does a transcript that stops mean part of the recording is missing?

No. The audio file and the transcript are separate. A cut-off transcript means recognition did not produce text for that stretch — the recording itself still has all of it, and you can play or re-transcribe that section.

Will re-transcribing the same recording fix a cutoff?

Usually only if something about the conditions changed, most commonly going online when the first attempt was offline. If nothing changed, the same section tends to fail again.

Does this happen more on longer recordings?

Yes. Longer audio is worked through in more sections, so there are more opportunities for one section to come back with nothing. A short recording has less room for this to happen.

Is a cut-off transcript the same problem as a blank transcript?

Related but not the same. A blank transcript means recognition failed for the whole recording. A cut-off transcript means it worked for part of it and then stopped — the earlier text you already have is still accurate.