This page describes the user-level view of the FLAC format (for a more detailed explanation see the <AHREF="format.html">format page</A>). It also contains the user documentation for <B><TT>flac</TT></B>, which is the command-line file encoder/decoder, <B><TT>metaflac</TT></B>, the FLAC metadata editor, and the <AHREF="#plugins">input plugins</A>.
Keep in mind that the online version of this document will always apply to the latest release. For older releases, check the documentation included with the release package.
See the <AHREF="format.html#scope">Scope</A>, <AHREF="format.html#architecture">Architecture</A>, <AHREF="format.html#definitions">Definitions</A>, and <AHREF="format.html#overview">Overview</A> sections of the <AHREF="format.html">format page</A> for a good introduction. This section will be expanded in the future.
<B><TT>flac</TT></B> is the command-line file encoder/decoder. The input to the encoder and the output to the decoder must either be RIFF WAVE format, or raw interleaved sample data. <B><TT>flac</TT></B> only supports linear PCM samples (in other words, no A-LAW, uLAW, etc.). Another restriction (hopefully short-term) is that the input must be 8, 16, or 24 bits per sample. This is not a limitation of the FLAC format, just the reference encoder/decoder.
<B><TT>flac</TT></B> assumes that RIFF WAVE files will have the extension ".wav"; this may be overridden with a command-line option. For piped-in data, <B><TT>flac</TT></B> tries to determine the type by looking at the beginning of the file. Other than this, <B><TT>flac</TT></B> makes no assumptions about file extensions, though the convention is that FLAC files have the extension ".flac" (or ".fla" on ancient file systems like FAT-16).
Before going into the full command-line description, a few other things help to sort it out: 1) <B><TT>flac</TT></B> encodes by default, so you must use <B>-d</B> to decode; 2) the options <B><TT>-0</TT></B> .. <B><TT>-9</TT></B> that control the compression level actually are just synonyms for different groups of specific encoding options (described later) and you can get the same effect by using the same options; 3) <B><TT>flac</TT></B> behaves similarly to gzip in the way it handles input and output files.
In any case, if no <TT>inputfile</TT> is specified, stdin is assumed. If only one inputfile is specified, it may be "-" for stdin. When stdin is used as input, <B><TT>flac</TT></B> will write to stdout. Otherwise <B><TT>flac</TT></B> will perform the desired operation on each input file to similarly named output files (meaning for encoding, the extension will be replaced with ".flac", or appended with ".flac" if the input file has no extension, and for decoding, the extension will be ".wav" for WAVE output and ".raw" for raw output). The original file is not deleted.
</P>
<P>
There are special forms for encoding/decoding from stdin to a file:
<UL>
<LI>
flac [options] - outputfile
</LI>
<LI>
flac -d [options] - outputfile
</LI>
</UL>
which are better than
<UL>
<LI>
flac [options] > outputfile
</LI>
<LI>
flac -d [options] > outputfile
</LI>
</UL>
since the former allows flac to seek backwards to write the STREAMINFO or RIFF WAVE header contents when necessary.
</P>
<P>
Also, you can force output data to go to stdout using <TT>-c</TT>.
</P>
<P>The encoding options affect the compression ratio and encoding speed. The format options are used to tell <B><TT>flac</TT></B> the arrangement of samples if the input file (or output file when decoding) is a raw file. If it is a RIFF WAVE file the format options are not needed since they are read from the WAVE header.
In test mode, <B><TT>flac</TT></B> acts just like in decode mode, except no output file is written. Both decode and test modes detect errors in the stream, but they also detect when the MD5 signature of the decoded audio does not match the stored MD5 signature, even when the bitstream is valid.
Decode (<B><TT>flac</TT></B> encodes by default). <B><TT>flac</TT></B> will exit with an exit code of <TT>1</TT> (and print a message, even in silent mode) if there were any errors during decoding, including when the MD5 checksum does not match the decoded output. Otherwise the exit code will be <TT>0</TT>.
Analyze (same as <B><TT>-d</TT></B> except an analysis file is written). The exit codes are the same as in decode mode. This option is mainly for developers; the output will be a text file that has data about each frame and subframe.
Allow encoder to generate non-Subset files. The resulting FLAC file may not be streamable, so you should only use this option in combination with custom encoding options meant for archival. File decoders will still be able play (and seek in) such files.
<TT># </TT> : a specific sample number for a seek point
</LI>
<LI>
<TT>X </TT> : a placeholder point (always goes at the end of the SEEKTABLE)
</LI>
<LI>
<TT>#x</TT> : # evenly spaced seekpoints, the first being at sample 0
</LI>
</UL>
You may use many -S options; the resulting SEEKTABLE will be the unique-ified union of all such values.<BR>
With no -S options, flac defaults to '-S 100x'. Use -S- for no SEEKTABLE.<BR>
NOTE: -S #x will not work if the encoder can't determine the input size before starting.<BR>
NOTE: if you use -S # and # is >= samples in the input, there will be either no seek point entered (if the input size is determinable before encoding starts) or a placeholder point (if input size is not determinable)<BR>
Tell the encoder to write a <TT>PADDING</TT> metadata block of the given length (in bytes) after the <TT>STREAMINFO</TT> block. <TT>-P 0</TT> implies no <TT>PADDING</TT> block, which is the default. This is useful if you plan to tag the file later with an <TT>APPLICATION</TT> block; instead of having to rewrite the entire file later just to insert your block, you can write directly over the <TT>PADDING</TT> block.
Specify the blocksize in samples. The default is 1152 for -l 0, otherwise 4608. Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096/8192/16384/32768. The current encoder uses the same blocksize for the entire stream.
Enable mid-side coding (only for stereo streams). Tends to increase compression by a few percent on average. For each block both the stereo pair and mid-side versions of the block will be encoded, and smallest resulting frame will be stored. Currently mid-side encoding is only available when bits-per-sample <= 16.
Enable loose mid-side coding (only for stereo streams). Like <TT>-m</TT> but the encoder adaptively switches between independent and mid-side coding, which is faster but yields less compression than <TT>-m</TT> (which does an exhaustive search).
Synonymous with -l 32 -b 4608 -m -e -r 16 -R 32 -p. This is painfully slow but gives you the maximum compression <B><TT>flac</TT></B> can do for the given blocksize.
Exhaustive model search (expensive!). Normally the encoder estimates the best model to use and encodes once based on the estimate. With an exhaustive model search, the encoder will generate subframes for every order and use the smallest. If the max LPC order is high this can significantly increase the encode time but can shave off another 0.5%.
Specifies the maximum LPC order. This number must be <= 32. If 0, the encoder will not attempt generic linear prediction, and use only fixed predictors. Using fixed predictors is faster but usually results in files being 5-10% larger.
Specifies the precision of the quantized LP coefficients, in bits. The default is <B><TT>-q 0</TT></B>, which means let the encoder decide based on the signal. Unless you really know your input file it's best to leave this up to the encoder.
Do exhaustive LP coefficient quantization optimization. This option overrides any <B><TT>-q</TT></B> option. It is expensive and typically will only improve the compression a tiny fraction of a percent. <B><TT>-q</TT></B> has no effect when <B><TT>-l 0</TT></B> is used.
Set the [min,]max residual partition order. The min value defaults to 0 if unspecified.<BR>
By default the encoder uses a single Rice parameter for the subframe's entire residual. With this option, the residual is iteratively partitioned into 2^min# .. 2^max# pieces, each with its own Rice parameter. Higher values of max# yield diminishing returns. The most bang for the buck is usually with <B><TT>-r 2,2</TT></B> (more for higher blocksizes). This usually shaves off about 1.5%. The technique tends to peak out about when blocksize/(2^n)=128. Use <B><TT>-r 0,16</TT></B> to force the highest degree of optimization.
Set the Rice parameter search distance. Defaults to 0. The residual coder will search for the best Rice parameter +/- this number for each residual partition. This option is expensive (run time for -R n will be almost 2n+1 times that of -R 0) and doesn't give much of a gain.
Verify the encoding process. With this option, <B><TT>flac</TT></B> will create a parallel decoder that decodes the output of the encoder and compares the result against the original. It will abort immediately with an error if a mismatch occurs. <B><TT>-V</TT></B> increases the total encoding time but is guaranteed to catch any unforseen bug in the encoding process.
<B><TT>metaflac</TT></B> is the command-line <TT>.flac</TT> file metadata editor. Right now it just lists the contents of all metadata blocks in a .flac file, but soon it will allow you to insert, delete, and edit blocks.
</P>
<P>
Currently <B><TT>metaflac</TT></B> can be invoked only one way:
<UL>
<LI>
Listing: metaflac [-v] inputfile
</LI>
</UL>
</P>
<P>
<TT>inputfile</TT> may be "-" for stdin. If <TT>-v</TT> is used, you will get verbose output.
All that is necessary is to copy <B><TT>libxmms-flac.so</TT></B> to the directory where XMMS looks for input plugins (usually <B><TT>/usr/lib/xmms/Input</TT></B>). There is nothing else to configure. Make sure to restart XMMS before trying to play any <TT>.flac</TT> files.
All that is necessary is to copy <B><TT>in_flac.dll</TT></B> to the <B><TT>Plugins/</TT></B> directory of your Winamp installation. There is nothing else to configure. Make sure to restart Winamp before trying to play any <TT>.flac</TT> files.
Bug tracking is done on the Sourceforge project page <AHREF="http://sourceforge.net/bugs/?group_id=13478">here</A>. If you submit a bug, please provide an email contact and/or use the Monitor feature.
