PCM Drop logoPCM Drop
All articles

µ-law and A-law Explained: The Telephone Audio Formats That Fool PCM Players

·7 min read

Sometimes a call recording, VoIP capture or telephony webhook gives you an "8 kHz, 8-bit" file that sounds terrible in every PCM player. The speech is there, but it is buried in a harsh, gritty roar, and changing between signed and unsigned 8-bit does not help. You are probably not looking at linear PCM at all. You are looking at G.711 µ-law or A-law, the encodings that have carried telephone calls since the 1970s.

They are easy to mistake for raw PCM because they also have no header, one byte per sample and a fixed 8,000 Hz rate. The difference is how each byte maps to a sound level.

Why Telephone Audio Is Not Linear

Plain 8-bit linear PCM has 256 evenly spaced levels. That sounds poor, with roughly 48 dB of dynamic range and audible hiss on quiet speech, because most of those levels sit in the loud range that speech rarely uses. Human hearing is closer to logarithmic: we notice small changes in quiet sounds much more than the same change in loud ones.

G.711 uses this. It is standardised by the ITU and used in essentially every phone network. Each sample still takes 8 bits, but the levels are spaced logarithmically. They are packed tightly near silence and spread out at high volume. This technique is called companding (compressing plus expanding). The result is quality similar to about 13–14-bit linear audio, at the same 64 kbit/s as 8-bit audio (8,000 samples per second × 8 bits).

There are two versions of the curve:

  • µ-law (also written u-law or mu-law): used in North America and Japan.
  • A-law: used in Europe and most of the rest of the world, and on international links.

They are similar in spirit but not interchangeable. Decoding A-law as µ-law, or the reverse, gives intelligible but distorted, rasping audio.

Where You Will Meet G.711 Files

  • VoIP and SIP systems. G.711 is the baseline codec for RTP voice. Packet captures of calls usually carry it as payload type 0 (PCMU, µ-law) or 8 (PCMA, A-law).
  • Telephony platforms and voice APIs. Several cloud telephony services stream call audio to your server as base64-encoded 8 kHz µ-law, and expect µ-law in return.
  • Asterisk and FreeSWITCH. Sound prompts and recordings are often stored as .ulaw or .alaw files. These are headerless G.711, unlike Asterisk's .sln files, which are true 16-bit linear PCM.
  • Legacy formats. Sun/NeXT .au files default to µ-law. WAV files can also hold G.711, marked with format code 7 for µ-law or 6 for A-law instead of 1 for PCM.

How to Recognise a µ-law or A-law File

A few clues point to G.711 rather than 8-bit PCM:

  • The source is telephony, VoIP or a voice API, and the data rate is 8,000 bytes per second.
  • Played as 8-bit PCM at 8,000 Hz, the timing and rhythm of speech are clearly correct, but the sound is a loud, distorted roar. Swapping signed and unsigned changes the character of the noise without fixing it.
  • In a hex editor, near-silent passages are full of FF and 7F bytes (µ-law silence) or D5 and 55 bytes (A-law silence). Silence in 8-bit unsigned PCM sits around 80 instead.

Because silence in µ-law is stored near the top of the byte range, a linear decoder reads a quiet room as nearly full-scale signal. That is why these files sound so loud and harsh when misread.

Converting G.711 to Normal PCM or WAV

Decoding G.711 back to 16-bit linear PCM is lossless with respect to what was transmitted. You get back the exact values the encoder chose. FFmpeg has dedicated input formats for both:

ffmpeg -f mulaw -ar 8000 -ac 1 -i call.ulaw call.wav
ffmpeg -f alaw  -ar 8000 -ac 1 -i call.alaw call.wav

SoX works too:

sox -t raw -r 8000 -e u-law -c 1 call.ulaw call.wav

In Audacity, choose File → Import → Raw Data and set the encoding to "U-Law" or "A-Law", with 8,000 Hz and 1 channel.

If you would rather inspect the call in a raw PCM player, convert it to 16-bit linear PCM first with ffmpeg -f mulaw -ar 8000 -ac 1 -i call.ulaw -f s16le call.pcm. Then open call.pcm in the PCM Drop player with 8,000 Hz, 16-bit and mono. The player does not decode µ-law or A-law directly, so this conversion step is needed.

A note for Python users: the standard library's audioop module, with its convenient ulaw2lin and alaw2lin functions, was removed in Python 3.13. On current versions, use FFmpeg, or a third-party package or lookup table, instead.

Should You Convert Before Processing?

Almost always, yes. Speech recognition engines, audio editors and analysis code expect linear PCM. Running them on G.711 bytes without decoding gives meaningless results. Decode once at the edge of your system, work in 16-bit linear PCM internally, and re-encode to G.711 only if you are sending audio back into a phone network.

Keep in mind that the audio stays telephone quality after decoding. G.711 at 8 kHz carries nothing above about 4 kHz, so upsampling to 44.1 kHz will not bring back the missing high frequencies. For archiving, a 16-bit 8 kHz WAV preserves everything. If you need smaller files, an MP3 at 32–48 kbps mono sounds the same. See our PCM to MP3 guide for the commands.

Summary

µ-law and A-law look like 8-bit raw PCM on disk, but each byte is a logarithmically coded level rather than a linear one. That is why PCM players turn them into a roar. Look for an 8 kHz telephony source and lots of FF or D5 bytes in silent sections. Decode with FFmpeg's mulaw or alaw input format, and you get clean 16-bit audio that every tool understands.