Sustainability of Digital Formats: Planning for Library of Congress Collections

Open source bitstream encoding format designed for lossless compression of LPCM audio data, with many of its default parameters tuned to CD-quality music data. The encoding is described in Notes, below. The format also includes "transport system" elements that provide a file format for the encoded data. The FLAC Web site indicates that in some applications there may be advantages to using Ogg (or Matroska) as a wrapper. Comments welcome.

The format's sponsors compare FLAC's level of disclosure, player and hardware support, streamability, and cost with those of other lossless codecs at https://xiph.org/flac/comparison.html.

Moderate. Employed by Web sites like Live Music Archive (on this page as a menu item). A number of FLAC-capable devices are listed at the FLAC site. Software tools exist for encoding and decoding, including plug-ins for browser-related online media players like Winamp. These are sometimes included in the application or may be downloaded from https://xiph.org/flac/download.html.

Originally introduced in the 8.1 update for Windows 8, Microsoft's Windows 10 built-in media player apps include native support for FLAC. According to cnet, "FLAC files now show up in Explorer as the new Windows 'G' icon and by default will play in the new Groove player."

Appears to be limited to technical metadata.

From https://xiph.org/flac/format.html: "A FLAC bitstream consists of the 'fLaC' marker at the beginning of the stream, followed by a mandatory metadata block (called the STREAMINFO block), any number of other metadata blocks, then the audio frames. FLAC supports up to 128 kinds of metadata blocks. [The STREAMINFO block] has information about the whole stream, like sample rate, number of channels, total number of samples, etc. It must be present as the first metadata block in the stream. Other metadata blocks may follow, and ones that the decoder doesn't understand, it will skip." Also included in the STREAMINFO block is the MD5 signature of the unencoded audio data.

From https://xiph.org/flac/format.html#def_CUESHEET: [The cuesheet] block is for storing various information that can be used in a cue sheet. It supports track and index points, compatible with Red Book CD digital audio discs, as well as other CD-DA metadata such as media catalog number and track ISRCs. The CUESHEET block is especially useful for backing up CD-DA discs, but it can be used as a general purpose cueing mechanism for playback.

Transport system, native file format. (from https://xiph.org/flac/ogg_mapping.html):
The original FLAC format includes a very thin transport system. This system of compressed FLAC audio data mixed with a thin transport has come to be known as 'native FLAC'. The transport consists of audio frame headers and footers which contain synchronization patterns, timecodes, and checksums (but notably not frame lengths), and a metadata system. It is very lightweight and does not support more elaborate transport mechanisms such as multiple logical streams, but it has served its purpose well. The native FLAC transport is not a transport "layer" in the way of standard codec design because it cannot be entirely separated from the payload. Though the metadata system can be separated, the frame header includes both data that belongs in the transport (sync pattern, timecode, checksum) and data that belongs in the compressed packets (audio parameters like channel assignments, sample rate, etc).

Coding. (from https://xiph.org/flac/format.html):
Encoding stages include:

• Blocking. The input is broken up into many contiguous blocks. With FLAC, the blocks may vary in size. The optimal size of the block is usually affected by many factors, including the sample rate, spectral characteristics over time, etc. Though FLAC allows the block size to vary within a stream, the reference encoder uses a fixed block size.
• Interchannel Decorrelation. In the case of stereo streams, the encoder will create mid and side signals based on the average and difference (respectively) of the left and right channels. The encoder will then pass the best form of the signal to the next stage.
• Prediction. The block is passed through a prediction stage where the encoder tries to find a mathematical description (usually an approximate one) of the signal. This description is typically much smaller than the raw signal itself. Since the methods of prediction are known to both the encoder and decoder, only the parameters of the predictor need be included in the compressed stream. FLAC currently uses four different classes of predictors . . . , but the format has reserved space for additional methods. FLAC allows the class of predictor to change from block to block, or even within the channels of a block.
• Residual coding. If the predictor does not describe the signal exactly, the difference between the original signal and the predicted signal (called the error or residual signal) must be coded losslessy. If the predictor is effective, the residual signal will require fewer bits per sample than the original signal. FLAC currently uses only one method for encoding the residual (see the Residual coding section), but the format has reserved space for additional methods.

Versions. Information about FLAC versions is provided on the FLAC changelog page.

FLAC appears to have been developed by Josh Coalson; the FLAC Web site carries Coalson's name in copyright notices dated from 2000 forward. The Wikipedia FLAC entry (consulted on September 14, 2007) states that on "January 29th, 2003, Xiphophorus (now called the Xiph.Org Foundation) announced the incorporation of FLAC under their Xiph.Org banner, to go along with Ogg Vorbis, Ogg Theora, and Speex."

As of October 2013, documentation had migrated from a sourceforge wiki to xiph.org. In May 2013, the first software update in six years, to version 1.3.0, was published.

An offshoot of the European-based PREFORMA project, which aims "to address the challenge of implementing good quality standardised file formats for preserving data content in the long term," Codec Encoding for LossLess Archiving and Realtime transmission (cellar) is an IETF-approved project to standardize FLAC, Matroska,  and FFV1.