An audio file that plays too fast or sounds high-pitched

A recording you know is twenty minutes long finishes in twelve, and every voice on it sounds like a cartoon. Nothing is wrong with your speakers and nothing is wrong with the recording itself. In nearly every case the audio data is intact and only one number in the file’s header is wrong: the sample rate.

If speed and pitch moved together, that is the tell. Audio that plays fast and low, or slow and normal in pitch, is a different and rarer problem.

Why a wrong sample rate does this

Digital audio is a list of measurements taken at a fixed pace. The header at the front of the file says how fast to replay them: 44,100 per second for CD-style audio, 48,000 for most video work, 16,000 or 8,000 for voice recordings from phones and radios.

The player does not inspect the audio to work out its natural speed. It reads the number in the header and trusts it. If a file recorded at 44,100 is labeled 48,000, the player runs through the measurements faster than they were taken, so the whole thing finishes early and every frequency shifts up. Label a 48,000 file as 44,100 and you get the opposite: slow and deep.

The ratio tells you which pair of numbers is involved. Audio that runs roughly ten percent fast is a 44,100 file labeled 48,000. Audio that runs at three times speed is often a 16,000 file labeled 48,000, which is why voice memos and radio recordings show up in this category so often.

Read the sample rate before you change anything

macOS has a command that tells you what the file claims. Open Terminal and run it against your file:

afinfo ~/Desktop/recording.m4a

You will get the format, the sample rate, the channel count and the duration. Two lines matter.

Compare the reported duration against how long you know the recording to be. If afinfo says twelve minutes and you recorded twenty, the header is lying and the sample rate is the reason. If afinfo says twenty minutes but playback finishes in twelve, the file is fine and the player is at fault.

Then look at the sample rate itself. Anything other than 8,000, 16,000, 22,050, 32,000, 44,100, 48,000 or 96,000 is suspicious on its face, and a rate that looks plausible can still be wrong for this particular file.

Rule out the player first

Before treating the file, check that the file is actually the problem. It takes a minute and saves you from re-encoding something that was never broken.

1. Play the file in QuickTime Player and in the Music app. If one plays it correctly and the other does not, the file is fine.
2. Open Audio MIDI Setup (in Applications, Utilities) and look at your output device’s format. A device stuck at an unusual rate can affect everything you play, not just this file.
3. Try the file on another Mac or another device if you have one to hand.

If every player agrees the file is fast, the header is wrong and it is time to rewrite it.

When the header is genuinely damaged

There is a version of this that is not a labeling mistake but real damage. A recording interrupted mid-write, or a file that arrived from a transfer that stopped partway, can end up with a header containing whatever bytes happened to land there. The symptoms are recognizable: a nonsense sample rate, a duration of zero or something wildly wrong, and playback that is fast, stuttering, or refuses to start.

That is a repair job rather than a conversion job, because there is nothing coherent for a converter to read. A repair pass scans the file for the actual audio frames and writes a new header describing what it finds.

Manatee does this on the Mac in Repair mode: drop the file on the menu bar icon and it works from a duplicate, never modifying your original, then reports the outcome as Fixed, Partial or Not fixable. Partial is the honest answer when a recording was cut off in progress, and it means what it says: the audio that reached the disk comes back and the rest does not exist to recover. Corrupted MP3 or M4A won’t play on Mac walks through the neighboring symptoms.

Rewriting the file to a clean, explicit format

For a file that is merely mislabeled rather than damaged, the goal is a new file whose header is written fresh and correctly.

Converting to WAV is the most predictable route, because WAV stores uncompressed audio with a plain header and nothing is guessed. Converting to MP3 or M4A works too and produces a far smaller file, at the cost of a re-encode; lossless vs lossy covers what that costs in practice.

Manatee’s Convert mode takes the file and writes the new one alongside, all on your Mac with no upload. It accepts the formats these problems tend to arrive in, including the voice-recorder formats that so often carry a low sample rate: AMR, CAF, WMA, OPUS and the rest.

One honest limit. If a file’s header says 48,000 and the audio was really 44,100, any tool that trusts the header will faithfully reproduce the fast version at the new format. A conversion fixes a damaged or missing header. It does not second-guess a header that is internally consistent but factually wrong. For that case, the reliable fix is to go back to whatever produced the file and export again, choosing the rate deliberately.

Avoiding it next time

Most mislabeled audio comes from three places. Screen and call recordings made while an audio interface changed rate mid-session. Files extracted from video by a tool that assumed a rate rather than reading one. And raw or headerless audio dumps, where there is no rate to read at all and something has to guess.

When you export, set the sample rate explicitly rather than leaving it on automatic, and keep video work at 48,000 throughout. Mixing rates inside one project is also the usual root of audio out of sync after a conversion, which is the same underlying confusion showing up as drift instead of speed.

Questions

Can I fix the speed without re-encoding the audio? Sometimes. Rewriting only the header leaves the audio untouched, which is ideal. Whether that path is available depends on the format; compressed formats often have the rate baked into each frame as well.

Why does the file sound normal on my phone but fast on my Mac? Different players handle a contradictory header differently. Some trust the container, some trust the audio stream. A file that disagrees with itself will play differently everywhere.

Does this affect video files too? Yes, though it shows up as audio that drifts away from the picture rather than a chipmunk effect, because the video track keeps its own timing.

The pitch is wrong but the length is right. Same cause? No. That points at a channel or decoding problem rather than a rate mismatch, and it is worth checking whether the file plays correctly in a second application before doing anything to it.