RFC 9639: Free Lossless Audio Codec (FLAC)

4.1. Blocking

The block size used for audio data has a direct effect on the compression ratio. If the block size is too small, the resulting large number of frames means that a disproportionate number of bytes will be spent on frame headers. If the block size is too large, the characteristics of the signal may vary so much that the encoder will be unable to find a good predictor. In order to simplify encoder/decoder design, FLAC imposes a minimum block size of 16 samples, except for the last block, and a maximum block size of 65535 samples. The last block is allowed to be smaller than 16 samples to be able to match the length of the encoded audio without using padding.¶

While the block size does not have to be constant in a FLAC file, it is often difficult to find the optimal arrangement of block sizes for maximum compression. Because of this, a FLAC stream has explicitly either a constant or variable block size throughout and stores a block number instead of a sample number to slightly improve compression if a stream has a constant block size.¶

4.2. Interchannel Decorrelation

Channels are correlated in many audio files. The FLAC format can exploit this correlation in stereo files by coding an average of all samples in both subblocks (a mid channel) or the difference between all samples in both subblocks (a side channel) instead of directly coding subblocks into subframes. The following combinations are possible:¶

The side channel needs one extra bit of bit depth, as the subtraction can produce sample values twice as large as the maximum possible in any given bit depth. The mid channel in mid-side stereo does not need one extra bit, as it is shifted right 1 bit. The right shift of the mid channel does not lead to lossy behavior because an odd sample in the mid subframe must always be accompanied by a corresponding odd sample in the side subframe, which means the lost least-significant bit can be restored by taking it from the sample in the side subframe.¶

4.3. Prediction

The FLAC format has four methods for modeling the input signal:¶

A FLAC encoder is free to select any of the above methods to model the input. However, to ensure lossless coding, the following exceptions apply:¶

For more information on fixed and linear predictors, see [Lossless-Compression] and [Robinson-TR156].¶

4.4. Residual Coding

If a subframe uses a predictor to approximate the audio signal, a residual is stored to "correct" the approximation to the exact value. When an effective predictor is used, the average numerical value of the residual samples is smaller than that of the samples before prediction. While having smaller values on average, it is possible that a few "outlier" residual samples are much larger than any of the original samples. Sometimes these outliers even exceed the range that the bit depth of the original audio offers.¶

To efficiently code such a stream of relatively small numbers with an occasional outlier, Rice coding (a subset of Golomb coding) is used. Depending on how small the numbers are that have to be coded, a Rice parameter is chosen. The numerical value of each residual sample is split into two parts by dividing it by 2^{(Rice parameter)}, creating a quotient and a remainder. The quotient is stored in unary form and the remainder in binary form. If indeed most residual samples are close to zero and a suitable Rice parameter is chosen, this form of coding, with a so-called variable-length code, uses fewer bits than the residual in unencoded form.¶

As Rice codes can only handle unsigned numbers, signed numbers are zigzag encoded to a so-called folded residual. See Section 9.2.7 for a more thorough explanation.¶

Quite often, the optimal Rice parameter varies over the course of a subframe. To accommodate this, the residual can be split up into partitions, where each partition has its own Rice parameter. To keep overhead and complexity low, the number of partitions used in a subframe is limited to powers of two.¶

The FLAC format uses two forms of Rice coding, which only differ in the number of bits used for encoding the Rice parameter, either 4 or 5 bits.¶

8.1. Metadata Block Header

Each metadata block starts with a 4-byte header. The first bit in this header flags whether a metadata block is the last one. It is 0 when other metadata blocks follow; otherwise, it is 1. The 7 remaining bits of the first header byte contain the type of the metadata block as an unsigned number between 0 and 126, according to the following table. A value of 127 (i.e., 0b1111111) is forbidden. The three bytes that follow code for the size of the metadata block in bytes, excluding the 4 header bytes, as an unsigned number coded big-endian.¶

8.2. Streaminfo

The streaminfo metadata block has information about the whole stream, such as 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. There MUST be no more than one streaminfo metadata block per FLAC stream.¶

If the streaminfo metadata block contains incorrect or incomplete information, decoder behavior is left unspecified (i.e., it is up to the decoder implementation). A decoder MAY choose to stop further decoding when the information supplied by the streaminfo metadata block turns out to be incorrect or contains forbidden values. A decoder accepting information from the streaminfo metadata block (most significantly, the maximum frame size, maximum block size, number of audio channels, number of bits per sample, and total number of samples) without doing further checks during decoding of audio frames could be vulnerable to buffer overflows. See also Section 11.¶

The following table describes the streaminfo metadata block in order, excluding the metadata block header.¶

The minimum block size and the maximum block size MUST be in the 16-65535 range. The minimum block size MUST be equal to or less than the maximum block size.¶

Any frame but the last one MUST have a block size equal to or greater than the minimum block size and MUST have a block size equal to or less than the maximum block size. The last frame MUST have a block size equal to or less than the maximum block size; it does not have to comply to the minimum block size because the block size of that frame must be able to accommodate the length of the audio data the stream contains.¶

If the minimum block size is equal to the maximum block size, the file contains a fixed block size stream, as the minimum block size excludes the last block. Note that in the case of a stream with a variable block size, the actual maximum block size MAY be smaller than the maximum block size listed in the streaminfo metadata block, and the actual smallest block size excluding the last block MAY be larger than the minimum block size listed in the streaminfo metadata block. This is because the encoder has to write these fields before receiving any input audio data and cannot know beforehand what block sizes it will use, only between what bounds the block sizes will be chosen.¶

The sample rate MUST NOT be 0 when the FLAC file contains audio. A sample rate of 0 MAY be used when non-audio is represented. This is useful if data is encoded that is not along a time axis or when the sample rate of the data lies outside the range that FLAC can represent in the streaminfo metadata block. If a sample rate of 0 is used, it is recommended to store the meaning of the encoded content in a Vorbis comment field (see Section 8.6) or an application metadata block (see Section 8.4). This document does not define such metadata.¶

The MD5 checksum is computed by applying the MD5 message-digest algorithm in [RFC1321]. The message to this algorithm consists of all the samples of all channels interleaved, represented in signed, little-endian form. This interleaving is on a per-sample basis, so for a stereo file, this means the first sample of the first channel, then the first sample of the second channel, then the second sample of the first channel, etc. Before computing the checksum, all samples must be byte-aligned. If the bit depth is not a whole number of bytes, the value of each sample is sign-extended to the next whole number of bytes.¶

In the case of a 2-channel stream with 6-bit samples, bits will be lined up as follows:¶

SSAAAAAASSBBBBBBSSCCCCCC
^   ^   ^   ^   ^   ^
|   |   |   |   |  Bits of 2nd sample of 1st channel
|   |   |   |  Sign extension bits of 2nd sample of 2nd channel
|   |   |  Bits of 1st sample of 2nd channel
|   |  Sign extension bits of 1st sample of 2nd channel
|  Bits of 1st sample of 1st channel
Sign extension bits of 1st sample of 1st channel

In the case of a 1-channel stream with 12-bit samples, bits are lined up in little-endian byte order as follows:¶

AAAAAAAASSSSAAAABBBBBBBBSSSSBBBB
   ^     ^   ^   ^       ^   ^
   |     |   |   |       |  Most-significant 4 bits of 2nd sample
   |     |   |   | Sign extension bits of 2nd sample
   |     |   |  Least-significant 8 bits of 2nd sample
   |     |  Most-significant 4 bits of 1st sample
   |    Sign extension bits of 1st sample
  Least-significant 8 bits of 1st sample

8.3. Padding

The padding metadata block allows for an arbitrary amount of padding. This block is useful when it is known that metadata will be edited after encoding; the user can instruct the encoder to reserve a padding block of sufficient size so that when metadata is added, it will simply overwrite the padding (which is relatively quick) instead of having to insert it into the existing file (which would normally require rewriting the entire file). There MAY be one or more padding metadata blocks per FLAC stream.¶

8.4. Application

The application metadata block is for use by third-party applications. The only mandatory field is a 32-bit application identifier (application ID). Application IDs are registered in the IANA "FLAC Application Metadata Block IDs" registry (see Section 12.2).¶

8.5. Seek Table

The seek table metadata block can be used to store seek points. It is possible to seek to any given sample in a FLAC stream without a seek table, but the delay can be unpredictable since the bitrate may vary widely within a stream. By adding seek points to a stream, this delay can be significantly reduced. There MUST NOT be more than one seek table metadata block in a stream, but the table can have any number of seek points.¶

Each seek point takes 18 bytes, so a seek table with 1% resolution within a stream adds less than 2 kilobytes of data. The number of seek points is implied by the size described in the metadata block header, i.e., equal to size / 18. There is also a special "placeholder" seek point that will be ignored by decoders but can be used to reserve space for future seek point insertion.¶

A seek table is generally not usable for seeking in a FLAC file embedded in a container (see Section 10), as such containers usually interleave FLAC data with other data and the offsets used in seek points are those of an unmuxed FLAC stream. Also, containers often provide their own seeking methods. However, it is possible to store the seek table in the container along with other metadata when muxing a FLAC file, so this stored seek table can be restored when demuxing the FLAC stream into a standalone FLAC file.¶

8.6. Vorbis Comment

A Vorbis comment metadata block contains human-readable information coded in UTF-8. The name "Vorbis comment" points to the fact that the Vorbis codec stores such metadata in almost the same way (see [Vorbis]). A Vorbis comment metadata block consists of a vendor string optionally followed by a number of fields, which are pairs of field names and field contents. The vendor string contains the name of the program that generated the file or stream. The fields contain metadata describing various aspects of the contained audio. Many users refer to these fields as "FLAC tags" or simply as "tags". A FLAC file MUST NOT contain more than one Vorbis comment metadata block.¶

In a Vorbis comment metadata block, the metadata block header is directly followed by 4 bytes containing the length in bytes of the vendor string as an unsigned number coded little-endian. The vendor string follows, is UTF-8 coded and is not terminated in any way.¶

Following the vendor string are 4 bytes containing the number of fields that are in the Vorbis comment block, stored as an unsigned number coded little-endian. If this number is non-zero, it is followed by the fields themselves, each of which is stored with a 4-byte length. For each field, the field length in bytes is stored as a 4-byte unsigned number coded little-endian. The field itself follows it. Like the vendor string, the field is UTF-8 coded and not terminated in any way.¶

Each field consists of a field name and field contents, separated by an = character. The field name MUST only consist of UTF-8 code points U+0020 through U+007E, excluding U+003D, which is the = character. In other words, the field name can contain all printable ASCII characters except the equals sign. The evaluation of the field names MUST be case insensitive, so U+0041 through 0+005A (A-Z) MUST be considered equivalent to U+0061 through U+007A (a-z). The field contents can contain any UTF-8 character.¶

Note that the Vorbis comment as used in Vorbis allows for 2⁶⁴ bytes of data whereas the FLAC metadata block is limited to 2²⁴ bytes. Given the stated purpose of Vorbis comments, i.e., human-readable textual information, the FLAC metadata block limit is unlikely to be restrictive. Also, note that the 32-bit field lengths are coded little-endian as opposed to the usual big-endian coding of fixed-length integers in the rest of the FLAC format.¶

8.7. Cuesheet

A cuesheet metadata block can be used either to store the track and index point structure of a Compact Disc Digital Audio (CD-DA) along with its audio or to provide a mechanism to store locations of interest within a FLAC file. Certain aspects of this metadata block come directly from the CD-DA specification (called Red Book), which is standardized as [IEC.60908.1999]. The description below is complete, and further reference to [IEC.60908.1999] is not needed to implement this metadata block.¶

The structure of a cuesheet metadata block is enumerated in the following table.¶

If the media catalog number is less than 128 bytes long, it is right-padded with 0x00 bytes. For CD-DA, this is a 13-digit number followed by 115 0x00 bytes.¶

The number of lead-in samples has meaning only for CD-DA cuesheets; for other uses, it should be 0. For CD-DA, the lead-in is the TRACK 00 area where the table of contents is stored; more precisely, it is the number of samples from the first sample of the media to the first sample of the first index point of the first track. According to [IEC.60908.1999], the lead-in MUST be silent, and CD grabbing software does not usually store it; additionally, the lead-in MUST be at least two seconds but MAY be longer. For these reasons, the lead-in length is stored here so that the absolute position of the first track can be computed. Note that the lead-in stored here is the number of samples up to the first index point of the first track, not necessarily to INDEX 01 of the first track; even the first track MAY have INDEX 00 data.¶

The number of tracks MUST be at least 1, as a cuesheet block MUST have a lead-out track. For CD-DA, this number MUST be no more than 100 (99 regular tracks and one lead-out track). The lead-out track is always the last track in the cuesheet. For CD-DA, the lead-out track number MUST be 170 as specified by [IEC.60908.1999]; otherwise, it MUST be 255.¶

8.8. Picture

The picture metadata block contains image data of a picture in some way belonging to the audio contained in the FLAC file. Its format is derived from the Attached Picture (APIC) frame in the ID3v2 specification; see [ID3v2]. However, contrary to the APIC frame in ID3v2, the media type and description are prepended with a 4-byte length field instead of being 0x00 delimited strings. A FLAC file MAY contain one or more picture metadata blocks.¶

Note that while the length fields for media type, description, and picture data are 4 bytes in length and could code for a size up to 4 GiB in theory, the total metadata block size cannot exceed what can be described by the metadata block header, i.e., 16 MiB.¶

Instead of picture data, the picture metadata block can also contain a URI as described in [RFC3986].¶

The structure of a picture metadata block is enumerated in the following table.¶

The height, width, color depth, and "number of colors" fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display it, but applications MAY use them to decide whether or not to process a block (e.g., when selecting between different picture blocks) and MAY show them to the user. If a picture has no concept for any of these fields (e.g., vector images may not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero.¶

The following table contains all the defined picture types. Values other than those listed in the table are reserved. There MAY only be one each of picture types 1 and 2 in a file. In general practice, many FLAC playback devices and software display the contents of a picture metadata block, if present, with picture type 3 (front cover) during playback.¶

The origin and use of value 17 ("A bright colored fish") is unclear. This was copied to maintain compatibility with ID3v2. Applications are discouraged from offering this value to users when embedding a picture.¶

If a URI (not a picture) is contained in this block, the following points apply:¶

9.1. Frame Header

Each frame MUST start on a byte boundary and start with the 15-bit frame sync code 0b111111111111100. Following the sync code is the blocking strategy bit, which MUST NOT change during the audio stream. The blocking strategy bit is 0 for a fixed block size stream or 1 for a variable block size stream. If the blocking strategy is known, a decoder can include this bit when searching for the start of a frame to reduce the possibility of encountering a false positive, as the first two bytes of a frame are either 0xFFF8 for a fixed block size stream or 0xFFF9 for a variable block size stream.¶

Octets 1-5
0b11111110 0b10101111 0b10011111 0b10110101 0b10100011
               ^^^^^^     ^^^^^^     ^^^^^^     ^^^^^^
                 |          |          |      Bits 18-13
                 |          |      Bits 24-19
                 |      Bits 30-25
             Bits 36-31

Octets 6-7
0b10111000 0b10000000
    ^^^^^^     ^^^^^^
      |       Bits 6-1
  Bits 12-7

9.2. Subframes

Following the frame header are a number of subframes equal to the number of audio channels. Note that subframes contain a bitstream that does not necessarily have to be a whole number of bytes, so only the first subframe starts at a byte boundary.¶

9.3. Frame Footer

Following the last subframe is the frame footer. If the last subframe is not byte aligned (i.e., the number of bits required to store all subframes put together is not divisible by 8), zero bits are added until byte alignment is reached. Following this is a 16-bit CRC, initialized with 0, with the polynomial x¹⁶ + x¹⁵ + x² + x⁰. This CRC covers the whole frame, excluding the 16-bit CRC but including the sync code.¶

10.1. Ogg Mapping

The Ogg container format is defined in [RFC3533]. The first packet of a logical bitstream carrying FLAC data is structured according to the following table.¶

The number of header packets MAY be 0, which means the number of packets that follow is unknown. This first packet MUST NOT share a Ogg page with any other packets. This means the first page of a logical stream of FLAC-in-Ogg is always 79 bytes.¶

Following the first packet are one or more header packets, each of which contains a single metadata block. The first of these packets SHOULD be a Vorbis comment metadata block for historic reasons. This is contrary to unencapsulated FLAC streams, where the order of metadata blocks is not important except for the streaminfo metadata block and where a Vorbis comment metadata block is optional.¶

Following the header packets are audio packets. Each audio packet contains a single FLAC frame. The first audio packet MUST start on a new Ogg page, i.e., the last metadata block MUST finish its page before any audio packets are encapsulated.¶

The granule position of all pages containing header packets MUST be 0. For pages containing audio packets, the granule position is the number of the last sample contained in the last completed packet in the frame. The sample numbering considers interchannel samples. If a page contains no packet end (e.g., when it only contains the start of a large packet that continues on the next page), then the granule position is set to the maximum value possible, i.e., 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF.¶

The granule position of the first audio data page with a completed packet MAY be larger than the number of samples contained in packets that complete on that page. In other words, the apparent sample number of the first sample in the stream following from the granule position and the audio data MAY be larger than 0. This allows, for example, a server to cast a live stream to several clients that joined at different moments without rewriting the granule position for each client.¶

If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing encoding of the current Ogg stream and starting a new Ogg stream, concatenated to the previous one. This is called chaining in Ogg. See the Ogg specification [RFC3533] for details.¶

10.2. Matroska Mapping

The Matroska container format is defined in [RFC9559]. The codec ID (EBML path \Segment\Tracks\TrackEntry\CodecID) assigned to signal tracks carrying FLAC data is A_FLAC in ASCII. All FLAC data before the first audio frame (i.e., the fLaC ASCII signature and all metadata blocks) is stored as CodecPrivate data (EBML path \Segment\Tracks\TrackEntry\CodecPrivate).¶

Each FLAC frame (including all of its subframes) is treated as a single frame in the context of Matroska.¶

If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing the current Matroska segment and starting a new one with the new properties.¶

10.3. ISO Base Media File Format (MP4) Mapping

The full encapsulation definition of FLAC audio in MP4 files was deemed too extensive to include in this document. A definition document can be found at [FLAC-in-MP4-specification].¶

12.1. Media Type Registration

IANA has registered the "audio/flac" media type as follows. This media type is applicable for FLAC audio that is not packaged in a container as described in Section 10. FLAC audio packaged in such a container will take on the media type of that container, for example, "audio/ogg" when packaged in an Ogg container or "video/mp4" when packaged in an MP4 container alongside a video track.¶

Type name:

audio¶

Subtype name:

flac¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

as per RFC 9639¶

Security considerations:

See the security considerations in Section 11 of RFC 9639.¶

Interoperability considerations:

See the descriptions of past format changes in Appendix B of RFC 9639.¶

Published specification:

RFC 9639¶

Applications that use this media type:

FFmpeg, Apache, Firefox¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names for this type:

audio/x-flac¶

Magic number(s):

fLaC¶

File extension(s):

flac¶

Macintosh file type code(s):

N/A¶

Uniform Type Identifier:

org.xiph.flac conforms to public.audio¶

Windows Clipboard Format Name:

audio/flac¶

Person & email address to contact for further information:

IETF CELLAR Working Group (cellar@ietf.org)¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

IETF CELLAR Working Group¶

Change controller:

Internet Engineering Task Force (iesg@ietf.org)¶

12.2. FLAC Application Metadata Block IDs Registry

IANA has created a new registry called the "FLAC Application Metadata Block IDs" registry. The values correspond to the 32-bit identifier described in Section 8.4.¶

To register a new application ID in this registry, one needs an application ID, a description, an optional reference to a document describing the application ID, and a Change Controller (IETF or email of registrant). The application IDs are allocated according to the "First Come First Served" policy [RFC8126] so that there is no impediment to registering any application IDs the FLAC community encounters, especially if they were used in audio files but were not registered when the audio files were encoded. An application ID can be any 32-bit value but is often composed of 4 ASCII characters that are human-readable.¶

The initial contents of "FLAC Application Metadata Block IDs" registry are shown in the table below. These initial values were taken from the registration page at xiph.org (see [ID-registration-page]), which is no longer being maintained as it has been replaced by this registry.¶

A.1. Determining the Necessary Data Type Size

To find the smallest data type size that is guaranteed not to overflow for a certain sequence of arithmetic operations, the combination of values producing the largest possible result should be considered.¶

For example, if two 16-bit signed integers are added, the largest possible result forms if both values are the largest number that can be represented with a 16-bit signed integer. To store the result, a signed integer data type with at least 17 bits is needed. Similarly, when adding 4 of these values, 18 bits are needed; when adding 8, 19 bits are needed, etc. In general, the number of bits necessary when adding numbers together is increased by the log base 2 of the number of values rounded up to the nearest integer. So, when adding 18 unknown values stored in 8-bit signed integers, we need a signed integer data type of at least 13 bits to store the result, as the log base 2 of 18 rounded up is 5.¶

When multiplying two numbers, the number of bits needed for the result is the size of the first number plus the size of the second number. For example, if a 16-bit signed integer is multiplied by another 16-bit signed integer, the result needs at least 32 bits to be stored without overflowing. To show this in practice, the largest signed value that can be stored in 4 bits is -8. (-8)*(-8) is 64, which needs at least 8 bits (signed) to store.¶

A.2. Stereo Decorrelation

When stereo decorrelation is used, the side channel will have one extra bit of bit depth; see Section 4.2.¶

This means that while 16-bit signed integers have sufficient range to store samples from a fully decoded FLAC frame with a bit depth of 16 bits, the decoding of a side subframe in such a file will need a data type with at least 17 bits to store decoded subframe samples before undoing stereo decorrelation.¶

Most FLAC decoders store decoded (subframe) samples as 32-bit values, which is sufficient for files with bit depths up to (and including) 31 bits.¶

A.3. Prediction

A prediction (which is used to calculate the residual on encoding or added to the residual to calculate the sample value on decoding) is formed by multiplying and summing preceding sample values. In order to eliminate the possibility of integer overflow, the combination of preceding sample values and predictor coefficients producing the largest possible value should be considered.¶

To determine the size of the data type needed to calculate either a residual sample (on encoding) or an audio sample value (on decoding) in a fixed predictor subframe, the maximum possible value for these is calculated as described in Appendix A.1 and in the following table. For example, if a frame codes for 16-bit audio and has some form of stereo decorrelation, the subframe coding for the side channel would need 16+1+3 bits if a third-order fixed predictor is used.¶

Where:¶

For subframes with a linear predictor, the calculation is a little more complicated. Each prediction is the sum of several multiplications. Each of these multiply a sample value with a predictor coefficient. The extra bits needed can be calculated by adding the predictor coefficient precision (in bits) to the bit depth of the audio samples. To account for the summing of these multiplications, the log base 2 of the predictor order rounded up is added.¶

For example, if the sample bit depth of the source is 24, the current subframe encodes a side channel (see Section 4.2), the predictor order is 12, and the predictor coefficient precision is 15 bits, the minimum required size of the used signed integer data type is at least (24 + 1) + 15 + ceil(log2(12)) = 44 bits. As another example, with a side-channel subframe bit depth of 16, a predictor order of 8, and a predictor coefficient precision of 12 bits, the minimum required size of the used signed integer data type is (16 + 1) + 12 + ceil(log2(8)) = 32 bits.¶

A.4. Residual

As stated in Section 9.2.7, an encoder must make sure residual samples are representable by a 32-bit integer, signed two's complement, excluding the most negative value. As in the previous section, it is possible to calculate when residual samples already implicitly fit and when an additional check is needed. This implicit fit is achieved when residuals would fit a theoretical 31-bit signed integer, as that satisfies both of the mentioned criteria. When this implicit fit is not achieved, all residual values must be calculated and checked individually.¶

For the residual of a fixed predictor, the maximum residual sample size was already calculated in the previous section. However, for a linear predictor, the prediction is shifted right by a certain amount. The number of bits needed for the residual is the number of bits calculated in the previous section, reduced by the prediction right shift, and increased by one bit to account for the subtraction of the prediction from the current sample on encoding.¶

Taking the last example of the previous section, where 32 bits were needed for the prediction, the required data type size for the residual samples in case of a right shift of 10 bits would be 32 - 10 + 1 = 23 bits, which means it is not necessary to perform the aforementioned check.¶

As another example, when encoding 32-bit PCM with fixed predictors, all predictor orders must be checked. While the zero-order fixed predictor is guaranteed to have residual samples that fit a 32-bit signed integer, it might produce a residual sample value that is the most negative representable value of that 32-bit signed integer.¶

Note that on decoding, while the residual sample values are limited to the aforementioned range, the predictions are not. This means that while the decoding of the residual samples can happen fully in 32-bit signed integers, decoders must be sure to execute the addition of each residual sample to its accompanying prediction with a signed integer data type that is wide enough, as with encoding.¶

A.5. Rice Coding

When folding (i.e., zigzag encoding) the residual sample values, no extra bits are needed when the absolute value of each residual sample is first stored in an unsigned data type of the size of the last step, then doubled, and then has one subtracted depending on whether the residual sample was positive or negative. However, many implementations choose to require one extra bit of data type size so zigzag encoding can happen in one step without a cast instead of the procedure described in the previous sentence.¶

B.1. Addition of Blocking Strategy Bit

Perhaps the largest backwards-incompatible change to the specification was published in July 2007. Before this change, variable block size streams were not explicitly marked as such by a flag bit in the frame header. A decoder had two ways to detect a variable block size stream: by comparing the minimum and maximum block sizes in the streaminfo metadata block (which are equal for a fixed block size stream) or by detecting a change of block size during a stream if a decoder did not receive a streaminfo metadata block, which could not happen at all in theory. As the meaning of the coded number in the frame header depends on whether or not a stream has a variable block size, this presented a problem: the meaning of the coded number could not be reliably determined. To fix this problem, one of the reserved bits was changed to be used as a blocking strategy bit. See also Section 9.1.¶

Along with the addition of a new flag, the meaning of the block size bits (see Section 9.1.1) was subtly changed. Initially, block size bits patterns 0b0001-0b0101 and 0b1000-0b1111 could only be used for fixed block size streams, while 0b0110 and 0b0111 could be used for both fixed block size and variable block size streams. With this change, these restrictions were lifted, and patterns 0b0001-0b1111 are now used for both variable block size and fixed block size streams.¶

B.2. Restriction of Encoded Residual Samples

Another change to the specification was deemed necessary during standardization by the CELLAR Working Group of the IETF. As specified in Section 9.2.7, a limit is imposed on residual samples. This limit was not specified prior to the IETF standardization effort. However, as far as was known to the working group, no FLAC encoder at that time produced FLAC files containing residual samples exceeding this limit. This is mostly because it is very unlikely to encounter residual samples exceeding this limit when encoding 24-bit PCM, and encoding of PCM with higher bit depths was not yet implemented in any known encoder. In fact, these FLAC encoders would produce corrupt files upon being triggered to produce such residual samples, and it is unlikely any non-experimental encoder would ever do so, even when presented with crafted material. Therefore, it was not expected that existing implementations would be rendered non-compliant by this change.¶

B.3. Addition of 5-Bit Rice Parameters

One significant addition to the format was the residual coding method using 5-bit Rice parameters. Prior to publication of this addition in July 2007, a partitioned Rice code with 4-bit Rice parameters was the only residual coding method specified. The range offered by this coding method proved too small when encoding 24-bit PCM; therefore, a second residual coding method was specified that was identical to the first, but with 5-bit Rice parameters.¶

B.4. Restriction of LPC Shift to Non-negative Values

As stated in Section 9.2.6, the predictor right shift is a number signed two's complement, which MUST NOT be negative. This is because shifting a number to the right by a negative amount is undefined behavior in the C programming language standard. The intended behavior was that a positive number would be a right shift and a negative number would be a left shift. The FLAC reference encoder was changed in 2007 to not generate LPC subframes with a negative predictor right shift, as it turned out that the use of such subframes would only very rarely provide any benefit and the decoders that were already widely in use at that point were not able to handle such subframes.¶

C.1. Features outside of the Streamable Subset

As described in Section 7, FLAC specifies a subset of its capabilities as the FLAC streamable subset. Certain decoders may choose to only decode FLAC files conforming to the limitations imposed by the streamable subset. Therefore, maximum compatibility with decoders is achieved when the limitations of the FLAC streamable subset are followed when creating FLAC files.¶

C.2. Variable Block Size

Because it is often difficult to find the optimal arrangement of block sizes for maximum compression, most encoders choose to create files with a fixed block size. Because of this, many decoder implementations receive minimal use when handling variable block size streams, and this can reveal bugs or reveal that implementations do not decode them at all. Furthermore, as explained in Appendix B.1, there have been some changes to the way variable block size streams are encoded. Because of this, maximum compatibility with decoders is achieved when FLAC files are created using fixed block size streams.¶

C.3. 5-Bit Rice Parameters

As the addition of the coding method using 5-bit Rice parameters, as described in Appendix B.3, occurred quite a few years after the FLAC format was first introduced, some early decoders might not be able to decode files containing such Rice parameters. The introduction of this was specifically aimed at improving compression of 24-bit PCM audio, and compression of 16-bit PCM audio only rarely benefits from using 5-bit Rice parameters. Therefore, maximum compatibility with decoders is achieved when FLAC files containing audio with a bit depth of 16 bits or less are created without any use of 5-bit Rice parameters.¶

C.4. Rice Escape Code

Escaped Rice partitions are seldom used, as it turned out their use provides only a very small compression improvement. As many encoders do not use these by default or are not capable of producing them at all, it is likely that many decoder implementations are not able to decode them correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created without any use of escaped Rice partitions.¶

C.5. Uncommon Block Size

For unknown reasons, some decoders have chosen to support only common block sizes for all but the last block of a stream. Therefore, maximum compatibility with decoders is achieved when creating FLAC files using common block sizes, as listed in Section 9.1.1, for all but the last block of a stream.¶

C.6. Uncommon Bit Depth

Most audio is stored in bit depths that are a whole number of bytes, e.g., 8, 16, or 24 bits. However, there is audio with different bit depths. A few examples:¶

The FLAC format can contain these bit depths directly, but because they are uncommon, some decoders are not able to process the resulting files correctly. It is possible to store these formats in a FLAC file with a more common bit depth without sacrificing compression by padding each sample with zero bits to a bit depth that is a whole byte. The FLAC format can efficiently compress these wasted bits. See Section 9.2.2 for details.¶

Therefore, maximum compatibility with decoders is achieved when FLAC files are created by padding samples of such audio with zero bits to the bit depth that is the next whole number of bytes.¶

In cases where the original signal is already padded, this operation cannot be reversed losslessly without knowing the original bit depth. To leave no ambiguity, the original bit depth needs to be stored, for example, in a Vorbis comment field or by storing the header of the original file. The choice of a suitable method is left to the implementor.¶

Besides audio with a "non-whole byte" bit depth, some decoder implementations have chosen to only accept FLAC files coding for PCM audio with a bit depth of 16 bits. Many implementations support bit depths up to 24 bits, but no higher. Consult [FLAC-wiki-interoperability] for more up-to-date information.¶

C.7. Multi-Channel Audio and Uncommon Sample Rates

Many FLAC audio players are unable to render multi-channel audio or audio with an uncommon sample rate. While this is not a concern specific to the FLAC format, it is of note when requiring maximum compatibility with decoders. Unlike the previously mentioned interoperability considerations, this is one where compatibility cannot be improved without sacrificing the lossless nature of the FLAC format.¶

From a non-exhaustive inquiry, it seems that a non-negligible number of players, especially hardware players, do not support audio with 3 or more channels or sample rates other than those considered common; see Section 9.1.2.¶

For those players that do support and are able to render multi-channel audio, many do not parse and use the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag (see Section 8.6.2). This is also an interoperability consideration because compatibility cannot be improved without sacrificing the lossless nature of the FLAC format.¶

C.8. Changing Audio Properties Mid-Stream

Each FLAC frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. However, many FLAC decoders do not handle such changes, as few other formats are capable of holding such streams and changing playback properties during playback is often not possible without interrupting playback. Also, as explained in Section 9, using this feature of FLAC results in various practical problems.¶

However, even when storing an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as recommended in Section 9, many decoders are not able to decode such a stream correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created with a single set of audio properties, in which the properties coded in the streaminfo metadata block (see Section 8.2) and the properties coded in all frame headers (see Section 9.1) are the same. This can be achieved by splitting up an input stream with changing audio properties at the points where these properties change into separate streams or files.¶

D.1. Decoding Example 1

This very short example FLAC file codes for PCM audio that has two channels, each containing one sample. The focus of this example is on the essential parts of a FLAC file.¶

00000000: 664c 6143 8000 0022 1000 1000  fLaC..."....
0000000c: 0000 0f00 000f 0ac4 42f0 0000  ........B...
00000018: 0001 3e84 b418 07dc 6903 0758  ..>.....i..X
00000024: 6a3d ad1a 2e0f fff8 6918 0000  j=......i...
00000030: bf03 58fd 0312 8baa 9a         ..X......

00000000: 01100110 01001100 01100001 01000011  fLaC
00000004: 10000000 00000000 00000000 00100010  ..."
00000008: 00010000 00000000 00010000 00000000  ....
0000000c: 00000000 00000000 00001111 00000000  ....
00000010: 00000000 00001111 00001010 11000100  ....
00000014: 01000010 11110000 00000000 00000000  B...
00000018: 00000000 00000001 00111110 10000100  ..>.
0000001c: 10110100 00011000 00000111 11011100  ....
00000020: 01101001 00000011 00000111 01011000  i..X
00000024: 01101010 00111101 10101101 00011010  j=..
00000028: 00101110 00001111 11111111 11111000  ....
0000002c: 01101001 00011000 00000000 00000000  i...
00000030: 10111111 00000011 01011000 11111101  ..X.
00000034: 00000011 00010010 10001011 10101010  ....
00000038: 10011010

D.2. Decoding Example 2

This FLAC file is larger than the first example, but still contains very little audio. The focus of this example is on decoding a subframe with a fixed predictor and a coded residual, but it also contains a very short seek table, a Vorbis comment metadata block, and a padding metadata block.¶

00000000: 664c 6143 0000 0022 0010 0010  fLaC..."....
0000000c: 0000 1700 0044 0ac4 42f0 0000  .....D..B...
00000018: 0013 d5b0 5649 75e9 8b8d 8b93  ....VIu.....
00000024: 0422 757b 8103 0300 0012 0000  ."u{........
00000030: 0000 0000 0000 0000 0000 0000  ............
0000003c: 0000 0010 0400 003a 2000 0000  .......: ...
00000048: 7265 6665 7265 6e63 6520 6c69  reference li
00000054: 6246 4c41 4320 312e 332e 3320  bFLAC 1.3.3
00000060: 3230 3139 3038 3034 0100 0000  20190804....
0000006c: 0e00 0000 5449 544c 453d d7a9  ....TITLE=..
00000078: d79c d795 d79d 8100 0006 0000  ............
00000084: 0000 0000 fff8 6998 000f 9912  ......i.....
00000090: 0867 0162 3d14 4299 8f5d f70d  .g.b=.B..]..
0000009c: 6fe0 0c17 caeb 2100 0ee7 a77a  o.....!....z
000000a8: 24a1 590c 1217 b603 097b 784f  $.Y......{xO
000000b4: aa9a 33d2 85e0 70ad 5b1b 4851  ..3...p.[.HQ
000000c0: b401 0d99 d2cd 1a68 f1e6 b810  .......h....
000000cc: fff8 6918 0102 a402 c382 c40b  ..i.........
000000d8: c14a 03ee 48dd 03b6 7c13 30    .J..H...|.0

00000088: 11111111 11111000 01101001 10011000  ..i.
0000008c: 00000000 00001111 10011001 00010010  ....
00000090: 00001000 01100111 00000001 01100010  .g.b
00000094: 00111101 00010100 01000010 10011001  =.B.
00000098: 10001111 01011101 11110111 00001101  .]..
0000009c: 01101111 11100000 00001100 00010111  o...
000000a0: 11001010 11101011 00100001 00000000  ..!.
000000a4: 00001110 11100111 10100111 01111010  ...z
000000a8: 00100100 10100001 01011001 00001100  $.Y.
000000ac: 00010010 00010111 10110110 00000011  ....
000000b0: 00001001 01111011 01111000 01001111  .{xO
000000b4: 10101010 10011010 00110011 11010010  ..3.
000000b8: 10000101 11100000 01110000 10101101  ..p.
000000bc: 01011011 00011011 01001000 01010001  [.HQ
000000c0: 10110100 00000001 00001101 10011001  ....
000000c4: 11010010 11001101 00011010 01101000  ...h
000000c8: 11110001 11100110 10111000 00010000  ....
000000cc: 11111111 11111000 01101001 00011000  ..i.
000000d0: 00000001 00000010 10100100 00000010  ....
000000d4: 11000011 10000010 11000100 00001011  ....
000000d8: 11000001 01001010 00000011 11101110  .J..
000000dc: 01001000 11011101 00000011 10110110  H...
000000e0: 01111100 00010011 00110000           |.0

TITLE=שלום

0x8428 B617 7946 3129 5E3A 2722 D445 D128 0B3D B723 EB45 DF28
0x723f 1E25 9D46 4929 B841 7026 5747 B829 8F43 8127 AEC7 14DF
0x9FC4 41DD 54C7 E4DE A5C4 40DD 1EC6 33DE 82C3 90DC 0BC4 02DD
0x4AC1 3EDB

D.3. Decoding Example 3

This example is once again a very short FLAC file. The focus of this example is on decoding a subframe with a linear predictor and a coded residual with more than one partition.¶

00000000: 664c 6143 8000 0022 1000 1000  fLaC..."....
0000000c: 0000 1f00 001f 07d0 0070 0000  .........p..
00000018: 0018 f8f9 e396 f5cb cfc6 dc80  ............
00000024: 7f99 7790 6b32 fff8 6802 0017  ..w.k2..h...
00000030: e944 004f 6f31 3d10 47d2 27cb  .D.Oo1=.G.'.
0000003c: 6d09 0831 452b dc28 2222 8057  m..1E+.("".W
00000048: a3                             .

0000002a: 11111111 11111000 01101000 00000010  ..h.
0000002e: 00000000 00010111 11101001 01000100  ...D
00000032: 00000000 01001111 01101111 00110001  .Oo1
00000036: 00111101 00010000 01000111 11010010  =.G.
0000003a: 00100111 11001011 01101101 00001001  '.m.
0000003e: 00001000 00110001 01000101 00101011  .1E+
00000042: 11011100 00101000 00100010 00100010  .(""
00000046: 10000000 01010111 10100011           .W.

0x004F 6F4E 08C3 A6BC F32A 4335 0DE5 D2DA F40E 1813 06FC FB00