<br><br><div class="gmail_quote">On Tue, Jun 22, 2010 at 8:00 AM, Adrian Knoth <span dir="ltr"><<a href="mailto:adi@drcomp.erfurt.thur.de">adi@drcomp.erfurt.thur.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Tue, Jun 22, 2010 at 06:38:45AM -0400, Gene Heskett wrote:<br>
<br>
> >from TFA:<br>
> >: Implemented in a DSP chip or microprocessor, this simple compressor<br>
> >: requires about 50 instructions per sample. However, lossless<br>
> >: compression ratios fall between 1.3:1 and 2:1 on baseband signals.<br>
> ><br>
> >So a size of 75% expected and on occasion down to 50% after compression.<br>
> >How is that compared to existing implementations?<br>
> It was the lossless claim that got my attention, Jens. I am well aware<br>
> that current compressors can beat that at "acceptable" quality. But an<br>
> ogg at q7<br>
<br>
</div>Jens was never talking about lossy "compression", which I call data<br>
reduction to avoid the ambiguity with real compression (as in ZIP).<br>
<br>
Lossless audio coding is nothing new, FLAC has been around for years.<br>
Your referenced codec achives 1.3:1 to 2:1. One can compare this to some<br>
values provided here:<br>
<div class="im"><br>
<br>
   <a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm" target="_blank">http://web.inter.nl.net/users/hvdh/lossless/lossless.htm</a><br>
<br>
<br>
</div>These are all lossless codecs, and as one can see, only few manage to<br>
come close to 2:1 (50% compression).<br>
<br>
However, results for predictive coding (derivation based approaches)<br>
vary a lot depending on the input signal. As a rule of thumb, a pure<br>
sine is easier to predict than noise, which more or less is the<br>
mathematical equivalent of randomness (I'm sure Fons could go into<br>
detail here, if necessary).<br>
<br>
<br>
Long story short: I don't think your link contains something<br>
extra-ordinary, just another me-too approach of well-known techniques.<br>
It might save you a few bits, but you'll have to measure it. Fire up<br>
octave, load the matlab script, encode a wave file and compare it to<br>
FLAC.<br>
<br>
If your referenced algorithm gives striking results, then convince<br>
everybody to forget about FLAC and use this new algo instead. Let me<br>
predict that neither the first nor the latter will happen. ;)<br>
<br>
<br>
That's more or less the end of the story. Any further discussion would<br>
only make sense with measured results at hand.<br>
<br>
<br>
HTH<br>
<font color="#888888"><br>
--<br>
mail: <a href="mailto:adi@thur.de">adi@thur.de</a>       <a href="http://adi.thur.de" target="_blank">http://adi.thur.de</a>      PGP/GPG: key via keyserver<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br><br>I've tested flac -8 and the given matlab script on a wav file.  The matlab script reports a compression ratio of 7.9908, and flac reports a compression ratio of 0.521, obviously, they measure in inverse ways, but 7.99 still seems excessively high.<br>

<br>Jeremy<br>