Chipmunk or Slow-Motion Voice? Fixing Audio at the Wrong Speed

Three symptoms, three families of cause

Listen to a voice you know and compare the converted file with the original, or with how the speaker really sounds.

• Faster and higher, or slower and lower, together. Like a tape played at the wrong speed. The samples are being played at a different rate from the one they were recorded at.
• Faster or slower, but the pitch sounds right. Something time-stretched the audio, keeping pitch while changing tempo. Often a speed setting in an editor or player.
• Higher or lower, but the duration is unchanged. A pitch-shift effect or voice processing was applied, deliberately or by accident.

The first family is by far the most common after conversion, and it is also the easiest to undo exactly.

Measure the ratio

Compare the duration of the wrong file with the original, or with a known real-world length such as a 30-minute meeting. Divide one by the other and look the result up:

About 1.088

Audio recorded at 48 kHz played as 44.1 kHz: slower and roughly 1.5 semitones lower

About 0.919

Audio recorded at 44.1 kHz played as 48 kHz: faster and roughly 1.5 semitones higher

Exactly 2 or 0.5

A rate mislabelled by a factor of two, such as 16 kHz treated as 32 kHz or 8 kHz: an octave shift

About 0.96

24 frames per second material played at 25, as in many older PAL broadcasts and discs: about 4 percent faster and slightly higher

About 1.001

29.97 and 30, or 23.976 and 24, confused: no audible pitch change but slow drift against the picture

A round figure such as 0.8 or 1.25

A playback or editing speed setting, often with pitch preserved

Here the ratio is the new duration divided by the original. As a concrete check, a 30-minute recording made at 48 kHz but played as 44.1 kHz lasts about 32 minutes 39 seconds. Why these sample rates exist, and why recognition uses 16 kHz, is explained in audio sample rates.

Where each cause comes from

Sample-rate mismatches happen when a device, driver or app assumes a different rate from the one the audio was recorded at, and plays or writes the samples without converting them. Older audio drivers, some USB devices, and recording software set to one rate while the interface runs at another are typical sources. A proper conversion resamples the audio, recalculating samples so that speed and pitch stay the same; a mismatch skips that step.

Wrong header values happen when a file says one rate but contains another. This turns up with some recorders and converters, and with raw audio imported without its settings, where the importer has to be told the rate and is given the wrong one.

Frame-rate conversions change speed deliberately. Broadcasters in 25 frames per second regions long played 24 frames per second film slightly fast, and the audio sped up with it unless pitch correction was applied. A conversion between NTSC-style rates, such as 23.976 and 24, changes speed by about one part in a thousand, which is inaudible as pitch but enough to drift a few seconds over an hour.

Accidental time-stretching happens in editors when a clip's speed or duration is changed and the audio follows, in screen recordings made while a player ran at 1.25 or 1.5 times speed, and in apps that export at the playback speed you were listening at.

Diagnose step by step

1. Find a reference: the original file, the camera's own playback, or the known duration of the event.
2. Measure both durations precisely and calculate the ratio.
3. Listen for pitch. Did it change along with speed, or not?
4. Check the file in a media inspector such as MediaInfo and note the sample rate it claims.
5. Retrace the chain: which app recorded, converted, imported and exported the file, and what rate each one was set to.
6. Match the ratio to the table above and test the reverse correction on a copy.

Fixes that restore the original exactly

Reinterpreting the rate is the cleanest fix when the samples themselves are intact and only labelled or played wrongly. You tell the software what rate the samples really are, without resampling, and speed and pitch return to normal together. In Audacity, the track menu's Rate setting changes how the samples are interpreted. With ffmpeg, the asetrate filter does the same. For a file labelled 44.1 kHz that was really recorded at 48 kHz:

ffmpeg -i slow.wav -af asetrate=48000 fixed.wav

Swap the number for the true rate in other cases. For the 25-for-24 speed-up, slow everything back by 24/25. At 48 kHz that means reinterpreting at 46,080 Hz and then resampling properly to 48 kHz:

ffmpeg -i fast.wav -af "asetrate=46080,aresample=48000" restored.wav

For accidental time-stretching, the best fix is to undo the speed change in the original project and export again. If only the stretched file exists, apply the inverse tempo, for example ffmpeg's atempo filter at 0.8 for audio that was sped to 1.25 times. Each stretch adds slight artefacts, so this recovers usable audio rather than a perfect original.

For video files, fix the audio and copy the picture back in without re-encoding it. If the picture's timing was correct and only the audio was wrong, the fix also restores sync; general sync repairs are covered in audio and video out of sync.

A worked example: an interview that came back too deep

What a speed error does to transcripts and subtitles

Speech recognition copes with small pitch differences, but voices that are noticeably too fast, too slow or shifted by a large interval are harder to recognise, so fix the speed before transcribing. The more practical problem is timing: timestamps describe the file you transcribed. If you transcribe a sped-up or slowed-down audio file and then use the subtitles on the original video, every cue will drift progressively further out of place. Fast speech that is genuinely fast, rather than sped up by a conversion, is a separate challenge covered in transcribing fast speech.

Mistakes and limits of speed repairs

• Resampling instead of reinterpreting. Converting a mislabelled file to the "right" rate preserves the wrong speed; you have to reinterpret first.
• Approximate corrections. A tempo change of 1.09 instead of the exact ratio leaves a residual drift over long recordings.
• Repeated processing. Each time-stretch or pitch shift adds artefacts, so always correct from the earliest copy available.
• Fixing audio but not the subtitles or edit that were built on the wrong version; anything derived from the wrong-speed file needs redoing.
• Treating tiny frame-rate differences as pitch problems. A one-in-a-thousand speed difference matters for sync, not for how a voice sounds.

How mydubly treats speed and pitch

mydubly accepts MP3, WAV, M4A, AAC, OGG and FLAC audio and MP4, MOV, WebM, MKV and M4V video. In the browser it decodes the audio and converts it to mono at 16 kHz for recognition; that conversion is part of decoding, not a reinterpretation, so it does not change speed or pitch. It also cannot correct a file that already plays at the wrong speed, and the timestamps in the transcript, SRT and VTT files follow the file you upload.

In a dub, individual translated lines may be sped up gently, by default up to about 1.15 times, or slowed to 0.9 times, so they fit the timing of the original speech. That is deliberate timing fit, described in syncing translated audio with video, not a conversion error. If the whole source audio runs at the wrong speed against the picture, fix it before translating, because the dubbed lines are timed to the audio as uploaded.

Next step: fix from the original, then transcribe

Correct the rate or tempo on a copy, confirm the duration matches the original, and then run the file through audio to text. If you are working with WAV files from a recorder, WAV to text explains what happens to them during transcription.