FAQ

General Tools API Project

General

What is FLAC?

FLAC stands for Free Lossless Audio Codec, an audio format similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works, except with FLAC you will get much better compression because it is designed specifically for audio, and you can play back compressed FLAC files in your favorite player (or your car or home stereo, see supported devices) just like you would an MP3 file.

For more details, see What is FLAC?

I have a FLAC file, how do I play it?
How can I create FLAC files?

See Using FLAC or a list of hardware that supports FLAC.

What licensing applies to the FLAC format and software?

See the license page.

What kinds of tags does FLAC support?

FLAC has it's own native tagging system which is identical to that of Vorbis. They are called alternately "FLAC tags" and "Vorbis comments". It is the only tagging system required and guaranteed to be supported by FLAC implementations.

Out of convenience, the reference decoder knows how to skip ID3 tags so that they don't interfere with decoding. But you should not expect any tags beside FLAC tags to be supported in applications; some implementations may not even be able to decode a FLAC file with ID3 tags.

What software support FLAC?

This list is so large now it is difficult to maintain and keep up-to-date. For a partial list of open-source software that supports FLAC, see the software section of the links page. For a partial list of the most popular software used to encode, decode, play, tag, and rip FLAC files, see the download page.

How can I play FLAC in Windows Media Player?

The easiest way is to use the Xiph.org Directshow Filters, download them here

What hardware products support FLAC?

See the hardware section of the links page.

What is the difference between (native) FLAC and Ogg FLAC?

You can think of an audio codec as having two layers. The inside layer is the raw compressed data, and the outside layer is the "container" or "transport layer" that splits and arranges the compressed data in pieces so it can be seeked through, edited, etc.

"Native" FLAC is the compressed FLAC data stored in a very minimalist container, designed to be very efficient at storing single audio streams.

Ogg FLAC is the compressed FLAC data stored in an Ogg container. Ogg is a much more powerful transport layer that enables mixing several kinds of different streams (audio, data, metadata, etc). The overhead is slightly higher than with native FLAC.

In either case, the compressed FLAC data is the same and one can be converted to the other without re-encoding.

Which should I use, (native) FLAC or Ogg FLAC?

The short answer right now is probably "native FLAC". If all you are doing is compressing audio to be played back later, native FLAC will do everything you need, is more widely supported, and will yield smaller files. If you plan to edit the compressed audio, or want to multiplex the audio with video later in an Ogg container, Ogg FLAC is a better choice.

Why aren't PERFORMER/TITLE/etc tags stored in the FLAC CUESHEET block?

This has turned out to be a pretty polarizing issue and requires a long explanation.

The original purpose of a cue sheet in CD authoring software was to lay out the disc, essentially specifying how the audio will be organized on the disc; some of the information ends up as the CD table of contents: the track numbers and locations, and the index points. Later CD-TEXT was added. But CD-TEXT is a very complex spec, and actually goes in the CD subcode data. It is internationalized, not through Unicode, but with several different character sets, some of them multi-byte. It even allows for graphics. In cue sheets, the TITLE/PERFORMER/etc tags are just a limited shorthand for authoring CD-TEXT, but when you rip, you almost never parse the CD-TEXT, you get it from another database, and it doesn't really belong in the FLAC CUESHEET block.

For FLAC the intention is that applications can calculate the CDDB or CDindex ID from the CUESHEET block and look it up in an online or local database just like CD rippers and players do. But if you really want it in the file itself, the track metadata should be stored separate from the CUESHEET, and already can be because of FLAC's metadata system. There just isn't a method specified yet because as soon as it is, people will say that it's not flexible enough. From experience (and you can see this come up time and time again in many lists), anyone who is going to the trouble of keeping a lossless collection in the first place will already be picky about metadata, and it is hard to come up with a standard that will please even the majority. That is the big problem with metadata and is why Xiph has deferred on it, waiting for someone to come up with a good metadata spec that can be multiplexed together with data.

Some players (for example Foobar2000) allow you to store the CDDB data as FLAC tags and can parse that.

Why doesn't FLAC store all WAVE metadata?
If flac compresses WAVE files, why isn't it technically a WAVE file compressor?

(By default, flac does not store WAVE metadata, but it can with the --keep-foreign-metadata option described below.)

FLAC is a general-purpose audio format, not just a compressed WAVE file format. There's a subtle difference. WAVE is a complicated standard; many kinds of data besides audio data can be put in it. FLAC's purpose is not to reproduce a WAVE file, including all the non-audio data that is in it, it is to losslessly compress the audio.

However, if you really need to store the non-audio parts of a WAVE or AIFF file, you can use the --keep-foreign-metadata option to flac when encoding to store it in FLAC metadata, then use the option again when decoding to restore in to the decoded WAVE/AIFF file.

Why do some lossless comparisons say FLAC does not support RIFF chunks?

This is a limitation that no longer exists with FLAC (see above).

Why do the encoder settings have a big effect on the encoding time but not the decoding time?

It's hard to explain without going into the codec design, but to oversimplify, the encoder is looking for functions that approximate the signal. Higher settings make the encoder search more to find better approximations. The functions are themselves encoded in the FLAC file. Decoding only requires computing the one chosen function, and the complexity of the function is very stable. This is by design, to make decoding easier, and is one of the things that makes FLAC easy to implement in hardware.

Why use FLAC instead of other codecs that compress more?

For most users, a small difference in filesize is usually far outweighed by FLAC's advantages: open patent free codec, portable open source (BSD) reference implementation, documented API, multi-platform support, hardware support, multi-channel support, etc. Improving FLAC to get a little more compression is not worth making it more complex and more compute-intensive to decode, and hence, less likely to be supported in hardware.

Why can't you make FLAC encode faster?

FLAC already encodes pretty fast. It is faster than real-time even on weak systems and is not much slower than even the fastest codecs. And it is faster than the CD ripping process with which it is usually paired, meaning even if it went faster, it would not speed up the ripping-encoding process anyway.

Part of the reason is that FLAC is asymmetric (see also). That means that it is optimized for decoding speed at the expense of encoding speed, because it makes it easier to decode on low-powered hardware, and because you only encode once but you decode many times.

How can I be sure FLAC is lossless?
How much testing has been done on FLAC?

First, FLAC is probably the only lossless compressor that has a published and comprehensive test suite. With the others you rely on the author's personal testing or the longevity of the program. But with FLAC you can download the whole test suite and run it on any version you like, or alter it to test your own data. The test suite checks every function in the API, as well as running many thousands of streams through an encode-decode-verify process, to test every nook and cranny of the system. Even on a fast machine the full test suite takes hours. The full test suite must pass on several platforms before a release is made.

Second, you can always use the -V option with flac (also supported by most GUI frontends) to verify while encoding. With this option, a decoder is run in parallel to the encoder and its output is compared against the original input. If a difference is found flac will stop with an error.

Finally, FLAC is used by many people and has been judged stable enough by many software and hardware makers to be incorporated into their products.

What is the lowest bitrate (or highest compression) achievable with FLAC?

With FLAC you do not specify a bitrate like with some lossy codecs. It's more like specifying a quality with Vorbis or MPC, except with FLAC the quality is always "lossless" and the resulting bitrate is roughly proportional to the amount of information in the original signal. You cannot control the bitrate much and the result can be from around 100% of the input rate (if you are encoding noise), down to almost 0 (encoding silence).

How many channels does FLAC support?

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.

What kind of audio samples does FLAC support?

FLAC supports linear PCM samples with a resolution between 4 and 32 bits per sample. FLAC does not support floating point samples. In some cases it is possible to losslessly transform samples from an incompatible range to a FLAC-compatible range before encoding.

FLAC supports linear sample rates from 1Hz - 655350Hz in 1Hz increments.

Will FLAC ever support floating-point samples?

It's unlikely FLAC will ever support floating-point samples natively. The main application for floating-point is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else.

FLAC is designed as a consumer audio format. It trades ease of editing for a featureful, robust transport layer more suited for playback, and encoding speed for more compression and faster decompression.

Tools

How do I set up EAC to rip directly to FLAC?

See hydrogenaud.io wiki page or Case's excellent EAC configuration page. Or use AutoFLAC to rip to FLAC or multiple formats at once.
How do I encode a file that starts with a dash?

When using flac to encode on the command-line, a file that starts with a dash will be treated as an option, but there is a simple workaround. Use -- to signal the end of options and the beginning of filenames, like so:

flac -V -- -01-name.wav

Why does it take so long to edit some FLAC files with metaflac?

Since metadata is stored at the beginning of a FLAC file, changing the length of it can sometimes cause the whole file to be rewritten. You can avoid this by adding padding with flac when you encode, or with metaflac after encoding. By default, flac adds 8k of padding; you can change this amount if you need more or less.

Why don't wildcards for file names like *.flac or *.wav work with flac/metaflac on Windows?

The Windows command shells (cmd.exe, command.com) implement wildcard handling differently than most other shells, leaving it up to the program to do everything including difficult and ambiguous cases. For an explanation of why wildcards on cmd.exe/command.com are dangerous, see here. Better command shells for Windows exist, e.g. from Cygwin. A workaround with the Windows shells is to do something like:

for %F in (*.wav) do flac "%F"

but care must still be taken that the command will execute as intended.

I compressed a file to FLAC with verify on, and flac said "Verify FAILED!" Why?

The only known cause of verify errors is faulty hardware. The dead giveaway is that if you repeat the exact same command, the error occurs in a different place or not at all. This can also happen when decoding or testing a FLAC file. If this is happening it is your hardware and not a FLAC bug.

The problem is usually caused by overclocking/overheating the CPU or bad RAM. Try one of the many free programs available for testing hardware (e.g. Memtest).

If you ever have a verify error that fails at the same place every time, please file a bug and provide a sample.

I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical. Why?
I compressed a WAVE file to FLAC and it said "warning: skipping unknown sub-chunk LIST". Why?

WAVE is a complicated standard; many kinds of data besides audio data can be put in it. Most likely what has happened is that the application that created the original WAVE file also added some extra information for it's own use, which FLAC does not store or recreate by default (but can with the --keep-foreign-metadata option) (see also). The audio data in the two WAVE files will be identical. There are other tools to compare just the audio content of two WAVE files; ExactAudioCopy has such a feature.

For the more technically inclined, by default FLAC only stores what is in the 'fmt ' and 'data' sub-chunks of a WAVE file. (see also)

I decoded a FLAC file and the WAVE is 2 bytes shorter than the original. Why?

The difference is probably that between an 18-byte 'fmt ' subchunk in the original WAVE vs. a 16-byte one in the decoded WAVE. With WAVE there is more than one way to write identical formatting information, but FLAC always writes the most common legal form. (see also)

Why did I get "ERROR initializing encoder, state = FLAC__STREAM_ENCODER_NOT_STREAMABLE"?

You specified encoding options that are outside the Streamable subset. If that is what you really wanted and you understand the consequences, you can use flac --lax to generate a non-Subset stream. The resulting file may not be streamable or play in all players.

Why doesn't the same file compressed on different machines with the same options yield the same FLAC file?

It's not supposed to, and neither does it mean either encoding was bad. There are many variations between different machines or even different builds of flac on the same machine that can lead to small differences in the FLAC file, even if they have the exact same final size. This is normal.

API

Why does your API change for point releases?

The FLAC release numbering scheme of MAJOR.MINOR.MICRO reflects the state of the FLAC format, not the API. This is most intuitive for users, at the expense of flustering developers. The shared library number (derived from the libtool current:revision:age number) is the indicator of binary API compatibility. As of FLAC 1.1.3, the current, revision, and age numbers are also #defined in the library headers to make porting easier; see the porting guide.

How can I determine the encoded frame length?

With native FLAC, it is not possible to determine the frame length without decoding. Probably if I had it all to do again I would have constrained the possible block sizes, which would have made it more practical to put the frame length in the frame header. For an example of how to find the frame boundaries in a stream, see the source code to metaflac, in the functionality that adds seek points.

With Ogg FLAC, it can be calculated from the Ogg page header.

Project

Where are the mailing lists, forums, discussion areas, etc.?

There are a few places. The main discussions happen on the official FLAC mailing lists (you must subscribe to post). Also, there is a lot of discussion relating to FLAC on Hydrogen Audio.

How do I submit a bug report?

First, visit the bug tracking page and do a little searching of both open and closed bugs to see if yours is already there. If you have something truly new submit a new bug there. Make sure to monitor the bug or include your email address in the description. Include as much information as possible: the version of FLAC that you are running, the name and version of any frontend you are running, your operating system and version, your CPU type and speed, the amount of memory you have, where you downloaded FLAC from, the exact error message (if any) copied from the console, and anything else you may think will help.