xiph/flac: the reference implementation of the Free Lossless Audio Codec

What xiph/flac is, and who needs a reference implementation

FLAC is open source software that reduces the storage space needed for digital audio without removing information, according to the README. The files it reads and writes are FLAC files, and because other software can read and write the same format, the project describes itself as the FLAC reference implementation. That word, reference, is the whole reason to pick this repository over a binding or a wrapper. When two FLAC tools disagree about a stream, the behaviour of this code is the behaviour everyone else is measured against.

The audience is narrower than the format's popularity suggests. You are in the target group if you are writing a decoder and want something to compare against, if you are building an encoder and need the reference encoder's output, if you maintain a media pipeline that must store audio without generation loss, or if you need to inspect and edit FLAC metadata from a script. You are not in the target group if your problem is file size on a phone. Lossless compression keeps every sample, so the ceiling on compression is set by the audio itself.

libFLAC, libFLAC++, flac and metaflac: the four moving parts

The project is not one binary. The README lists libFLAC, a library implementing reference encoders and decoders for native FLAC and Ogg FLAC plus a metadata interface; libFLAC++, a C++ object wrapper around libFLAC; the flac command line program for encoding and decoding; and metaflac for viewing and editing metadata. Documentation for the two tools lives in the man directory as flac.md and metaflac.md, and the API documentation is Doxygen output under doc/html/api.

That split matters when you plan a dependency. An application that only plays files needs libFLAC and nothing else. An application that only tags files needs metaflac's metadata interface, or the library underneath it. The C++ wrapper exists so that C++ callers do not have to manage the C API by hand, but it is a separate library with a separate build, not a header-only convenience. The data flow is conventional for a codec: a stream is parsed into frames, the metadata interface reads and writes blocks such as the stream information and any application-specific blocks, and the decoder reconstructs samples that must match the original exactly. The README does not describe internal frame layout here; it points at the format specification instead, which now lives outside the repository.

Building xiph/flac with CMake or autotools

The README states that all components build with a variety of compilers, including GCC, Clang, Visual Studio and the Intel C++ Compiler, on x86, x86_64, ARMv7, ARMv8 and PowerPC. Two build systems are provided, autotools and CMake, and the README calls them equivalent for most use cases while noting they differ slightly in configuration options. The Visual Studio project files that once existed have been removed in favour of CMake.

The recommended sequence is an out-of-tree build. From an empty build directory, point CMake at the source tree:

/path/to/flac-build$ cmake /path/to/flac-source
/path/to/flac-build$ make
/path/to/flac-build$ make test
/path/to/flac-build$ make install

CMake generates build scripts for the default system, which on UNIX means Makefiles. The test target runs the project's own tests, and install places the built libraries and headers. To use a different generator, pass -G; the README gives Ninja and Xcode as examples:

/path/to/flac-build$ cmake /path/to/flac-source -GNinja
/path/to/flac-build$ ninja

OGG is the one dependency that surprises people. CMake searches for OGG by default, and if it cannot find it you can point at it directly with -DOGG_ROOT. To build without OGG support, disable it explicitly:

/path/to/flac-build$ cmake /path/to/flac-source -DWITH_OGG=OFF

To see the full option list, including whether to build the C++ library or the documentation, run cmake with -LH. Visual Studio users are pointed at the CMake GUI: choose a source directory and a build directory outside the repository, press Configure, pick the Visual Studio version and the Win32 or x64 target, then Generate and Open Project. The README warns that files generated this way are regenerated by CMake, so edits such as extra compile flags are lost.

Where xiph/flac is the wrong tool

The honest limitation is in the first sentence of the README: FLAC reduces storage space without removing information. That is a guarantee, and it is also a floor. A FLAC file cannot be smaller than the entropy of its own audio, so on a device with a hard storage or bandwidth budget, a lossy codec will win by a margin that no encoder setting closes. Choosing FLAC for a streaming service aimed at mobile data is a design error, not a tuning problem.

There are smaller constraints too. Ogg FLAC support is a build-time decision, so a binary compiled with WITH_OGG=OFF will not handle Ogg containers at all, and that is a property of the build rather than a runtime option. The format specification is no longer shipped in the repository: the README says documentation of the FLAC format was included in previous releases but can now be found at the IETF datatracker draft, with conformance files in a separate repository. If you are implementing the format independently of libFLAC, you are now following two external sources rather than one local document. And the API documentation is only present in a release tarball; from a git checkout you must generate it with Doxygen yourself, which the README states plainly.

FLAC versus the lossy and uncompressed options

The two comparisons people actually make are FLAC against MP3 and FLAC against WAV, and the difference in approach is the same in both cases. A lossy codec such as MP3 discards information that a perceptual model says listeners will not miss; the encoder's job is to decide what to throw away. FLAC's encoder does not make that decision at all. It compresses the sample data and keeps everything, so decoding returns the original samples exactly. Against WAV, the trade is the reverse: WAV stores uncompressed samples, so it is larger and trivially readable, while FLAC spends CPU to shrink the same audio losslessly and requires a decoder to get it back.

That places the three formats on a single axis rather than in competition. WAV is the largest and the simplest. FLAC sits in the middle: smaller than WAV, larger than MP3, exact. MP3 is the smallest and the only one that cannot be reversed. If your pipeline has a stage where audio is edited, archived or re-encoded repeatedly, lossless storage prevents generation loss from accumulating across passes. If the audio is only ever played once, that protection buys nothing.

Licensing across the FLAC components

Licence terms are not uniform across this repository, and the README is explicit about the split. The codec libraries, libFLAC and libFLAC++, are distributed under Xiph.Org's BSD-like licence, described in COPYING.Xiph. All other programs and plugins are under the GNU General Public License, in COPYING.GPL, and the LGPL text is present as COPYING.LGPL. The documentation is under the GNU Free Documentation License, in COPYING.FDL. The repository carries all four files at the top level, and the README notes that each file in the distribution states at the top the terms under which it may be distributed.

The practical consequence is that linking libFLAC into a proprietary application and shipping the flac command line tool are two different licensing situations, and you should read the specific files rather than assume one licence covers the project. This is a description of what the repository says, not legal advice; the component you actually link determines which file you need to read.

Maintenance and upgrade expectations

The repository is not archived, and the last push was on 2026-07-19. Releases are infrequent and large: 1.5.0 arrived on 2025-02-11, preceded by 1.4.3 on 2023-06-23 and 1.4.2 on 2022-10-22. That cadence is normal for a format that is meant to be stable, but it has an operational cost. If you track master, you are tracking a branch that moves between releases with no promise of API stability in between. If you track release tarballs, you may go a year or more between upgrades, which means security fixes and platform support arrive in batches rather than continuously.

Upgrade cost is dominated by the build, not the API. The two build systems differ slightly in configuration options, so a project that pins autotools flags and later moves to CMake has to re-map them, and the OGG decision is one of the options that lives in that difference. The CHANGELOG.md file at the top level is where release-to-release changes are described, and it is the file to read before bumping a pinned version. The README does not document a rollback procedure, so plan for the fact that downgrading means rebuilding the previous version yourself.

Editorial conclusion

Adopt xiph/flac if you need a reference encoder, decoder or metadata editor that other FLAC software is expected to interoperate with, and if you can accept a C build with CMake or autotools and a split licence across components. Do not adopt it as a general purpose compressed audio format for constrained storage or bandwidth: it is lossless, so it removes no audio information and cannot reach the size of a lossy codec. Before building, check three things in the repository itself: whether you need OGG support, since CMake searches for it and can be told WITH_OGG=OFF, which licence file applies to the component you are linking, and whether a release tarball already contains the Doxygen API documentation you would otherwise have to generate from a git checkout.

Frequently asked questions

Official sources

1. License: GFDL-1.3
2. Project website
3. README
4. Releases
5. xiph/flac on GitHub