Raw Audio Sounds Wrong? How to Diagnose Speed, Static and Distortion

Step 0: Make Sure the File Really Is Raw PCM

Before changing any settings, check that the file actually contains raw samples. Files are often named .pcm or .raw when they really hold compressed audio or have a header at the start. If no combination of settings produces anything other than noise, this is usually the reason.

The first few bytes of the file tell you. On macOS or Linux, run xxd yourfile.pcm | head -2. On Windows, open the file in any hex editor. Look for these signatures:

If you see small values changing smoothly, such as 00 00 01 00 FF FF 02 00, you are probably looking at 16-bit PCM near silence. That is the kind of file this guide is about.

Step 1: Use the File Size to Narrow Down the Format

The size of a raw PCM file is exactly:

bytes = sample rate × bytes per sample × channels × seconds

This gives you a quick sanity check when you know roughly how long the recording should be. Suppose a device recorded for 10 seconds and produced a 320,000-byte file. That is 32,000 bytes per second, which fits 16,000 Hz × 2 bytes × 1 channel (16 kHz, 16-bit, mono). It also fits 8,000 Hz × 2 bytes × 2 channels, or 8,000 Hz × 4 bytes × 1 channel (32-bit float). The duration alone does not tell you which is right, but it cuts dozens of combinations down to two or three.

The byte count is also a useful check. A 16-bit stereo file always has a size divisible by 4. A 16-bit mono file always has an even size. If a "16-bit" file has an odd number of bytes, it is either truncated or has an extra byte at the start (see Step 5).

Step 2: Fix the Speed and Pitch (Sample Rate)

If the audio sounds like the right thing played at the wrong speed, the sample rate is wrong. It may be a recognisable voice that is too fast and too high, or too slow and too low. Speed and pitch always change together in raw PCM, because the player is simply consuming samples faster or slower than they were recorded.

• Too fast and high-pitched: the playback rate is higher than the recording rate. Choose a lower sample rate.
• Too slow and deep: the playback rate is lower than the recording rate. Choose a higher sample rate.

The size of the error tells you how far off you are:

The last two rows are the tricky ones. A 44,100 vs 48,000 mix-up changes the speed by under 9%, which sounds "slightly off" rather than obviously wrong. If a voice sounds a little too sluggish or a little too bright, try the other one of these two rates before anything else. An octave error (2× or 0.5×) usually means one of three things: an 8k/16k mix-up, a 22.05k/44.1k mix-up, or the channel count problem described next.

Step 3: Rule Out a Mono/Stereo Mix-Up

A wrong channel count also looks like a speed problem, which is why it catches people out. In a stereo file the samples are interleaved: left, right, left, right. If you decode a mono file as stereo, the player sends every other sample to each ear. Each channel then gets half the samples, so the audio plays at double speed and lasts half as long. If you decode a stereo file as mono, the left and right samples play one after another. The audio runs at half speed and lasts twice as long, often with a slightly gritty texture because neighbouring samples come from different microphones.

To tell this apart from a sample-rate error, look at the reported duration. If you know the recording was 30 seconds and the player shows 15 or 60, change the channel count first. If the duration is correct but the pitch is wrong, the sample rate is the problem. With headphones there is a second clue: a mono file decoded as stereo sounds nearly identical in both ears, but with an odd, slightly hollow quality.

Step 4: Fix Static and Harsh Distortion (Bit Depth, Sign and Byte Order)

If the speed is plausible but the sound is buried in noise, the problem is how each sample is being read. The common cases sound noticeably different:

• Loud, constant white noise with the real audio faintly audible underneath: usually byte order. The file is big-endian but is being read as little-endian, or the other way round. Each sample has its high and low bytes swapped, so tiny changes in the signal become huge jumps. Big-endian audio is rare today, but it still comes from some network streams, older Mac and Sun formats, and certain DSP chips.
• Pure full-scale static with nothing recognisable: 32-bit float data read as 16-bit integers, or a misaligned file (Step 5). Try 32-bit float.
• Near-silence with occasional loud pops: the opposite case, 16-bit integer data read as 32-bit float. Most integer patterns become tiny float values, and a few become huge or invalid ones.
• Harsh, buzzing distortion that is worst in the quiet parts: 8-bit data with the wrong sign. Unsigned 8-bit audio stores silence as 128, while signed 8-bit stores it as 0. If you read one as the other, near-silent passages swing between the extremes. That is why the quiet parts sound worst instead of the loud ones.
• Half speed buried in hiss: 16-bit audio decoded as 8-bit. Every sample is read as two, so the duration doubles, and the low byte of each sample turns into noise. This is easy to confuse with Step 3, but the hiss gives it away. The opposite mistake, 8-bit audio read as 16-bit, plays at double speed as static.

The PCM Drop player covers the three most common sample formats: 8-bit unsigned, 16-bit signed little-endian and 32-bit float. For big-endian or 24-bit data, Audacity's File → Import → Raw Data dialog lets you set the encoding and byte order explicitly. With FFmpeg, choose the input format, for example -f s16be for 16-bit big-endian or -f s24le for 24-bit little-endian.

Step 5: Check for a Header or an Offset

Sometimes everything is set correctly and the audio is still pure noise. Or it plays correctly but starts with a short click. Both point to extra bytes at the start of the file.

A click or blip in the first few milliseconds usually means a header is being played as audio. The standard 44-byte WAV header becomes 22 samples of 16-bit "audio", short enough to sound like a tick. It does no harm, but it tells you the file is really a WAV.

Pure noise with 16-bit settings that ought to be right often means the data is shifted by an odd number of bytes. Each sample is then built from the second half of one value and the first half of the next. Skipping a single byte fixes it. On macOS or Linux, tail -c +2 input.pcm > fixed.pcm copies everything except the first byte. In Audacity's raw import dialog, set "Start offset" to 1. Some capture tools also write their own small header, often 16, 32 or 64 bytes. If you know the header size, skip exactly that many bytes.

Problems That Are Not Settings Problems

A few symptoms survive every combination of settings because the problem is in the recording itself:

• Total silence at every setting: open the file in a hex editor. If it is all 00 bytes, the device recorded nothing. This is often a microphone that was never enabled, a muted input or a missing permission.
• Flat-topped, crunchy peaks on loud passages: clipping. The input gain was too high when the audio was recorded, and the lost information cannot be recovered afterwards.
• Regular tiny gaps or clicks every fraction of a second: buffer underruns in the recording code. The device dropped samples when it could not write them fast enough.
• A steady low hum at 50 or 60 Hz: mains interference picked up by the hardware. You can confirm the frequency by comparing it with a 50 Hz or 60 Hz tone from the tone generator.

Summary

Work through the problems in order: confirm the file is raw, use the file size to narrow the options, fix the speed, rule out a channel mix-up, and then fix the sample format. That covers almost every broken raw audio file. Once it sounds right, write the settings down. Raw PCM keeps no record of its own format, so this note is the only metadata the file will ever have. Then export a WAV or MP3 copy that any player can open.