remove commented-out stuff
[flac.git] / doc / html / faq.html
index 5b4d933..daa48ca 100644 (file)
                        <A HREF="#general__testing"><B>How much testing has been done on FLAC?</B></A>
                </LI>
                <LI>
-                       <A HREF="#general__wave_flac_wave"><B>I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical.  Why?</B></A>
+                       <A HREF="#general__lowest_bitrate"><B>What is the lowest bitrate achievable with FLAC?</B></A>
                </LI>
                <LI>
-                       <A HREF="#general__skipped_subchunk"><B>I compressed a WAVE file to FLAC and it said "warning: skipping unknown sub-chunk LIST".  Why?</B></A>
-               </LI>
-               <LI>
-                       <A HREF="#general__two_bytes_short"><B>I decoded a FLAC file and the WAVE is 2 bytes shorter than the original.  Why?</B></A>
-               </LI>
-               <LI>
-                       <A HREF="#general__lowest_bitrate"><B>What is the lowest bitrate achieveable with FLAC?</B></A>
+                       <A HREF="#general__submit_bug"><B>How do I submit a bug report?</B></A>
                </LI>
        </UL>
        </P>
        <BR>
        <UL>
                <LI>
+                       <A HREF="#tools__eac_and_flac"><B>How do I set up EAC to rip directly to FLAC?</B></A>
+               </LI>
+               <LI>
                        <A HREF="#tools__option_blocking"><B>How do I encode a file that starts with a dash?</B></A>
                </LI>
                <LI>
                        <A HREF="#tools__long_meta_edits"><B>Why does it take so long to edit some FLAC files with metaflac?</B></A>
                </LI>
                <LI>
+                       <A HREF="#tools__hardware_prob"><B>I compressed a file to FLAC with verify on, and flac said "Verify FAILED!"  Why?</B></A>
+               </LI>
+               <LI>
+                       <A HREF="#tools__wave_flac_wave"><B>I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical.  Why?</B></A>
+               </LI>
+               <LI>
+                       <A HREF="#tools__skipped_subchunk"><B>I compressed a WAVE file to FLAC and it said "warning: skipping unknown sub-chunk LIST".  Why?</B></A>
+               </LI>
+               <LI>
+                       <A HREF="#tools__two_bytes_short"><B>I decoded a FLAC file and the WAVE is 2 bytes shorter than the original.  Why?</B></A>
+               </LI>
+               <LI>
                        <A HREF="#tools__not_streamable"><B>Why did I get "ERROR initializing encoder, state = 14:FLAC__STREAM_ENCODER_NOT_STREAMABLE"?</B></A>
                </LI>
        </UL>
                <A NAME="general__native_vs_ogg"><B>What is the difference between (native) FLAC and Ogg FLAC?</B></A>
        </P>
        <P>
-               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 breaks the compressed data into pieces so it can be seeked through, edited, etc.
+               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.
        </P>
        <P>
                "Native" FLAC is the compressed FLAC data stored in a very minimalist container, designed to be very efficient at storing single audio streams.
                This has turned out to be a pretty polarizing issue and requires a long explanation.
        </P>
        <P>
-               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, 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.
+               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.
        </P>
        <P>
-               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 players do.  But if you really want it in the file itself, the track metadata really should be stored separate from the CUESHEET, and already can be because of FLAC's metadata system.  There just isn't one 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 me multiplexed together with data.
+               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 me multiplexed together with data.
        </P>
        <P>
                Some players (for example Foobar2000) allow you to store the CDDB data as FLAC tags and can parse that.
                <A NAME="general__asymmetry"><B>Why do the encoder settings have a big effect on the encoding time but not the decoding time?</B></A>
        </P>
        <P>
-               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 function, and the complexity of the function is vary stable.  This is by design, to make decoding easier, and is one of the things that makes FLAC easy to implement in hardware.
+               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.
        </P>
        <P>
                <A NAME="general__alternatives"><B>Why use FLAC instead of other codecs that compress more?</B></A>
                <A NAME="general__encode_faster"><B>Why can't you make FLAC encode faster?</B></A>
        </P>
        <P>
-               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 usually 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.
+               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.
        </P>
        <P>
                Part of the reason is that FLAC is asymmetric <A HREF="#general__asymmetry">(see also)</A>.  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.  
                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.
        </P>
        <P>
-               <A NAME="general__wave_flac_wave"><B>I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical.  Why?</B></A>
-               <BR>
-               <A NAME="general__skipped_subchunk"><B>I compressed a WAVE file to FLAC and it said "warning: skipping unknown sub-chunk LIST".  Why?</B></A>
-       </P>
-       <P>
-               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.  But 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; <A HREF="http://www.exactaudiocopy.de/">ExactAudioCopy</A> has such a feature.  <A HREF="#general__two_bytes_short">(see also)</A>
-       </P>
-       <P>
-               For the more technically inclined, FLAC only stores what is in the 'fmt ' and 'data' sub-chunks.
-       </P>
-       <P>
-               <A NAME="general__two_bytes_short"><B>I decoded a FLAC file and the WAVE is 2 bytes shorter than the original.  Why?</B></A>
+               <A NAME="general__lowest_bitrate"><B>What is the lowest bitrate achievable with FLAC?</B></A>
        </P>
        <P>
-               The difference is probably 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 right identical formatting information, but FLAC always writes the most common form.  <A HREF="#general__wave_flac_wave">(see also)</A>
+               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 and the result can be from around 100% of the input rate (if you are encoding noise), down to almost 0 (encoding silence).
        </P>
        <P>
-               <A NAME="general__lowest_bitrate"><B>What is the lowest bitrate achieveable with FLAC?</B></A>
+               <A NAME="general__submit_bug"><B>How do I submit a bug report?</B></A>
        </P>
        <P>
-               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 and the result can be from around 100% of the input rate (if you are encoding noise), down to almost 0 (encoding silence).
+               First, <A HREF="http://sourceforge.net/tracker/?group_id=13478&atid=113478">visit the bug submission page</A> and do a little searching of both open and closed bugs to see if yours is already there.  If you have something truly new, <A HREF="http://sourceforge.net/bugs/?func=addbug&group_id=13478">submit a new bug</A>.  <B>Make sure</B> to monitor the bug or include your email address in the description.
        </P>
 
        <H2>
                <B>Tools</B>
        </H2>
        <P>
+               <A NAME="tools__eac_and_flac"><B>How do I set up EAC to rip directly to FLAC?</B></A>
+       </P>
+       <P>
+               See Case's excellent <A HREF="http://www.saunalahti.fi/cse/EAC/index.html">EAC configuration page</A>.  Or use <A HREF="http://mareo.netfirms.com/">MAREO</A> to rip to multiple formats at once.
+       </P>
+       <P>
                <A NAME="tools__option_blocking"><B>How do I encode a file that starts with a dash?</B></A>
        </P>
        <P>
                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 <TT>flac</TT> when you encode, or with <TT>metaflac</TT> after encoding.  By default, <TT>flac</TT> adds 4k of padding; you can change this amount if you need more or less.
        </P>
        <P>
+               <A NAME="tools__hardware_prob"><B>I compressed a file to FLAC with verify on, and flac said "Verify FAILED!"  Why?</B></A>
+       </P>
+       <P>
+               Every single report of this has turned out to be caused by a hardware problem, usually aggressive over-clocking or bad RAM.  The best indicator of this is that the verify failure does not always happen in the same place for the same file.  First, read the comments in <A HREF="http://sourceforge.net/tracker/index.php?func=detail&aid=595858&group_id=13478&atid=113478">this bug report</A>.  Then, if you have a file that fails verification in the same place every time, <A HREF="#general__submit_bug">submit a new bug</A>, uploading a sample according to <A HREF="http://sourceforge.net/tracker/index.php?func=detail&aid=585158&group_id=13478&atid=113478">the instructions found at the bottom of this bug report</A>.
+       </P>
+       <P>
+               <A NAME="tools__wave_flac_wave"><B>I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical.  Why?</B></A>
+               <BR>
+               <A NAME="tools__skipped_subchunk"><B>I compressed a WAVE file to FLAC and it said "warning: skipping unknown sub-chunk LIST".  Why?</B></A>
+       </P>
+       <P>
+               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  <A HREF="#tools__two_bytes_short">(see also)</A>.  But 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; <A HREF="http://www.exactaudiocopy.de/">ExactAudioCopy</A> has such a feature.
+       </P>
+       <P>
+               For the more technically inclined, FLAC only stores what is in the 'fmt ' and 'data' sub-chunks of a WAVE file.
+       </P>
+       <P>
+               <A NAME="tools__two_bytes_short"><B>I decoded a FLAC file and the WAVE is 2 bytes shorter than the original.  Why?</B></A>
+       </P>
+       <P>
+               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 form.  <A HREF="#tools__wave_flac_wave">(see also)</A>
+       </P>
+       <P>
                <A NAME="tools__not_streamable"><B>Why did I get "ERROR initializing encoder, state = 14:FLAC__STREAM_ENCODER_NOT_STREAMABLE"?</B></A>
        </P>
        <P>
                <A NAME="api__frame_length"><B>How can I determine the encoded frame length?</B></A>
        </P>
        <P>
-               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.
+               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 <TT>metaflac</TT>, in the functionality that adds seek points.
        </P>
        <P>
                With Ogg FLAC, it can be calculated from the Ogg page header.