stillnote
Back to Stillnote

Guide

Your Mac recorded the meeting and captured no audio

The recorder ran for the full hour. The timer counted up. The file is the size you would expect. And there is nothing in it, or nothing from the other people, or nothing from you. This is one of the most demoralizing failures in the whole category, because you only find out once the meeting is over and the thing you were recording no longer exists.

Published 2026-08-13

A meeting recording is two captures, not one

Almost every meeting recorder that runs on your own computer, rather than joining the call as a bot, is recording two separate things at once. One is your microphone. The other is the audio your computer is playing, which is how the other participants get into the recording at all. These are different subsystems, they use different permissions, and they fail independently.

That is why the symptom tells you where to look. It is worth being precise about which of the three you actually have, because the fixes do not overlap.

Why nothing warned you

The uncomfortable part is that the recorder usually had no idea either. When an audio capture on macOS is orphaned, it typically does not raise an error, does not stop, and does not report an end of stream. It keeps delivering buffers on the same schedule it always did. The buffers are simply empty.

So every signal a normal recorder watches stays green. The stream is open. Buffers are arriving. The frame count is climbing. The file is growing, because silence still takes up space on disk. A recorder that checks whether it is running will conclude, correctly and uselessly, that it is running.

Catching this requires measuring the content of the audio rather than the health of the stream, and it requires distinguishing a broken capture from a quiet room. Those are not the same thing and a naive silence detector conflates them. A live capture carries a continuous low level noise floor even when nobody is talking, so it is quiet but never exactly zero. A capture that has been disconnected produces literal digital silence, sample after sample. The gap between those two is enormous, which is what makes it safe to act on: you can raise an alarm on exact zeros without ever raising one on a long pause in a real conversation.

Both sides have to be watched, and watched separately

There is a subtle trap here that is worth naming, because it is easy to build and hard to notice. If you detect a dead system audio capture by requiring the microphone to confirm it, reasoning that somebody is clearly talking while the far end is empty, then your detector is only as alive as the microphone. Point that reasoning at a meeting where the microphone is also dead and it produces nothing at all. The one recording where both captures are failing becomes the one recording with no warning.

The fix is to treat the two tracks as independent witnesses. A microphone that is quiet is ambiguous, because people do pause. A microphone that is producing exact digital silence is not quiet, it is absent, and a detector should notice the difference and keep working without it. Whether a given tool does this is a fair question to ask of any recorder you rely on.

How to check a recording is real, in under a minute

The second harm: a transcript that blames the wrong person

A silent recording is an obvious loss. There is a less obvious one hiding behind it. If the system audio capture dies and the microphone keeps running, the microphone is often still picking up the room, which means other people's words continue to arrive on the track the tool treats as you. The recording is not empty. It is populated with other people's remarks, confidently attributed to you, in your own notes.

That failure deserves its own treatment, and we wrote it up separately in when a meeting transcript names the wrong speaker. The short version: a tool that cannot hear who is speaking should stop claiming to know, and should say so on screen while the meeting is still running.

What Stillnote does

Stillnote records, transcribes, and summarizes meetings entirely on your Mac. No bot joins the call, nothing is uploaded, and every check described here runs locally on your machine. It watches the system audio track for digital silence, tries to rebuild the capture in place without interrupting your recording, and shows a warning that cannot be dismissed if the far end is genuinely not being captured. For any stretch where capture was provably dead, it stops asserting that those lines are yours.

The independent microphone case described above is the most recent thing we changed, and it came from auditing our own detector rather than from a user report. It is built and tested, and it reaches you in the next release rather than in the build on the download page today. The changelog is where it will show up when it ships.

Stillnote is free for 5 enhanced notes a month with no credit card required. See the full pricing or read how the on-device design works.

Recordings with no audio: common questions

Why does my Mac meeting recording have no audio?

A meeting recording on a Mac is usually two separate captures: your microphone, and the audio your computer is playing from the call. They fail independently and for different reasons. A recording with no sound at all usually means the microphone capture never started or was pointed at a device that produced nothing. A recording where you can hear yourself but nobody else usually means the system audio capture failed. A recording where you can hear everyone but yourself usually means the microphone was muted at the hardware level or another app had taken exclusive control of it.

Why can I hear the other participants but not myself?

Your microphone was delivering silence. The three common causes are a hardware mute switch on a headset or a physical mute button on a conference speaker, a Bluetooth headset that switched profile mid-call and stopped presenting its microphone, and another application holding exclusive access to the input device. All three look identical to software: the capture keeps running and keeps producing samples on schedule, and every sample is zero.

Why can I hear myself but not the other participants?

The system audio capture failed. On a Mac this most often happens when the default output device changes while a recording is running, which can orphan an existing audio tap. Connecting or disconnecting headphones, switching to a Bluetooth speaker, or an app taking control of the output can all do it. The capture usually keeps running and keeps delivering buffers on schedule, but the buffers no longer contain anything.

How can I check that a recording is actually capturing audio, before the meeting ends?

Watch a live input level, not a running timer. A timer only proves the recorder is running, which it will keep doing perfectly while capturing nothing. A level meter proves samples are arriving with content in them. If your tool shows a level, speak and confirm it moves, and confirm it also moves when someone else talks. If it shows only a timer, record a ten second test, stop, and play it back before the meeting that matters.

Is a silent recording recoverable afterwards?

No. If the samples were never captured, there is nothing in the file to recover, and no amount of processing will produce audio that was never written. This is why detecting the failure during the meeting matters more than any repair step afterwards. The only thing that can be recovered is the part that was captured before the failure.

Why does a recorder not notice that it is recording silence?

Most recorders check whether they are running, not whether what they are receiving contains anything. A failed capture on macOS typically does not raise an error, does not stop, and does not report an end of stream. It delivers buffers of zeros on schedule until you stop it. Unless something is measuring the content of those buffers, everything the recorder can see looks healthy.

How do you tell a broken capture apart from a quiet 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, sample after sample, which is a signature no real room and no real call produces. A pause is quiet. A dead capture is empty, and the difference is large enough to act on.

Does Stillnote upload my meeting to check any of this?

No. Stillnote records, transcribes, and summarizes on your Mac. The audio health checks, 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.

Keep reading

When a transcript names the wrong speakerHow on-device processing worksMeeting notes without a botPrivate meeting notes on MacWhat changed recentlyAll guides

Descriptions of how audio capture fails are given at a category level, drawn from macOS behaviour and from failures observed in Stillnote itself. They do not assert specifics about any other tool. Device level causes vary by hardware and by macOS version, and the checklist above is general guidance rather than a guarantee that a given recording will be recoverable or that a given cause applies to your machine. Nothing here is legal advice, and Stillnote does not determine whether recording a given conversation is permitted where you are. Stillnote is a native macOS app on Apple Silicon, made by LeapVision Technologies Inc.