Identification and description

Full name

FLAC (Free Lossless Audio Codec), Version 1.1.2

Description

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.

FLAC, Version 1.1.3 (November 2005, not documented at this Web site at this time)

Has later version

FLAC, Version 1.1.4 (February 2007, not documented at this Web site at this time)

Has later version

FLAC, Version 1.2.0 (Not documented at this Web site at this time)

Has later version

FLAC, Version 1.3.0 (June 2013, not documented at this Web site at this time)

Local use

LC experience or existing holdings

None. In late 2005, there was preliminary discussion within the Library's Motion Picture, Broadcasting, and Recorded Sound Division concerning the use of FLAC files as on-premises listening copies of preservation-project masters. By 2007, system redesign and increasing bandwidth to the reading (i.e., listening) rooms meant that uncompressed WAVE_LPCM could be provided and the FLAC proposal was set aside.

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.

Licensing and patents

Documentation and tools are freely distributed under Xiph's variant of the BSD open-source license.

Transparency

Depends upon algorithms and tools to read; requires sophistication to build tools.

Self-documentation

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.

From https://xiph.org/flac/faq.html#general__channels: "FLAC supports from 1 to 8 channels per stream. Channels are only grouped in FLAC to take advantage of interchannel correlation and to define common channel assignments (like stereo L/R, 5.1 surround, et cetera). When encoding a large number of independent channels it is expected that they are coded separately and if required, multiplexed together in a suitable container like Ogg or Matroska."

Support for user-defined sounds, samples, and patches

Not applicable.

Functionality beyond normal rendering

One specialist in the field reports two fixity elements in FLAC: first,"the header of a FLAC file contains an MD5 checksum or signature that represents the original audio data that is encoded," and second that "deeper within the FLAC file, audio samples are grouped into audio frames which themselves are checksummed with a crc value." In addition, the specification reports that FLAC is streamable in a computer network if some constraints are applied; see . Later versions (post 1.1.2) include support for images and other content elements.

Notes

General

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).

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.

History

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.