22 Jun
2010
22 Jun
'10
4:55 a.m.
And is there a snowballs chance in hell that this is un-encumbered?
<http://electronicdesign.com/tabid/57/default.aspx?topic=algorithm_delivers_lossless_compression_to_adc_samples&catpath=&fltrTitle=&fltrSummary=&fltrPublication.aspx?nl=1>
Yeah, I sub to a lot of stuff, and occasionally a gem comes by.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Old programmers never die, they just hit account block limit.
22 Jun
22 Jun
8:37 a.m.
On Mon, 2010-06-21 at 22:55 -0400, Gene Heskett wrote:
And is there a snowballs chance in hell that this is
un-encumbered?
<http://electronicdesign.com/tabid/57/default.aspx?topic=algorithm_delivers_lossless_compression_to_adc_samples&catpath=&fltrTitle=&fltrSummary=&fltrPublication.aspx?nl=1>
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?
--
jedes mal wenn du eine quintparallele verwendest
tötet bach ein kätzchen.
http://www.youtube.com/watch?v=43RdmmNaGfQ
11:01 a.m.
Excerpts from Jens M Andreasen's message of 2010-06-22 08:36:53 +0200:
On Mon, 2010-06-21 at 22:55 -0400, Gene Heskett wrote:
Typical lossless codecs manage to get typical music down to about at
most 50-60%, here's a graph and stuff:
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
And is there a snowballs chance in hell that this
is un-encumbered?
<http://electronicdesign.com/tabid/57/default.aspx?topic=algorithm_delivers_lossless_compression_to_adc_samples&catpath=&fltrTitle=&fltrSummary=&fltrPublication.aspx?nl=1>
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?
--
jedes mal wenn du eine quintparallele verwendest
tötet bach ein kätzchen.
http://www.youtube.com/watch?v=43RdmmNaGfQ
12:38 p.m.
On Tuesday 22 June 2010, Jens M Andreasen wrote:
On Mon, 2010-06-21 at 22:55 -0400, Gene Heskett wrote:
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
turned into an 192k mp3, or vice-versa, results in a blurred cacophony of
noise because each compressor throws away different stuff. The result is
still like fingernails on a backboard even to these 75 year old ears.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Nothing will ever be attempted if all possible objections must be first
overcome.
-- Dr. Johnson
And is there a snowballs chance in hell that this
is un-encumbered?
<http://electronicdesign.com/tabid/57/default.aspx?topic=algorithm_deliv
ers_lossless_compression_to_adc_samples&catpath=&fltrTitle=&fltrSummary=&
fltrPublication.aspx?nl=1>
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?
2 p.m.
On Tue, Jun 22, 2010 at 06:38:45AM -0400, Gene Heskett wrote:
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(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
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
3:09 p.m.
On Tue, 2010-06-22 at 14:00 +0200, Adrian Knoth wrote:
That's more or less the end of the story. Any
further discussion would
only make sense with measured results at hand.
There is this 50 instructions/sample thingie also. Size is comparable to
other lossless algos, but how about computational cost?
--
jedes mal wenn du eine quintparallele verwendest
tötet bach ein kätzchen.
http://www.youtube.com/watch?v=43RdmmNaGfQ
3:13 p.m.
On Tuesday 22 June 2010, Adrian Knoth wrote:
On Tue, Jun 22, 2010 at 06:38:45AM -0400, Gene Heskett
wrote:
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
I certainly won't argue with that assessment. In truth, I had forgotten
about flac too, possibly another sign of CRS that goes with age.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
All components become obsolete.
-- Murphy's Computer Laws n�8
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 
10 p.m.
On Tue, Jun 22, 2010 at 8:00 AM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de>wrote;wrote:
On Tue, Jun 22, 2010 at 06:38:45AM -0400, Gene Heskett
wrote:
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(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
What about the algorithm being unencumbered? Isn't that potentially a
problem?
Jeremy
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
10:09 p.m.
On Tue, Jun 22, 2010 at 8:00 AM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de>wrote;wrote:
On Tue, Jun 22, 2010 at 06:38:45AM -0400, Gene Heskett
wrote:
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(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
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.
Jeremy
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 
10:31 p.m.
On Tue, Jun 22, 2010 at 04:09:27PM -0400, Jeremy wrote:
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.
Does it decompress to the original ?
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
11:18 p.m.
On Tue, Jun 22, 2010 at 5:31 PM, <fons(a)kokkinizita.net> wrote:
Does it decompress to the original ?
The algorithm, patented by the way, is oriented to lossless
compression of HIGH SPEED signals, "New data compression technologies
can save power and cost in applications with sampling rates above 10
Msamples/sec." A lot above usual digital frequencies.
See:
http://www.dspdesignline.com/208808676;jsessionid=CEV13G2LQ4VWDQE1GHPSKHWAT…
Data compression for high-speed DSP, part 1
and
http://www.embedded.com/columns/technicalinsights/209400089?_requestid=1983…
Data compression for high-speed DSP, part 2
In Part 2 it is compared with LZ algorithms, of PKZIP fame. Somewhat
better, around 50% better, probably at the same level of the
algorithms already used for sound.
It advantage, is efficient implementation, in power, instructions and
pin count of DPS/FPGA chips, used for real time compression of those
high-speed images.
Also see, if interested:
http://www.dsp-fpga.com/articles/id/?4458
Compressing ADCs defuses data rate explosion in Data Acquisition Systems
There is some use for lossy compression, like ogg and mp3, but it not
well explained in the article
Final words of Part 2:
"By integrating compression into high-speed signal processing systems,
end-to-end system performance is maintained with reduced pin count,
memory, power, and cost. Just as speech, audio, image, and video
compression are now ubiquitous and integrated components of consumer
media, we believe that compression for high-speed DSP systems will
someday become as ubiquitous as these low-speed compression algorithms
have become."
--
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br
11:32 p.m.
On Tue, Jun 22, 2010 at 06:18:17PM -0300, A. C. Censi wrote:
On Tue, Jun 22, 2010 at 5:31 PM,
<fons(a)kokkinizita.net> wrote:
So I'll repeat the question: Does it decompress to the original ?
( _it_ meaning the file that was reported to be compressed better
than 7:1)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Does it decompress to the original ?
... lots of text but no answer ...
11:47 p.m.
On Tue, Jun 22, 2010 at 5:32 PM, <fons(a)kokkinizita.net> wrote:
On Tue, Jun 22, 2010 at 06:18:17PM -0300, A. C. Censi
wrote:
No algorithm is provided to decompress, but I realize that I have made a
mistake, because I read in the audio as floating point, but the algorithm
uses integer based audio coding. So basically it thinks everything is 0,1,
or -1. I am using GNU Octave, and I have tried some different functions for
converting the audio to integers, but none of the functions provided by
octave seem to work. I'll try and do it properly some time.
Jeremy
On Tue, Jun 22, 2010 at 5:31 PM,
<fons(a)kokkinizita.net> wrote:
So I'll repeat the question: Does it decompress to the original ?
( _it_ meaning the file that was reported to be compressed better
than 7:1)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Does it decompress to the original ?
... lots of text but no answer ...
11:52 p.m.
On Tue, Jun 22, 2010 at 05:47:04PM -0400, Jeremy wrote:
No algorithm is provided to decompress
OK. If I don't have to demonstrate that the result can
be decompressed to the original input I can write a
'lossless' compression algo in 5 minutes or less.
Under these conditions it's not even vapourware,
it's plain snake oil.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
23 Jun
23 Jun
12:14 a.m.
On Tue, Jun 22, 2010 at 6:52 PM, <fons(a)kokkinizita.net> wrote:
On Tue, Jun 22, 2010 at 05:47:04PM -0400, Jeremy
wrote:
> No algorithm is provided to decompress
By searching I found that in MATLAB repositories in
http://www.mathworks.fr/matlabcentral/fileexchange/9853-samplify-sampled-da…
Samplify Sampled Data Compression
there is evaluation code of samplify algorithms, with compress and
decompress code. There is a manual with some theory about it.
The code there can handle several data formats, integer and float.
--
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br
22 Jun
22 Jun
11:48 p.m.
There is no decompress code in the article ...
Someone has to wright one to check.
The author and his company claim that it can operate in lossless mode
and it is already in use in some medical systems, so probably yes. But
the improvement, if any, when compared with established algorithms
used for sound, seems not sensible. I would not bet time in writing
the decompression code.
ACC
PS - Matlab compression code is attached. So anyone can try to decompress!
On Tue, Jun 22, 2010 at 6:32 PM, <fons(a)kokkinizita.net> wrote:
On Tue, Jun 22, 2010 at 06:18:17PM -0300, A. C. Censi
wrote:
--
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br
On Tue, Jun 22, 2010 at 5:31 PM,
<fons(a)kokkinizita.net> wrote:
So I'll repeat the question: Does it decompress to the original ?
( _it_ meaning the file that was reported to be compressed better
than 7:1)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Does it decompress to the original ?
... lots of text but no answer ...
23 Jun
23 Jun
12:13 a.m.
On Tue, Jun 22, 2010 at 06:48:02PM -0300, A. C. Censi wrote:
There is no decompress code in the article ...
Someone has to wright one to check.
???
The author and his company claim that it can operate
in lossless mode
and it is already in use in some medical systems, so probably yes.
'Medical' means 2-D or 3-D images, or ECG or EEG data.
Compression algos that work well on image data have little
chance to perform as well on audio signals - the 'features'
are quite different. Same for ECG or EEG data which are
quite specific (with some very sophisticated algos having
been developed to analyse them). None of this is likely
to have any relevance to audio.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
12:53 a.m.
On Tuesday, June 22, 2010, <fons(a)kokkinizita.net> wrote:
On Tue, Jun 22, 2010 at 06:48:02PM -0300, A. C. Censi
wrote:
s/wright/write
There is no decompress code in the article ...
Someone has to wright one to check.
???
'Medical' means 2-D or 3-D images, or ECG or
EEG data.
). None of this is likely
to have any relevance to audio.
The key point, by a quick read is speed and easy of
implementation in
special chip architectures, lime DSP and FPGA.
The company is not focusing on soind applications,só it should no be
of use. One of the patents is from 2006, and only now, it is being
promoted.
If you want to look in the manual in the MATLAB zip file linked, I
think that you could grado the shortcomings.
Regards
--
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br
2:10 a.m.
On Tue, Jun 22, 2010 at 5:48 PM, A. C. Censi <accensi(a)gmail.com> wrote:
There is no decompress code in the article ...
Someone has to wright one to check.
The author and his company claim that it can operate in lossless mode
and it is already in use in some medical systems, so probably yes. But
the improvement, if any, when compared with established algorithms
used for sound, seems not sensible. I would not bet time in writing
the decompression code.
ACC
PS - Matlab compression code is attached. So anyone can try to decompress!
On Tue, Jun 22, 2010 at 6:32 PM, <fons(a)kokkinizita.net> wrote:
Alright, I've done some proper testing.
I encoded 105 seconds of 8 bit PCM audio.
Flac got a ratio of .240 on -0 (least compression) and a ratio of .230 on -8
(most compression)
The algorithm got a ratio of "2.7446", which is 0.36 if you convert it to
the way flac measures. (take the inverse).
So flac does better in terms of absolute compression, ignoring any
performance measures.
Jeremy
On Tue, Jun 22, 2010 at 06:18:17PM -0300, A. C.
Censi wrote:
--
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On Tue, Jun 22, 2010 at 5:31 PM,
<fons(a)kokkinizita.net> wrote:
So I'll repeat the question: Does it decompress to the original ?
( _it_ meaning the file that was reported to be compressed better
than 7:1)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Does it decompress to the original ?
... lots of text but no answer ... 
22 Jun
22 Jun
3:58 p.m.
On Tuesday 22 June 2010 06:38:45 Gene Heskett wrote:
It was the lossless claim that got my attention, Jens.
I am well aware
that current compressors can beat that at "acceptable" quality.
Foe lossless check out:
http://www.wavpack.com/
http://flac.sourceforge.net/
drew
5068
days inactive
5069
days old
linux-audio-dev@lists.linuxaudio.org
19 comments
8 participants
participants (8)
-
A. C. Censi -
Adrian Knoth -
drew Roberts -
fons＠kokkinizita.net -
Gene Heskett -
Jens M Andreasen -
Jeremy -
Philipp Überbacher