<A HREF="#general__testing"><B>How much testing has been done on FLAC?</B></A>
</LI>
<LI>
- <A HREF="#general__lowest_bitrate"><B>What is the lowest bitrate achieveable with FLAC?</B></A>
+ <A HREF="#general__lowest_bitrate"><B>What is the lowest bitrate achievable with FLAC?</B></A>
</LI>
</UL>
</P>
<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 vary 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__lowest_bitrate"><B>What is the lowest bitrate achieveable with FLAC?</B></A>
+ <A NAME="general__lowest_bitrate"><B>What is the lowest bitrate achievable with FLAC?</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).
<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. 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="#tools__two_bytes_short">(see also)</A>
+ 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.
+ 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
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="#tools__wave_flac_wave">(see also)</A>
+ 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>
<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.
projects / platform / upstream / flac.git / commitdiff