PCM, WAV, AIFF, FLAC, ALAC: lossless formats explained

Why this matters

If you run a video product — a streaming service, an OTT platform, a music-and-video app, a media archive — someone will eventually ask what format your master files should be in, and the wrong answer is expensive. Store everything as uncompressed WAV and your archive doubles in size; pick a codec your players cannot open and your delivery breaks. This article gives you the vocabulary to tell the difference between the audio itself and the box it ships in, a clear rule for when lossless compression pays for itself, and the standards to cite when a vendor's claims do not add up.

Lossy versus lossless: the one distinction that matters

Start with the word that does all the work. Lossless means no information is lost: when you decode the file, you get back exactly the numbers that went in, every sample identical. Lossy means some information was deliberately discarded to make the file smaller, and you can never get it back.

A helpful analogy is the difference between a ZIP archive and a JPEG photo. A ZIP file is lossless — unzip it and the original document returns byte for byte. A JPEG is lossy — it deletes detail the eye is unlikely to miss, and saving it again never recovers that detail. MP3 and AAC are the JPEGs of audio: they delete sound the ear is unlikely to notice. FLAC and ALAC are the ZIPs of audio: smaller files that decode back to the exact original.

This matters because the two jobs are different. A delivery codec like AAC optimizes for the smallest file a listener will accept. A lossless format optimizes for keeping the master perfect — for archiving, for editing, for re-encoding later into whatever delivery format the future demands. You would not master a film in JPEG, and you should not master audio in MP3.

Figure 1. Lossy encoding throws data away for good; lossless compression is reversible — the decoded output equals the original sample for sample.

PCM: the audio itself, before any container

Before we talk about file formats, we need the thing the files hold. When a microphone signal is digitized, the system measures the sound wave's level many thousands of times a second and writes each measurement as a number. That stream of numbers is called pulse-code modulation, or PCM — the most common way to represent uncompressed digital audio. (For how those measurements are taken, see What is digital audio: from sound wave to bits.)

PCM is not a file format. It is raw data: a long list of integers, two per stereo frame, arriving at the chosen sample rate. To turn that raw data into a file someone else can open, you have to wrap it in a container that records the rules for reading it — how many channels, what sample rate, what bit depth, where the audio starts and stops. Without that header, a pile of PCM numbers is unreadable, because nothing says whether they are 16-bit or 24-bit, mono or stereo, 44,100 or 48,000 samples per second.

So the mental model is two layers. The bottom layer is the PCM audio — the actual sound, identical no matter how you store it. The top layer is the container or codec — the box that either stores those numbers as-is (WAV, AIFF, BWF) or packs them smaller and reversibly (FLAC, ALAC). Keep these layers separate and every format below makes sense.

Figure 2. One audio, many boxes: PCM is the sound; WAV, AIFF, and BWF store it raw, while FLAC and ALAC store the same PCM compressed but fully reversible.

The uncompressed containers: WAV, AIFF, BWF

Three formats store PCM without compressing it. They differ mostly in heritage, not in audio quality — the samples inside are the same.

WAV (Waveform Audio File Format) is the Windows-world standard, introduced by Microsoft and IBM in 1991. It is a specific use of the RIFF container — a generic "Resource Interchange File Format" built from labelled blocks called chunks. A WAV file has a fmt chunk describing the audio and a data chunk holding the PCM. WAV stores samples little-endian (least-significant byte first), matching the Intel processors it was born on. It is the most universally readable audio container on earth.

AIFF (Audio Interchange File Format) is the Apple equivalent, created in 1988 for the Macintosh. It follows the Electronic Arts EA IFF 85 chunk structure, with a top-level FORM chunk, a COMM (common) chunk describing the audio, and an SSND chunk holding the samples. The one technical twist: AIFF stores samples big-endian (most-significant byte first), because the Motorola 68000 chip in early Macs was big-endian. Quality is identical to WAV; the byte order is the only thing that differs at the sample level.

BWF (Broadcast Wave Format) is WAV with professional metadata bolted on. Standardized by the European Broadcasting Union as EBU Tech 3285, it adds a bext (broadcast extension) chunk carrying a timecode reference, originator, origination date, and — since Version 2 (2011) — EBU R128 loudness metadata. The audio payload is still ordinary PCM; BWF just records who made the file, when, and at what timecode, which is why it is the exchange format of professional film and broadcast post-production. A normal WAV player opens a BWF file and ignores the extra chunk.

A common mistake: the 4 GB WAV ceiling

Here is a trap that bites long-form and high-resolution projects. Classic WAV, AIFF, and BWF all record chunk sizes in a 32-bit field. The largest number 32 bits can hold is 4,294,967,295 — so a single file cannot exceed roughly 4 gigabytes. Do the arithmetic for a long multichannel session: 6 channels × 24-bit (3 bytes) × 48,000 samples per second = 864,000 bytes every second, or about 3.1 GB per hour. A two-hour 5.1 record blows past the ceiling and the file silently corrupts or won't finish. The fix is RF64, the EBU's extended WAV defined in EBU Tech 3306: it swaps the RIFF tag for RF64 and stores a 64-bit size in a new ds64 chunk, lifting the limit to roughly 16 exabytes. If your pipeline records long surround sessions, require RF64-capable tools.

The lossless codecs: FLAC and ALAC

FLAC and ALAC do something the uncompressed containers do not: they make the file smaller while still decoding back to the exact same PCM.

The trick is prediction plus efficient coding, and it is worth one plain-language pass. The encoder looks at the audio in short blocks and fits a simple mathematical predictor that guesses each sample from the ones before it. Music is highly predictable from moment to moment, so the predictor is usually close. The encoder then stores only the small leftover difference between the guess and the true sample — the residual — using a compact number-coding scheme. Because the predictor and the residual together reconstruct the original sample exactly, nothing is lost. It is compression by describing the audio more cleverly, not by deleting any of it.

FLAC (Free Lossless Audio Codec) is the open standard. It was formally specified as IETF RFC 9639 in December 2024 — before that it had only a reference implementation and an informal spec since 2000. FLAC uses Rice coding (a subset of Golomb coding) for the residual, needs no floating-point math to decode, and offers compression levels 0–8: higher levels search harder for a better predictor, producing a slightly smaller file at the cost of slower encoding. Crucially, the compression level changes only file size and encode time — the decoded audio is identical at every level. RFC 9639 also added formal support for 32-bit integer audio.

ALAC (Apple Lossless Audio Codec) is Apple's equivalent, introduced in 2004 and open-sourced under the Apache 2.0 license in October 2011. It uses the same family of ideas — linear prediction plus efficient residual coding — and the reference implementation supports up to 32-bit samples and a wide range of sample rates. Unlike FLAC, ALAC has no user-facing compression-level dial; it uses one fixed algorithm. Its real advantage is native, first-class playback across the Apple ecosystem.

How much do they actually save?

For typical music, FLAC and ALAC compress CD-quality audio to roughly 50–70% of the uncompressed WAV size — call it a bit under half off. The two are very close to each other: across mixed material FLAC is usually within about 1–3% smaller than ALAC, a difference you would not notice on a single album but that adds a few gigabytes across a large library.

A worked example makes the storage case concrete. Take a three-minute stereo track at CD quality (16-bit, 44,100 Hz):

uncompressed size = 44,100 samples/s × 2 bytes × 2 channels × 180 s
                  = 31,752,000 bytes ≈ 31.8 MB  (WAV / AIFF / BWF)
FLAC at ~60%      ≈ 0.60 × 31.8 MB ≈ 19.1 MB
saved per track   ≈ 12.7 MB  (about 40%)

Multiply by a 5,000-track archive and the WAV version needs about 159 GB while the FLAC version needs about 95 GB — the same audio, sample for sample, at roughly 60% of the storage and the matching reduction in transfer cost.

So which do you use?

The decision turns on one question: are you mastering or distributing? For a production master — the file you will edit, mix, or re-encode later — use uncompressed WAV or, in film and broadcast, BWF, because raw PCM is the most compatible thing every tool reads and writes without surprises. For archiving or lossless delivery — the same perfect audio at lower storage and bandwidth — use FLAC for the widest device support, or ALAC when the audience lives inside Apple's ecosystem. Note that lossless of any kind is still far larger than lossy: that 19 MB FLAC track would be about 5 MB as a 192 kbps AAC stream, which is why streaming services deliver lossy to most users and reserve lossless for a premium tier.

Figure 3. Pick the format by the job: uncompressed PCM for masters, FLAC or ALAC for lossless storage and delivery.

Where Fora Soft fits in

In the video products we have built since 2005 — streaming and OTT platforms, e-learning, music-and-video apps, and media archives — the lossless question usually surfaces as a storage-and-pipeline decision rather than a quality one. We keep production and mezzanine masters as uncompressed PCM (WAV or BWF) so every downstream encode starts from a perfect source, then derive lossy delivery renditions from that single master. When a client wants a lossless tier, we reach for FLAC for cross-platform reach and ALAC where the catalogue is Apple-first. The recurring lesson is to separate the master format from the delivery format: get the master right once, and every future format follows cheaply.

What to read next

• What is digital audio: from sound wave to bits
• Bit depth and dynamic range: 16-bit, 24-bit, 32-bit float
• Audio in containers: how MP4, MKV, fMP4, MPEG-TS carry audio

Call to action

• Talk to a audio engineer — book a 30-minute scoping call to talk through your lossless audio formats plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Lossless formats cheat sheet — One-page reference: lossy vs lossless, the PCM-vs-container layer model, WAV/AIFF/BWF compared, FLAC vs ALAC, the 4 GB WAV ceiling and RF64 fix, and a master-vs-delivery decision rule.

References

1. IETF RFC 9639, Free Lossless Audio Codec (FLAC) (December 2024). Proposed Standard. Normative source for the FLAC bitstream: Rice coding (a subset of Golomb coding) for the residual, decode without floating-point math, formal 32-bit audio support, and the streamable subset. https://www.rfc-editor.org/info/rfc9639/
2. Xiph.Org Foundation, FLAC is now formally specified in RFC 9639 (19 December 2024). FLAC had a spec since 2000 and a reference implementation; RFC 9639 changes nothing except adding explicit 32-bit support. https://xiph.org/flac/2024/12/19/rfc-9639-published.html
3. EBU Tech 3285, Specification of the Broadcast Wave Format (BWF) — the bext broadcast extension chunk (Description, Originator, OriginationDate/Time, TimeReference, Version), with EBU R128 loudness metadata added in Version 2 (May 2011). https://tech.ebu.ch/docs/tech/tech3285.pdf
4. EBU Tech 3306, RF64: An extended File Format for Audio (2007/2009). Replaces the RIFF tag with RF64 and stores 64-bit sizes in a ds64 chunk, lifting the 32-bit ~4 GB ceiling. https://tech.ebu.ch/docs/tech/tech3306v1_1.pdf
5. Apple / Mac OS Forge, Apple Lossless Audio Codec (ALAC) reference implementation, open-sourced under the Apache License 2.0 (27 October 2011). Linear-prediction lossless codec; up to 32-bit samples. https://github.com/macosforge/alac
6. AIFF / AIFC Sound File Specifications (Apple, 1988; based on Electronic Arts EA IFF 85, 1985). FORM/COMM/SSND chunk structure; big-endian PCM; sample rate stored as an 80-bit IEEE 754 extended float. https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html
7. Library of Congress, Sustainability of Digital Formats: WAVE Audio File Format and Broadcast WAVE, Versions 1 and 2. RIFF chunk structure, little-endian PCM, 4 GB practical limit, version history. https://www.loc.gov/preservation/digital/formats/fdd/fdd000356.shtml
8. Hydrogenaudio Knowledgebase, ALAC — independent measurement that FLAC and ALAC compress mixed music to a similar size, with FLAC typically a few percent smaller. https://wiki.hydrogenaudio.org/index.php?title=ALAC

Note on source hierarchy (per editorial policy): for the FLAC bitstream and its 32-bit support this article follows the standards document (IETF RFC 9639, 2024) rather than older third-party summaries that predate the RFC and describe FLAC as "spec-less". Compression-ratio ranges are reported as ranges, not single figures, because they depend on material and encoder settings; the integers cited (4 GB limit, levels 0–8) come from the controlling specs (RIFF 32-bit field; RFC 9639).