FLAC File Documentation

---

Technical details

Feature	Value
Full name	Free Lossless Audio Codec
File extension	.flac
MIME type	audio/flac
Format type	Lossless compressed audio (native stream; can also ride in Ogg)
Developer	Xiph.Org Foundation (originally Josh Coalson)
Introduced	2001 (v1.0)
Standard	IETF RFC 9639 (December 2024)
Open standard	Yes — open, royalty-free
Compression	Lossless (linear prediction + Rice coding); ~50–70% of WAV
Byte order	Big-endian headers; frame sync at bit level
Magic number	66 4C 61 43 (“fLaC”)
First block	STREAMINFO (mandatory, 34 bytes)
Bit depth	4–32 bits per sample (32-bit added in RFC 9639)
Sample rate	Up to 655,350 Hz (commonly 44.1–192 kHz)
Channels	1–8 (stereo uses inter-channel decorrelation)
Tagging	VORBIS_COMMENT (same scheme as Ogg Vorbis)
Reference codec	libFLAC / flac CLI (v1.5.0, Feb 2025)
Related extensions	.wav, .mp3, .alac, .ogg, .opus
Specification	datatracker.ietf.org/doc/rfc9639/

What is a FLAC file?

FLAC stands for Free Lossless Audio Codec, an open, royalty-free format for compressing audio without discarding any data. Decompressing a FLAC file reproduces the original samples bit for bit, so a FLAC made from a CD decodes back to exactly the CD’s audio. It was created by Josh Coalson and first released in 2001, and is maintained by the Xiph.Org Foundation, the same organisation behind Ogg, Vorbis and Opus. Typical FLAC compression brings a file down to roughly 50–70% of the original WAV size, which made it the de-facto standard for ripping CDs, archiving music, and selling hi-res audio (24-bit at 96 or 192 kHz) on stores like Bandcamp and Qobuz.

FLAC is now a formal Internet standard: the IETF published RFC 9639 in December 2024, precisely specifying the format after two decades of a de-facto specification, and adding 32-bit integer audio support. The reference encoder and decoder reached version 1.5.0 in February 2025, adding multi-threaded encoding. Unlike lossy MP3 or AAC, FLAC keeps every sample, so the trade-off is larger files than lossy formats in exchange for exact fidelity.

The stream layout: marker, metadata blocks, frames

A native FLAC bitstream has three parts in order: the four-byte fLaC marker, then a run of metadata blocks, then the compressed audio frames. The marker is the ASCII string fLaC (66 4C 61 43) at offset 0. The metadata blocks describe the stream; the frames carry the sound.

"fLaC"                      4-byte stream marker
METADATA_BLOCK  STREAMINFO   (mandatory, always first)
METADATA_BLOCK  VORBIS_COMMENT / SEEKTABLE / PICTURE ... (optional)
METADATA_BLOCK  ... (last one has its "last-block" flag set)
FRAME
FRAME
...                          the losslessly compressed audio

Every metadata block starts with a 4-byte header. The top bit of the first byte is the last-metadata-block flag: it is 0 for every block except the final one, so a reader knows when the metadata ends and the audio frames begin. The remaining 7 bits of that byte give the block type (0 for STREAMINFO, 4 for VORBIS_COMMENT, 3 for SEEKTABLE, 6 for PICTURE, and so on). The next three bytes are a 24-bit big-endian length giving the size of the block body that follows.

The STREAMINFO block: 34 bytes that describe the whole stream

The first metadata block is always STREAMINFO, and it is mandatory. Its body is a fixed 34 bytes and holds the parameters a decoder needs before it can play a single frame: the sample rate, channel count, bit depth and total length, plus block-size bounds and an integrity hash.

STREAMINFO body (34 bytes, bit-packed, big-endian)
  16 bits  minimum block size (samples)
  16 bits  maximum block size (samples)
  24 bits  minimum frame size (bytes, 0 = unknown)
  24 bits  maximum frame size (bytes, 0 = unknown)
  20 bits  sample rate (Hz)
   3 bits  (channels - 1)          -> 1 to 8 channels
   5 bits  (bits per sample - 1)   -> up to 32-bit in RFC 9639
  36 bits  total samples in stream (0 = unknown)
 128 bits  MD5 of the unencoded audio

Two fields deserve attention. The sample rate is stored in 20 bits, which is why FLAC can describe rates far above the audible range (up to 655,350 Hz). The final field is a 128-bit MD5 signature of the decoded PCM audio. Because it hashes the audio before compression, a decoder can re-compute the MD5 of what it decoded and compare, giving a built-in integrity check that proves the file decompressed correctly. The flac -t test command uses exactly this.

VORBIS_COMMENT, SEEKTABLE and PICTURE

After STREAMINFO come optional blocks. VORBIS_COMMENT holds the tags — artist, album, title, track number — using the same human-readable FIELD=value scheme as Ogg Vorbis, which is why FLAC and Vorbis share tagging tools. SEEKTABLE holds an optional list of seek points, each mapping a sample number to a byte offset and a frame, so a player can jump to a position in a long file without scanning from the start. PICTURE embeds cover art (typically a JPEG or PNG) along with its type, MIME type and dimensions. Because these are all standalone blocks with a type and a length, a decoder that does not recognise a block simply reads its length and skips it, which keeps the format extensible.

Frames, subframes and the frame sync

The audio itself is divided into frames, each covering a fixed number of samples (the block size). A frame begins with a frame header that starts with a 14-bit sync code, the bit pattern 11111111111110, which lets a decoder find frame boundaries even when starting mid-stream. The header also encodes the block size, the sample rate, the channel assignment and, in variable-block-size streams, the sample number of the first sample in the frame, and it ends with a CRC-8 over the header bytes. Each frame ends with a CRC-16 over the whole frame, so both the header and the frame body are checksummed independently.

Inside a frame, each channel is coded as a separate subframe. For stereo, FLAC first decorrelates the two channels: instead of storing left and right independently, it can store, for example, a mid (average) channel and a side (difference) channel, because the two channels of real music are highly correlated and the difference compresses much smaller. The frame header’s channel-assignment field records which decorrelation was used (independent, left/side, right/side, or mid/side).

Linear prediction and Rice coding

FLAC’s losslessness comes from a two-stage method applied to each subframe: predict, then encode the small leftover. First it models the samples with a linear predictor, estimating each sample from a weighted sum of the preceding ones. A signal that is smooth or periodic (which most audio is) is predicted well, so the difference between the prediction and the true sample — the residual — is a stream of small numbers clustered near zero. FLAC supports fixed polynomial predictors and, for better compression, LPC predictors whose coefficients are computed per subframe and stored in the subframe header.

The residual is then entropy-coded with Rice coding (a special case of Golomb coding), which is efficient for exactly this kind of small, zero-centred data: it spends few bits on common small values and more on rare large ones. Because the whole chain is reversible — the decoder re-runs the predictor and adds back the exactly-reconstructed residual — no information is lost. Higher encoder settings (flac -8) search harder for better predictor orders and Rice parameters, producing smaller files at the cost of encoding time, but every setting is lossless and decodes identically.

Native FLAC versus FLAC-in-Ogg

The audio and metadata described above can be packaged two ways. The common one is the native FLAC stream, which begins with fLaC and is what a .flac file normally is. The same FLAC frames can instead be carried inside an Ogg container, which begins with OggS; Ogg-FLAC is useful for streaming and for multiplexing with other streams, but is less common for stored files. Both hold identical lossless audio; only the outer framing differs, which is why a player must check the leading bytes rather than assume the container from the extension.

Frequently asked questions

Does converting FLAC to WAV lose quality?

No. Both are lossless, so FLAC-to-WAV is bit-perfect: the WAV contains exactly the PCM samples FLAC decoded, which the STREAMINFO MD5 can verify. WAV is simply uncompressed, so the file becomes much larger and loses FLAC’s tag metadata, because WAV has no standard tagging scheme.

Why does FLAC store an MD5 of the audio?

The 128-bit MD5 in STREAMINFO hashes the original uncompressed audio. After decoding, a tool can re-hash the samples it produced and compare against the stored value, proving the file decompressed to exactly the original data. This is a built-in integrity check, separate from the per-frame CRCs that guard against bitstream corruption.

Why is a FLAC file bigger than an MP3?

Because FLAC is lossless and MP3 is lossy. MP3 permanently discards audio detail judged inaudible to reach small sizes; FLAC keeps every sample and only removes statistical redundancy through prediction and Rice coding. The result is exact reproduction at a larger size — typically several times bigger than a 320 kbit/s MP3 of the same track.

References

• IETF RFC 9639 — Free Lossless Audio Codec (FLAC)
• Xiph.Org — FLAC format documentation
• Xiph.Org — FLAC official site

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.