Meeting / Notes audio capture broken in 1.1.4 (78): chipmunk-fast system audio + dropped frames make Zoom recordings unintelligible

Affected version: 1.1.4 (build 78), auto-updated 2026-04-30 via Sparkle. macOS: 26.4.1 (build 25E253), Apple Silicon. Mic: Focusrite Scarlett 4i4 4th Gen (USB), input 1, hardwired XLR, 48 kHz native. App settings: isSystemAudioEnabled: true, meetingAutoDetectEnabled: true, selectedMicrophoneID: AppleUSBAudioEngine:Focusrite:Scarlett 4i4 4th Gen:S4Q7DA65B8A096:1,2.

Zoom meetings recorded as Notes are unintelligible on playback — described as "extremely slow and garbled / muffled." The auto-generated summary on affected notes reads things like "The audio quality is too poor to extract any meaningful information. The transcript contains only distorted, muffled audio and a phone ringing sound." Transcripts contain only [distorted audio] / [phone ringing] / [muffled audio] markers.

Reproduction (suspected)

Any Zoom meeting recorded as a Note on Monologue ≥1.1.4 (78). Confirmed broken on:

• 2026-05-04 21:07 (note 22cace72-4e05-4074-80d9-8e86dc8384ef, share 1a44a66a-5124-4290-b016-c0a2aaa8e13e): "Unclear Audio: Phone Ringing & Muffled Sounds"

• 2026-05-05 13:58 (note a7adcc3f-15a4-45e1-b3ec-e5486ac4de5c): "Outro Jingle"

• 2026-05-01 (note 454e8e3c-9a1f-4eb6-9b16-d7a2d49978c5): "Muffled Phone Call Attempt"

What ffprobe / ffmpeg show

The uploaded m4a (16 kHz stereo AAC LC) is internally consistent in format but the channel content is wrong:

Recovery test, applied to the R channel of the Apr 26 file:

ffmpeg -i note.m4a -filter_complex
"[0:a]channelsplit=channel_layout=stereo[L][R];
 [R]asetrate=8000,aresample=16000[Rs];
 [L][Rs]amerge=inputs=2[mix]"
-map "[mix]" -ac 2 -c:a aac -b:a 96k recovered.m4a

This makes the Apr 26 recording fully listenable, confirming that the system-audio frames were captured but the rate written into the file is 2× too high relative to the actual sample-stream contents — i.e. the SCK output was effectively 8 kHz but the file claims 16 kHz. The May 4 file needs a 3× factor (asetrate=5333) to recover cadence, and even at the right rate, ~94% of frames are silent — the system-audio capture is starving in the new build.

Likely cause

The system-audio capture path (presumably ScreenCaptureKit) is misconfigured. Either:

1. The CMSampleBuffer sample_rate returned by SCK isn't being read; the buffers are being concatenated under the assumption they're 16 kHz, when SCK is delivering them at a lower rate.

2. There's no proper sample-rate converter between the SCK audio sink and the file writer.

Whatever changed between 1.1.3 (77) and 1.1.4 (78) also broke:

• The mic-side L channel (now silent) — possibly the same buffer-pump being starved by the system-audio side.

• System-audio frame delivery cadence — went from "occasional drops" to "~6% of frames written, 94% silence."

Impact

For Zoom users on 1.1.4 (78), every meeting Note silently records garbage. The summary/transcript pipeline correctly identifies the audio as unusable but the user sees a plausible-looking note title (e.g. "Unclear Audio: Phone Ringing & Muffled Sounds") and only realizes on playback that the recording is gone. There's no warning during capture.

Asks

1. Stop the regression — root-cause whatever in 1.1.4 (78) broke system-audio capture vs 1.1.3 (77). Most likely a sample-rate conversion / channel-format change in the Notes recording pipeline.

2. Detect bad captures and warn the user — if the file ends up with a near-silent channel or the captured-vs-claimed sample-rate ratio is anything other than 1, surface it in the Note instead of letting the user discover via playback hours later.

3. Offer a downgrade path — Sparkle keeps prior DMGs (https://updates.jottle.ai/Monologue-1.1.3-77.dmg); a "roll back" link in Help & Support would let affected users keep working.

Happy to share the recovered Apr 26 mp4 and the broken May 4 mp4 directly if useful — both are in ~/Downloads/monologue-recovery/ on my machine.