Guide
Your meeting recording cut out halfway through
The first twenty minutes are perfect. Everyone is there, the transcript reads cleanly, the speakers are separated. Then, at some arbitrary moment nobody noticed at the time, the other participants stop appearing. Not gradually, not garbled. They are simply gone, and you are the only person in the second half of your own meeting.
Published 2026-08-14
What actually happened
A recorder running on your own Mac, rather than joining the call as a bot, captures two separate things. Your microphone, and the audio your computer is playing. The second one is how the other participants get into the recording at all, and it is the one that failed.
A capture of your computer's output audio has to decide which applications it is listening to. It resolves that once, at the moment the capture starts, and then holds that answer for the rest of the recording. That works exactly as long as the underlying audio arrangement stays put. If macOS tears down and reassembles its audio graph mid-meeting, the answer the capture is holding becomes stale, and it goes on faithfully listening to something that no longer produces anything.
Why nothing warned you
This is the part worth internalizing, because it explains why a recorder you trust can do this to you without a single error message.
We traced one of these end to end against the system log. The capture stream ran for 69 minutes without interruption. It delivered its buffers on the same schedule from the first minute to the last. It reported the identical frame count at every reporting interval. It raised zero errors, never hiccuped, and never reported an end of stream. Every single health signal a recorder normally watches was green for the entire hour, including the half hour during which it was recording nothing.
The only thing that changed was the content of the buffers, and a recorder that asks whether it is running will never look there. It will conclude, correctly and uselessly, that it is running.
In that particular case nobody touched anything. No headphones were connected or disconnected, the output route was the same before and after, and the only thing the log showed at the moment of death was one background application releasing an audio session and the audio device manager bringing devices back up a few seconds later. A second conferencing app was open. That was enough.
Detecting it while the meeting is still happening
Since nothing in the stream's state gives it away, the only place left to look is the audio itself. That sounds obvious and it has one genuinely hard part: telling a broken capture apart from a quiet meeting. A naive silence detector conflates them and will interrupt every thoughtful pause in every real conversation you have.
The distinction that holds up is exact digital silence rather than quiet. A live capture carries a continuous low level noise floor even when nobody is talking, so it measures low but never reaches zero. A capture that has been silently disconnected produces literal zeros, sample after sample, which is a signature no real room and no real call produces. In the recordings we measured, the longest run of digital silence on a healthy live capture was about two seconds. Setting the alarm tens of times above that leaves an enormous margin: it can fire on a dead capture without ever firing on a pause.
- Rebuild the capture first. A stale snapshot is repairable, and a rebuilt capture starts working again immediately, so the automatic attempt should come before anything that interrupts you.
- If it cannot be repaired, say so on screen and do not let the warning be dismissed by accident. You are the only person who can decide whether to keep going, move to a phone, or ask for a recap.
- Stop attributing the missing audio to anyone. A span where the far end was never captured should be marked unverified in the transcript rather than credited to the one person whose microphone still worked.
The failure underneath the failure
That third point is the one that does lasting damage. When the far end of a call goes quiet but your own microphone keeps working, a transcript that has not been told about the failure does not produce a gap. It produces a confident, complete-looking record in which you appear to have said things you did not say, because yours is the only voice left to attribute them to.
A visibly incomplete transcript is an inconvenience. A transcript that quietly puts other people's words in your mouth is a different category of problem, and it is the reason we treat capture health as a correctness feature rather than a diagnostics nicety. We wrote about that failure specifically in when a meeting transcript names the wrong speaker.
What to do if it already happened to you
- The missing audio is not recoverable. If the samples were never captured there is nothing in the file to repair, so spend the effort on the recap rather than on the recording.
- Check the part that was captured, and check who it is attributed to. If your tool credited the missing stretch to you, correct it before that transcript gets shared or searched.
- Before the next meeting that matters, record ten seconds, stop, and play it back. A timer proves the recorder is running. Playback proves it is capturing.
- During meetings, watch a live input level rather than a timer, and confirm it moves when somebody else is talking, not just when you are.
How Stillnote handles it
Stillnote monitors both captures continuously while a meeting is recording, on your Mac, against measured thresholds rather than guessed ones. When the far end goes digitally silent it rebuilds the capture automatically before it interrupts you, and if the rebuild attempts do not bring it back it says so on screen rather than letting you find out afterwards. Audio over a span that was provably never captured is marked unverified in the transcript instead of being attributed to you.
All of that runs locally. Recording, transcription, speaker separation, and summaries happen on your own machine, no bot joins the call, and nothing is uploaded.
A recording that cut out mid-meeting: common questions
Why did my meeting recording capture the first half and then go silent?
The most common cause on a Mac is that the audio graph was rebuilt while the recording was running. A capture of your computer's output audio resolves which applications it is listening to once, when it starts. If macOS later tears down and reassembles the audio graph, that snapshot goes stale and the capture is left listening to something that no longer produces anything. The capture does not error and does not stop. It keeps delivering perfectly timed silence for the rest of the meeting.
What causes the audio graph to be rebuilt mid-meeting?
Any application starting or stopping audio can trigger it, which is why this is far less exotic than it sounds. A second conferencing app launching in the background, a browser tab releasing an audio session, a media player opening, a notification sound, or a device being added are all enough. You do not have to touch anything. In the case we investigated most closely, nobody changed a device, nobody unplugged anything, and the output route was the same before and after.
Is this the same as unplugging headphones mid-call?
It has the same outcome and a different trigger. Connecting or disconnecting headphones changes the default output device, which orphans a running capture directly. A graph rebuild does not require any device change at all. Both leave you with a capture that is technically alive and substantively empty, so the detection has to work the same way for both: measure what is arriving, not whether something is arriving.
Why does the recording still look healthy while this is happening?
Because every signal a recorder normally watches stays green. In the failure we traced, the capture stream ran for 69 minutes continuously, delivered its buffers on schedule the entire time, reported the same frame count every single reporting interval, and raised zero errors. From inside the recorder, nothing was wrong. The only thing that changed was the content of the buffers, and content is the one thing a health check based on stream state never looks at.
How do you tell a dead capture from a quiet stretch of the meeting?
By looking for exact digital silence rather than for quiet. A live capture carries a continuous low level noise floor even when nobody is speaking, so its measured level is low but never exactly zero. A capture that has been silently disconnected produces literal zeros. In the recordings we measured, the longest run of digital silence on a healthy live capture was about two seconds, so a threshold set tens of times higher than that can raise an alarm on a dead capture without ever raising one on a pause in a real conversation.
Can the second half of the meeting be recovered afterwards?
No. If the samples were never captured, there is nothing in the file to recover. This is the entire reason detection has to happen during the meeting rather than after it. What can be recovered is the part that was captured before the failure, and what can be prevented is the recording quietly attributing the missing half to the wrong person.
What should a notetaker do when it detects this mid-meeting?
Three things, in order. Try to rebuild the capture, because a stale snapshot is repairable and a rebuilt capture starts working again immediately. Tell you on screen, without a dismissible toast that can be missed, because you are the only one who can decide whether to keep going. And stop attributing the missing audio to anyone: a span with no far end captured should be marked as unverified in the transcript rather than credited to the person whose microphone was still working.
Does Stillnote upload my meeting to detect any of this?
No. Stillnote records, transcribes, and summarizes on your Mac. The capture health monitoring, the transcription, the speaker separation, and the summary all run locally. Nothing about a failed recording, or a successful one, is uploaded to a Stillnote server, and none of it is used to train a model.
How much does Stillnote cost?
Stillnote is free for 5 enhanced notes a month with no credit card required. Plus is $8 a month for 30 notes, up to 3 connected calendars, and 90-day AI search. Pro is $13 a month for unlimited notes, unlimited calendars, and AI search across all your history. Billing happens in-app.