On Nov 12, 2009, at 16:32, Fernando Alberto Marengo Rodriguez wrote: > I' m studying FLAC performance, and I'd like to know how much > compression can be achieved for different audio files. > > 1) It seems that for nontonal sound (wideband noise), the > compression factor is better than for compound sound (tones + > nontonal components), which is typically 2. The reason for this > result could be the following: the LPC filter is more suitable for > estimating the amplitude spectrum of non tonal information, and do > not take into account the phase contribution for each spectral > component. Do you agree with me, or do you suggest other reasons > for this?
You should also find that lower amplitudes compress better than higher amplitudes. For example, if "live" material with normal dynamic range is compressed by FLAC, the ratio will be better than the same audio which has been compressed for mastering, which raises the levels of all the material in addition to reducing the range between quiet and loud. Your "wideband noise" may be gaussian or uniform distribution, and this could greatly affect the compression. I.e. do not assume that all noise is the same. There are probably other correlations besides just noise vs. tones and loud vs. quiet. It seems like you may want to do additional research. > 2) As far as I know, the compression ratio is defined as > > output file size / input file size, > > where the output file size includes frame header and other > information which do not represent the input samples. Don't forget that the input file size also includes frame header and other information which does not represent the input samples. This input file overhead can be negligible, but is not without some consequence. > My questions are: > > a) What percentage of the output sile size is exclusively > representing the input data? As this performance may depend on how > many tones are present in the input, I'd like to know some average > results if possible. I think you're phrasing the question wrong. The output size devoted to audio data content is variable, so it will not be accurately expressed as a percentage. Instead, there is a fixed amount of overhead for a given amount of timeline, which slightly varies according to the format chosen (16-bit, 24-bit, etc). The amount of space taken by the audio content is quite variable, and is not strictly specified other than algorithmically. I think you'll have to gather statistics rather than look for "specifications," since the percentage is a side-effect rather than a precise aspect of the design. > b) Is redundancy added to the compressed data in order to make FLAC > more robust? If this is the case, what's the percentage of these > data in the output file? I believe that you can answer this for yourself by carefully examining the details on the FLAC web pages. The entire format is described, down to the bit level. > 3) Where can I find more documentation about FLAC format and > design? Are there any more documents than those in the FLAC web > page? It' d be extremely useful not only for me, but also for many > people investigating about this interesting open-source format. I think what you are looking for is really a set of benchmarks that report on the effectiveness of the design in reaching its goal. There is no more documentation about the FLAC format and design than on the web site, because the web site includes everything related to format and design. The numerical factors that you are requesting are more about analysis than design, and they are fuzzy values rather than fixed aspects of format or design. Perhaps what you are really looking for is a White Paper which describes some of the research which went into FLAC, what sorts of sounds were analyzed when developing the algorithm, and what range of results were achieved by the resulting software. I do not recall seeing such published information, but perhaps the author, Josh Coalson, can elaborate. I'm sure that he had to test a wide variety of sounds, and there are certainly a number of test files in the open source suite. I just don't know how much public documentation there is at this high level of analysis. Brian Willoughby Sound Consulting _______________________________________________ Flac mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac
