http://sjeng.org/ftp/vorbis/Garf_Bl33p!.flacAny idea why the performance of most lossless codecs is so horrible on this very simple signal?I would expect prediction to be almost perfect for it.But:FLAC bitrate:580kbpsAPE bitrate:750kbpsWavPack: also >500kbpsZIP bitrate: 21kbps7z/RAR bitrate: 2.5kbps
Those last few percent of compression that the best lossless compressors get is at the cost of an enormous amount of complexity in the prediction algorithms. They look at dozens of previous samples and have dozens of adjusting coefficients. So, a single transition will generate a whole train of non-zero residual values to encode. Another version that simply used the previous sample as the prediction would encode this much better, but would virtually never work better on any sample of real music (in fact, WavPack's "fast" mode compresses this sample to about half the size of the "high" mode for this reason).Also, no lossless compressor is going to take advantage of exactly repeating sequences of numbers like a general data compressor, because these never occur in audio data and require completely different coding algorithms (i.e. dictionary based, no Rice coding).An "ideal" compressor could be made to try several different simple and complex algorithms to detect cases like this, but most people would not be willing to put up with the encoding time penalty unless it improved performance on any "real" samples.BTW, your sample scared my cat!
Just looking at the FLAC output with a hex editor shows that it's extremely redundant.
Garf, I haven't looked at the WAV yet, but that FLAC file is very very strange ! It looks like a killer sample for RAR !Original (FLAC) = 4'394'931 bytesRAR (Best) => 80'162 bytesRAR (Good) => 81'523 bytesRAR (Normal) => 27'680 bytes RAR (Fast) => 55'240 bytesRAR (Fastest) => 105'302 bytesJust looking at the FLAC output with a hex editor shows that it's extremely redundant.
If we're into RAR killer samples, I remember seeing some files (it was some Unreal Tournament mod IIRC) where RAR miserably lost it to ZIP, even to its own ZIP compressor. I can dig them up if anyone interested.
QuoteJust looking at the FLAC output with a hex editor shows that it's extremely redundant.This problem can't be avoided adding a function, in lossless codecs, that checks if the output file is redundant as numlock noted and changes the compression mode used?
Sorry, Garf, but why you have uploaded FLAC instead of ZIP than?
RAR 3.x can shrink the wav further to ~4756 bytes, when forcing markov ("text") compression at maximum order (99).Edit:LOL eltoder, what did you do to RAR, to gain that extra byte ? About bzip2, cool but that's still far away from my 76 bytes.
The maximal order is in fact 63, not 99. And the best results are obtained at order 60 And could you share you great program with us? -Eugene
it's awfully slow, and optimized for data, not audio (except for Garf ® © audio of course). Also the name of input and output files is hardcoded in the source..