[LAD] Better lossless compressions?

[Jeremy]

On Tue, Jun 22, 2010 at 8:00 AM, Adrian Knoth <adi at drcomp.erfurt.thur.de>wrote:

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


What about the algorithm being unencumbered?  Isn't that potentially a
problem?

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100622/c1bba25a/attachment.html>