Why your Mac recording plays too fast, too slow, or like a chipmunk

Your recording is fine. The number describing it is wrong.

An audio file is two things: a pile of samples, and a declaration of how many of them make up one second. If those disagree, the player obeys the declaration. 16,000 samples arrived per second, the header says 48,000 per second, so the player burns through them three times too quickly — and pitch rides along with speed, which is why it comes out as chipmunks rather than just as a fast recording.

The arithmetic is exact and there is no rounding in it:

playback speed = declared sample rate ÷ real sample rate

The bottom two rows are the ones people misdiagnose as “the file is a bit weird”. A 5-minute error over an hour is not weird; it is 44.1 against 48, and it is fixable in one command.

Work out the real rate from what you already have

You need two numbers, and you probably already know both.

macOS ships the tool for the first one. In Terminal:

afinfo recording.m4a

You get something like this — this is real output, from a file made for this article:

Data format:     1 ch,  48000 Hz, Int16
estimated duration: 3.333333 sec
audio bytes: 320000

That is the declared rate and the declared duration. The second number is how long the meeting actually was — from your calendar, from the other side’s recording, from memory.

Then:

real rate = declared rate × (declared duration ÷ true duration)

A file that says 48 kHz and 20 minutes, from a call that ran an hour: 48,000 × (20 ÷ 60) = 16,000. Your samples are 16 kHz. Round to the nearest ordinary rate — 8000, 16000, 22050, 24000, 32000, 44100, 48000 — because your calendar estimate is not precise and real hardware does not run at 15,987 Hz.

What actually causes it on a Mac

Four situations, in rough order of how often they bite.

A Bluetooth headset whose microphone got opened

This is the big one, and it is worth understanding because nothing in the interface warns you. A headset used for playback runs at one rate. The same headset used for a two-way call runs at a much lower one, and the switch happens the moment something opens its microphone — joining the call, in other words.

BlackHole’s tracker has this report from 2021: "I create a multi output include a bluetooth and BlackHole, voice can played well. But When I open a microphone using this bluetooth headset, voice file can not be played well. It is played slowly." Devin Roth, who wrote BlackHole, answered the same day: "In a nutshell it has to do with the sample rate of the mic." Another user, on AirPods Pro: "the sampling rate for MO device was only 16Hz and voice is garbled."

We hit the same thing from the other end, in our own recorder, and the log entry is specific about which number lied. AirPods active for both microphone and output: the microphone correctly read as 16 kHz in call mode, but kAudioHardwarePropertyDefaultSystemOutputDevice still reported 48 kHz, so the capture opened at 48 kHz while 16 kHz worth of samples arrived per second. File labelled 48 kHz, played 3× fast. That is written up in our issue tracker, dated 2026-04-26, and it is the reason this page exists.

A virtual audio device set by hand

BlackHole, Loopback and friends have a sample rate you choose in Audio MIDI Setup. Whether it follows the source depends on the app at the other end. Roth again, on whether BlackHole tracks the rate: "If you change the sample rate in a daw or other program (assuming they programmed it correctly) it will immediately be changed in AudioMidi setup… Now I tested with Audacity and it looks like it doesn't notify CoreAudio of any changes or respond to any changes in CoreAudio."

So the mechanism is a chain, and any link can be the wrong length: what the source plays at, what the virtual device is set to, and what the recorder writes into the header. Set all three the same before you record and this class of bug disappears.

An aggregate device with a bad clock

Apple’s own instructions for building one contain the step everybody skips: "To set the clock source for the Aggregate Device, choose the device from the Clock Source menu. Choose the device with the most reliable clock. For each device that is not the clock source, select Drift Correction."

Skip Drift Correction and you get a different symptom, which is worth separating out. A declared-rate mismatch is a constant ratio — wrong from the first second, wrong by the same amount at the end. An uncorrected clock is drift — fine at the start, progressively out of sync, typically heard as your voice and theirs sliding apart over a long recording. Different cause, different fix, and re-stamping the header will not touch it.

Roth’s own verdict on aggregates, in that same tracker: "Aggregates are full of bugs." And, later in the same thread: "I recommend not using Aggregates at all since they've only ever caused me problems." That is the author of the most-recommended virtual audio driver on macOS talking about the thing every tutorial tells you to build.

The device changed rate while you were recording

Pull one AirPod out. Plug in headphones. Join a second call. The route changes, the new device’s rate is not the old device’s rate, and a recorder that wrote its header at the start is now writing samples that no longer match it. Any recording that is correct for the first ten minutes and wrong after that is this.

Fix an existing recording without re-encoding it

The operation you want is re-declare the rate, not resample. Resampling changes the samples to fit the wrong number. Re-declaring changes the number to fit the samples, which is what you actually want, and for an uncompressed file it is lossless.

ffmpeg’s asetrate filter does exactly this. It is not built into macOS; brew install ffmpeg.

For a WAV, AIFF or CAF — samples come out bit-identical:

ffmpeg -i wrong.wav -af asetrate=16000 -c:a pcm_s16le right.wav

Verified on 4 August 2026: a 10-second 16 kHz tone was re-wrapped as 48 kHz (afinfo reported 3.333333 sec, 320000 audio bytes), then repaired with the command above. Result: 16000 Hz, 10.000000 sec, 320000 bytes, and the decoded PCM compared byte-for-byte identical to the original. Nothing was resampled.

For an .m4a or any AAC file, you have to accept one lossy generation:

ffmpeg -i wrong.m4a -af asetrate=16000 -c:a aac -b:a 128k right.m4a

-c:a copy will not work here and ffmpeg says why: "Filtering and streamcopy cannot be used together." An AAC bitstream carries its own rate index inside every frame, so there is nothing to re-stamp — it has to be decoded and re-encoded. One AAC generation on speech is not a disaster, but do it once, from the original.

The command that looks right and isn't:

ffmpeg -i wrong.wav -ar 16000 out.wav   # ← does not fix it

-ar is a resample instruction. It faithfully converts your already-wrong-speed audio to 16 kHz and hands you a file that is still 3× fast. Tested: duration stayed at 3.33 seconds.

When it isn’t the sample rate at all

One test separates two problems that look similar in a file browser and sound nothing alike.

Play it. Chipmunks or a drawl means speed, means rate, and the section above fixes it. Normal pitch, normal pace, but the file ends long before the meeting did means samples were dropped during capture — an overloaded audio subsystem skipping cycles, a device that stopped delivering, a microphone that quietly died forty minutes in. No header edit recovers those. They were never written.

That failure has its own page: when a Mac recording comes out silent or short.

What Narada does about this, and what it doesn’t

Narada records a meeting’s system audio and your microphone as two separate tracks without you installing a virtual driver or building anything in Audio MIDI Setup, so two of the four causes above are not available to you as mistakes. It reads the output device’s nominal sample rate (kAudioDevicePropertyNominalSampleRate) rather than the rate the audio tap advertises, which is what removed the common AirPods case. On the export side, the reader is pinned to 48 kHz so the encoder cannot mislabel source-rate samples as something else.

None of that is immunity, and our tracker says so. The AirPods fix is filed as partially resolved: it still misfires when the default-system-output property names the built-in speakers while you are actually listening through AirPods, or when AirPods report 48 kHz nominal while sitting in call mode. Narada builds a private aggregate device of its own for the system tap, and yanking a headset mid-recording can still make its rate drift — that is a separate open issue. The self-healing fix — measure the effective rate from frames divided by wall clock, and re-stamp the header when the two disagree by more than 5% — is on the list and has not shipped.

What has shipped is the narrower, honest thing: Narada checks each finished recording against itself, compares the frames it submitted with the frames actually in the file, and marks the recording Incomplete with a reason when audio went missing. It cannot get that audio back, and that check is about missing samples rather than a mislabelled rate. A recorder that tells you something is wrong is worth more than one that presents every file as fine.

Sources

• Apple Support, Create an Aggregate Device to combine multiple audio devices — “When you create an Aggregate Device, multiple devices appear as a single device in an app”; the Clock Source and Drift Correction instructions quoted above. https://support.apple.com/en-us/102171
• GitHub, ExistentialAudio/BlackHole issue #428, voice played slowly when mulit output is used incluing bluetooth headset and blackhole (25 June 2021) — the user report and Devin Roth’s reply, “In a nutshell it has to do with the sample rate of the mic.” https://github.com/ExistentialAudio/BlackHole/issues/428
• GitHub, ExistentialAudio/BlackHole issue #464, AirpodPro does not work properly (23 September 2021) — “the sampling rate for MO device was only 16Hz and voice is garbled”. https://github.com/ExistentialAudio/BlackHole/issues/464
• GitHub, ExistentialAudio/BlackHole issue #41, Sample rate not set by application? (6 January 2020) — Roth on when BlackHole follows an app’s rate, and on Audacity not notifying Core Audio. https://github.com/ExistentialAudio/BlackHole/issues/41
• GitHub, ExistentialAudio/BlackHole issue #524, Blackhole sample rate keeps changing — Roth on aggregate devices, in comments dated 13 October 2023: “Aggregates are full of bugs”, “I recommend not using Aggregates at all since they’ve only ever caused me problems.” https://github.com/ExistentialAudio/BlackHole/issues/524
• Narada’s own issue tracker, entries R1, R2 and active issue #4, dated 2026-04-26 — the AirPods 16 kHz / 48 kHz measurement and the state of the fix.
• The ffmpeg commands and the afinfo output in this article were run on macOS 26.5 with ffmpeg 8.0.1 on 4 August 2026.

All sources checked 4 August 2026.