Engineering notes

When a meeting transcript names the wrong speaker

Published August 6, 2026 by Stillnote

Most writing about AI meeting notes is about accuracy in the narrow sense: did the model hear the word correctly. That is the easy half. The harder half is attribution, the claim about who said it, and attribution fails differently. A misheard word looks wrong on the page. A misattributed line looks perfectly fine. It has your name on it, it is grammatical, it is plausible, and it will sit in your notes indefinitely without ever raising a flag.

What happened

During a real 69-minute meeting, the part of our app that captures the audio your Mac is playing, which is how it hears the other participants, stopped working 35 minutes in. It did not crash. It did not report an error. macOS kept handing it audio buffers on schedule, right to the end of the call, and the app logged a clean shutdown afterwards. Every check we had was green.

The buffers were empty. From minute 35 onward, every single sample in them was zero.

The microphone, meanwhile, was fine. It carried on doing exactly what a microphone in a room does: it picked up the people in the room, through the speakers and across the table. And because the app treated the microphone track as the owner's voice, which is normally a completely safe assumption, roughly 950 of about 1,300 transcript lines came out labelled as the person running the recording. They were not his. Some of them were remarks he would never have made, now sitting in his own notes with his name in front of them.

That is the failure worth writing about. The lost audio was the smaller problem. The misattribution was the real one, and nothing in the app said a word about either.

Why the obvious safeguard would not have caught it

The intuitive fix is a silence detector: if the other participants go quiet for a long time, raise a flag. We already had one, and it did not fire, for a good reason. Meetings are full of silence. People pause, think, mute themselves, take a phone call. A watchdog tuned tight enough to catch a dead capture in a reasonable time would spend every meeting crying wolf, and a watchdog loose enough to stay quiet would take most of an hour to notice.

So we went and measured the actual signal instead of arguing about thresholds. Across the 35 minutes when the capture was working on that recording:

• There was not one single second of exact digital silence. A live conferencing app pushes a continuous low-level noise floor into the capture even when nobody is talking.
• The longest run below the level where samples are effectively all zero was 2 seconds.
• The longest genuine conversational pause, measured at the quiet threshold a silence watchdog would use, was 41 seconds.
• From the moment the capture died, the track was exactly zero for 2,035 seconds without interruption.

Those numbers say something useful. "Quiet" and "dead" are not two points on the same scale, they are different signals. A quiet meeting still hums. A dead capture is arithmetic zero. Separating them on digital silence rather than on loudness gave us roughly sixty times the headroom that a quiet-based rule would have had, which is the difference between a check you can leave switched on and one you end up muting.

One more condition matters. Genuine digital silence forever is completely normal in some recordings: an in-person meeting has no call audio at all, and neither does a recording you started before joining. So the app only treats silence as a failure when the capture demonstrably worked earlier in this same recording and your microphone is actively picking up speech right now. Something is being said into this machine, and the channel that was carrying the room has gone to zero.

What we shipped

Detection alone is not a feature. What the app does about it is the feature, and it comes in three parts.

• Try to fix it. The app rebuilds the audio capture in place, up to three times, without touching your microphone, your recording file, or the meeting timeline. If it comes back, the recording continues as if nothing happened and the attempt budget resets, so cycling headphones through a long meeting keeps getting help.
• Say so, plainly. If reconnection fails, a warning appears during the meeting stating that the other participants are not being recorded, what probably caused it, and what usually fixes it. It has no dismiss button. The whole defect was silence, so an option to make it quiet again would reintroduce the bug.
• Stop guessing. For any stretch of the recording where the capture was provably dead, the app withdraws the claim about who was speaking. Those lines are marked Unverified speaker rather than attributed to you. The words are never deleted and never edited. Only the name is withdrawn, because the name was the part that was wrong.

That last point is the one we would argue for hardest in any transcription tool. The honest output of a system that has lost its ability to tell speakers apart is not a best guess. It is an explicit "someone spoke here and I do not know who." A reader can work with that. A reader cannot work with a confident wrong answer, because there is nothing on the page to tell them to check.

We extended the same rule to the summary. The local model that writes your notes is instructed to use the content of unverified lines where it is useful, and never to build an owner, a decision, or an attendance claim on top of one. An action item with the wrong name on it is how a transcription bug turns into a real-world misunderstanding.

The part we got wrong the first time

Worth admitting, because it is the more common shape of this class of bug. The first version of the fix corrected attribution when the meeting ended and the final transcript was assembled. The live view during the meeting still said "You."

So for the length of the outage, the app displayed a warning promising that room audio would be marked unverified rather than attributed to you, directly above a transcript that was, at that exact moment, attributing it to you. Both halves shipped, both halves worked, and together they made the app contradict itself on screen. The live view now applies the same withdrawal in real time, back-dated to the start of the outage so the lines already on screen are corrected too, and it carries through to crash recovery so a session restored after a crash cannot quietly re-assert the claim.

What to check in any meeting notes tool

None of this is specific to us. If you rely on a notetaker for anything that matters, these are worth knowing about whatever you use.

• Does it tell you during the meeting when capture fails, or only afterwards, or not at all? Find out before you need to know.
• Does it distinguish a quiet meeting from a broken capture? A tool that only watches for silence will miss the failure that matters.
• What does it do with speaker names when it is unsure? A tool that always produces a confident name is not more accurate, it is less honest.
• Can you get back to the audio and check a line yourself? If a commitment or a decision turns on who said something, the transcript should not be the only record.
• If you change audio devices mid-call, does anything notice? Connecting or disconnecting headphones is the single most common trigger for this whole failure mode.

Honest limits

• This detects one specific failure, a system audio capture that has gone to digital silence after previously working. It is not a general guarantee that every recording is complete or correct.
• Speaker names remain suggestions, always. Speaker separation is probabilistic, it degrades with crosstalk and poor microphones, and it can be wrong on a perfectly healthy recording.
• Recovery is best effort. Rebuilding the capture works in many cases and not all of them, which is exactly why the app tells you instead of assuming it succeeded.
• Audio recorded while the capture was dead is gone. Nothing recovers it. The app protects the attribution, not the missing sound.
• This behaviour has been verified with tests reproducing the failure, and continues to be checked against real meetings. Anything you plan to rely on deserves a look at the audio.

Stillnote records, transcribes, and summarizes meetings entirely on your Mac. Nothing is uploaded, no bot joins your calls, and everything described above, including the health check, runs locally. It 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.

Wrong speaker in a transcript: common questions

Keep reading

This post describes a failure found in Stillnote and the changes made in response to it. The measurements quoted come from a single real recording and are reported as measured, not as a guarantee of behaviour on every machine or every meeting. Descriptions of how audio capture can fail are given at a category level and do not assert specifics about any other tool. 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.