Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #678 > unrolled thread

disclosure versus proof

Back to article view | Back to comp.compression

Contents

  disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-02 14:37 -0800
    Re: disclosure versus proof pfraser <pete_fraser@comcast.net> - 2012-01-02 15:05 -0800
      Re: disclosure versus proof Michael <michaelhh@gmail.com> - 2012-01-02 23:00 -0800
        Re: disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-03 04:22 -0800
      Re: disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-03 03:42 -0800
        Re: disclosure versus proof Jim Leonard <mobygamer@gmail.com> - 2012-01-03 07:48 -0800
    Re: disclosure versus proof Thomas Richter <thor@math.tu-berlin.de> - 2012-01-03 13:33 +0100
    Re: disclosure versus proof Jim Leonard <mobygamer@gmail.com> - 2012-01-03 08:04 -0800
      Re: disclosure versus proof stan <smoore@exis.net> - 2012-01-03 14:19 -0500
        Re: disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-04 01:16 -0800
          Re: disclosure versus proof glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-04 12:18 +0000
          Re: disclosure versus proof Jim Leonard <mobygamer@gmail.com> - 2012-01-04 08:06 -0800
            Re: disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-05 02:30 -0800
              Re: disclosure versus proof Jim Leonard <mobygamer@gmail.com> - 2012-01-06 13:45 -0800
                Re: disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-08 11:48 -0800
                  Re: disclosure versus proof pfraser <pete_fraser@comcast.net> - 2012-01-08 14:06 -0800
                  Re: disclosure versus proof stan <smoore@exis.net> - 2012-01-08 17:06 -0500
          Re: disclosure versus proof stan <smoore@exis.net> - 2012-01-05 22:06 -0500
            Re: disclosure versus proof jules Gilbert <jules.stocks@gmail.com> - 2012-01-06 10:35 -0800

#678 — disclosure versus proof

People say they want proof, really they want disclosure.  No.

It doesn't gain me anything to prove anything to most of you.  Of
course if someone has $50M or $100M, US cash, and is ready to do a
deal I will, at reasonable cost, provide proof by means of a two
machine demonstration.  You'll have to come to me.

Someone has published some fairly good rules for a demo showing
perpetual compression.  I want police there and I'll be mentioning
some changes at the last minute but I don't think a buyer will see
these as deal-killers.

And sure, we'll turn off each machine while the other is on.  And
transfer to a floppy.  And compress and decompress better than 100:1,
whatever you like.  And use client supplied files I've never seen
previously or know about in advance.  (My program XOR's all input with
pseudo-RAD, it matters not what you supply.)

Whatever you like so long as my interests are protected.  I'll have to
know the names of the parties in advance and have an opportunity to
meet the players.  Worst case, I may decline to proceed but in such an
event you will not have paid for a demo.

However, as it happens earlier today I showed one investor and later
this week I have one firm appointment with a VC in the Boston area and
expect to firm up a second meeting.

Also, this month I expect to invite several Boston area firms involved
in wireless and telco technology to a demonstration I'm giving on Cape
Cod.

[toc] | [next] | [standalone]

#680

jules Gilbert wrote:

> Also, this month I expect to invite several Boston area firms involved
> in wireless and telco technology to a demonstration I'm giving on Cape
> Cod.

I think you'd get more interest from this group if, rather than always
telling us what you're going to do, you did it then told us the result.

[toc] | [prev] | [next] | [standalone]

#681

On Jan 2, 3:05 pm, pfraser <pete_fra...@comcast.net> wrote:
> jules Gilbert wrote:
> > Also, this month I expect to invite several Boston area firms involved
> > in wireless and telco technology to a demonstration I'm giving on Cape
> > Cod.
>
> I think you'd get more interest from this group if, rather than always
> telling us what you're going to do, you did it then told us the result.


He has posted this stuff for what, four years? And that he was a crazy
stock mogel? *yawn* I will beat him to the punch ;)

Hehehehehehehehehehehhehehehehheheheheehehhheehheheehehehheheheehhe

Ok silly laughter done


Hehheheheheh

Ok, really done now... heh... gah, he is so easy to laugh at.

Btw that's way to cheap Jules.

The hard drive war is just heating up. HP is spending 1 billion on a
new a new tech facility to produce a new type of harddrive/RAM, IBM is
running two techs out, Racetrack and something else, and everyone else
is pushing their own ideas for the next universal memory.

You could easily ask for one billion USD if it is perpetual.

And since you could compress prior to sending you can also speed up
the Internet. Obama wants to spend 50 billion doing that.

Your way undercutting yourself. Go for the real numbers!

Plus the nobel prize, hutter, the various other prizes...

[toc] | [prev] | [next] | [standalone]

#684

On Jan 3, 2:00 am, Michael <michae...@gmail.com> wrote:
> On Jan 2, 3:05 pm, pfraser <pete_fra...@comcast.net> wrote:
>
> > jules Gilbert wrote:
> > > Also, this month I expect to invite several Boston area firms involved
> > > in wireless and telco technology to a demonstration I'm giving on Cape
> > > Cod.
>
> > I think you'd get more interest from this group if, rather than always
> > telling us what you're going to do, you did it then told us the result.
>
> He has posted this stuff for what, four years? And that he was a crazy
> stock mogel? *yawn* I will beat him to the punch ;)
>
> Hehehehehehehehehehehhehehehehheheheheehehhheehheheehehehheheheehhe
>
> Ok silly laughter done
>
> Hehheheheheh
>
> Ok, really done now... heh... gah, he is so easy to laugh at.
>
> Btw that's way to cheap Jules.
>
> The hard drive war is just heating up. HP is spending 1 billion on a
> new a new tech facility to produce a new type of harddrive/RAM, IBM is
> running two techs out, Racetrack and something else, and everyone else
> is pushing their own ideas for the next universal memory.
>
> You could easily ask for one billion USD if it is perpetual.
>
> And since you could compress prior to sending you can also speed up
> the Internet. Obama wants to spend 50 billion doing that.
>
> Your way undercutting yourself. Go for the real numbers!
>
> Plus the nobel prize, hutter, the various other prizes...

Oh, and nothing in nature is perpetual.  Sure, I use the term
"perpetual", but that's just pizazz, really, my method is repeatable,
even repeatable many times, but perpetual -- no, nothing in nature is
that.  Not even the moon and stars.

And I believe -- but have not tried to demonstrate, yet -- that an
important class of communication products is just ahead, because what
limits most communication systems is noise, and hello!, noise is
random.  Doing away with (better to say, managing noise, defeating the
problem, making signal detection possible regardless of the noise
level,) this opens up an important new class of communication
applications.

Of course I recognize that I'm 65, my health isn't good (I practically
support my pharmacy, and the local EMT's know where I live.)

So yeah, I do this but it's not where I spend most of my time.  I have
a few other activities, for example I counsel people, I also write.

Years ago I got into a big fight with a VC.  I mean a bigtime knock
down dragged out fight, which, had I lost, would have forced me out of
IT research.  I won when the lead attorney for the syndicate of VC's
was disbarred and the leader of the syndicate decided to take an
unearned but timely vacation in Australia.  (I had the second PC
editor, the first code generator for the 86/88, which did the BYTE
mag. prime sieve test in under four seconds, when the industry
standard was about twenty seconds.  And Microsoft, you gotta love
them, brought out a compiler which, when it saw the problem was the
prime sieve, generated code to do that problem.  I had written most of
a fortran compiler for Digital Research, Inc.  And the few times I
came to Pacific Grove, no one took the day off to go flying.)

That experience, while very painful, taught me a great deal about
their industry and if I had another market I would have gone there.
But really, in America and across the world (I think,) certainly the
west, large companies have adopted the operating strategy that is
common today wrt intellectual property and patents generally, to use
whatever you want you want without regard for the rights of others,
ignoring patents, and then, when sued, use the courts as the means to
negotiate a settlement.

Microsoft did this with Stack Electronics and today, I'm not sure that
any of the cell phone companies don't do this.  I don't know, I
haven't researched this question, but talking with attorney's,
sniffing around, that's what it looks like.  Look at the Apple /
Samsung fight.  And I have a smartphone -- who can function without
one?

Anyway, I don't have too many places I can sell to...

And I actually can compress RAD, I did in fact show a fellow
yesterday, just as I said in my earlier post.  And, I decided many
years ago that I would rather the technology die with me rather than
see it used by others without I and/or my estate getting proper
compensation.

[toc] | [prev] | [next] | [standalone]

#683

On Jan 2, 6:05 pm, pfraser <pete_fra...@comcast.net> wrote:
> jules Gilbert wrote:
> > Also, this month I expect to invite several Boston area firms involved
> > in wireless and telco technology to a demonstration I'm giving on Cape
> > Cod.
>
> I think you'd get more interest from this group if, rather than always
> telling us what you're going to do, you did it then told us the result.

Peter, I notice you didn't seem to read, or perhaps you simply weren't
cognizant of my remark that yesterday I had shown one investor.

Your gap is why I don't bother with you people anymore.  I gave it my
best shot, I really did, for years and years, thinking that I could
make the internet work for me.  20-25 years ago I used to do VC
deals.  And I was able to defang one or two.  And toothless sharks
don't last long...

But you guys are nothing more than a mob.  If science depended, in
part, on the social dynamics I've seen demonstrated here, we would not
yet be using wheels.  Because the wheel would have been invented
thousands of times, and the invention stolen and the inventor killed
each time -- not a perfect allegory but reasonably accurate.

And Michael, your facts are wrong;  I built my first compressor to
process previously compressed file data more than 16 years ago.  And
as imperfect as it was I'll bet it's a lot better than anything you've
done.  Or you Peter.

For example, the program I demonstrated yesterday compresses each
client supplied 256 byte block into SEVERAL bytes, the number varies
but is less than ten, and -- before correction -- the likelihood of a
bit error is roughly (1 / 2 pi) * 10 ^ -10, per bit.

So yeah. I have to send a correction vector but usually, it's a vector
of zero's!

[toc] | [prev] | [next] | [standalone]

#687

On Jan 3, 5:42 am, jules Gilbert <jules.sto...@gmail.com> wrote:
> For example, the program I demonstrated yesterday compresses each
> client supplied 256 byte block into SEVERAL bytes, the number varies
> but is less than ten, and -- before correction -- the likelihood of a
> bit error is roughly (1 / 2 pi) * 10 ^ -10, per bit.
>
> So yeah. I have to send a correction vector but usually, it's a vector
> of zero's!

Is the size of the compressed data plus the correction vector smaller
than the original data?

[toc] | [prev] | [next] | [standalone]

#685

On 02.01.2012 23:37, jules Gilbert wrote:
> People say they want proof, really they want disclosure.  No.
>
> It doesn't gain me anything to prove anything to most of you.  Of
> course if someone has $50M or $100M, US cash, and is ready to do a
> deal I will, at reasonable cost, provide proof by means of a two
> machine demonstration.  You'll have to come to me.

Ok, then why do you post here? If you have nothing to show, you have 
nothing to show.

We all know the real reasons, don't we? You just try to attract some 
lazy people to collect money for nothing, posting here to keep such 
people interested in your none-ideas.

To all potential "buyers": Jules is a known con-artist in this group, 
don't put your money into something that is so easily refuted.

> And sure, we'll turn off each machine while the other is on.  And
> transfer to a floppy.  And compress and decompress better than 100:1,
> whatever you like.

You know the game, but you ignore the rules. Apparently, for every 
lossless compressor, it *must* expand most of its input sequences. But I 
guess you know. You just don't want your "investors", avoiding the term 
"victims", to know.

> Whatever you like so long as my interests are protected.

Your interest as in "not going to jail for fraud"? I beg your pardon, 
but I believe the interest of the public of putting people like you out 
of business would be more relevant than your interest in collecting 
money for non-working algorithms.

> However, as it happens earlier today I showed one investor and later
> this week I have one firm appointment with a VC in the Boston area and
> expect to firm up a second meeting.

Dear investor, hope you read this: Make a simple search for "counting 
argument". It is extremely simple, won't cost you more than ten minutes 
of time to search, and not more than 30 minutes to understand. That time 
is way much better invested than putting money into Jules con-art, even 
if your time is paid premium.

> Also, this month I expect to invite several Boston area firms involved
> in wireless and telco technology to a demonstration I'm giving on Cape
> Cod.

Dear Boston area firms: Stay away from this guy.

[toc] | [prev] | [next] | [standalone]

#690

On Jan 2, 4:37 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
> People say they want proof, really they want disclosure.

It is possible to provide proof without disclosing the exact method:

1. Someone provides you with a block of data to compress.
2. You compress the data
3. You make public the compressed data and a program that can
decompress it into the original source

By doing this, you prove your system works, and you aren't disclosing
the compressor or compression method.  People could analyze the
decompressor binary data and program, but that won't tell them
anything about how your analysis/compression method works.  What is
wrong with this scenario, and why won't you provide proof in this
manner?  Do you think that disclosing a compiled decompressor will
somehow expose your entire method?  (If so, you are wrong.)

You will attract a lot more potential buyers if you can demonstrate
your system in the manner described above.  I am on a first-name basis
with one VC and he won't touch compression because of the Adam's
Platform debacle and closed tests that are easily faked.

[toc] | [prev] | [next] | [standalone]

#691

Jim Leonard wrote:
> On Jan 2, 4:37 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
>> People say they want proof, really they want disclosure.
>
> It is possible to provide proof without disclosing the exact method:

<snip - man pulling back curtain to reveal the true nature of the wizard>

Haven't we been here before? I did watch the twilight zone marathon
over the new year, nevertheless I think we've done this before.

Sisyphus

[toc] | [prev] | [next] | [standalone]

#699

On Jan 3, 2:19 pm, stan <smo...@exis.net> wrote:
> Jim Leonard wrote:
> > On Jan 2, 4:37 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
> >> People say they want proof, really they want disclosure.
>
> > It is possible to provide proof without disclosing the exact method:
>
> <snip - man pulling back curtain to reveal the true nature of the wizard>
>
> Haven't we been here before? I did watch the twilight zone marathon
> over the new year, nevertheless I think we've done this before.
>
> Sisyphus

Don't worry Sisyphus, the idea that I can distribute a decompressor
and associated compressed files and not have it reverse engineered is
one of the most foolish assertions I have read;  Some have suggested
that plan to me, I hope their motivations were innocent.  If someone,
not very technical, doesn't realize the implications, let me inform
them:  Doing this would show sufficient details that others would be
able to produce work-alike programs.   Because, having access to even
this level of materials, within a day or so, a skilled programmer
using a debugger or even simply making small changes to a compressed
file and attempting decompression would permit someone to learn quite
a bit about the underlying basis, about the principles of operation my
program depends on, so I just can't permit this.  Possibly Mr. Leonard
isn't familiar with how easily an executable file can be turned back
into something that can be understood by a human, I don't know;  I
don't know his background.

I used to enjoy Twilight Zone episodes too!, but when we turn off the
TV it's back to research and development for some of us, I assume that
includes you.

[toc] | [prev] | [next] | [standalone]

#701

jules Gilbert <jules.stocks@gmail.com> wrote:

(snip)
> Don't worry Sisyphus, the idea that I can distribute a decompressor
> and associated compressed files and not have it reverse engineered is
> one of the most foolish assertions I have read;  Some have suggested
> that plan to me, I hope their motivations were innocent.  

Maybe most, but maybe not in all cases can one easily reverse engineer
the compression program from the decompression program.

Ones like LZW, where the decompressor needs to keep the dictionary
just as the compressor does are likely easy.

Something similar to the one-way functions used in public-key
encryption might be possible.

-- glen

[toc] | [prev] | [next] | [standalone]

#702

On Jan 4, 3:16 am, jules Gilbert <jules.sto...@gmail.com> wrote:
> Doing this would show sufficient details that others would be
> able to produce work-alike programs.

Work-alike DEcompressors, sure.  But not COMpressors.  If you believe
that someone could somehow reverse-engineer your entire compression
method from a compressed file and a decompressor binary, you are
mistaken.  You mentioned that you XOR the input stream with a random
stream as part of your method -- without someone owning the compressor
and being able to analyze that stream or how it is generated, how on
earth is someone supposed to reverse engineer the entire method?

Let's take a simple LZSS compressor/decompressor as an example.  If
someone gives me an LZSS compressed file and a decompressor, I could
run it and see it produces the same data as the input, verifying the
method works.  I could also determine that the compressed file is made
up of literal data and match offset+length data, which explains the
compressed file format.  But there is no way I could determine *how*
the compression method chose those particular match offsets+lengths --
the actual decision-making process is hidden from me.  I might be able
to make a workaline compressor that worked for *that specific set of
input data*, but it would be suboptimal (or non-functional!) for all
input sets.

You still didn't answer my question about whether or not the
compressed data + the size of the "correction vector" was less than
the size of the original data.

> isn't familiar with how easily an executable file can be turned back
> into something that can be understood by a human, I don't know;  I
> don't know his background.

I am well-versed in disassembling x86 binaries.  That is not the
point.  Just because I could disassemble the decompression process
does not mean I, or anyone else, can magically divine the process that
got the data in that state to begin with (see prior explanation).

I don't understand why you won't allow people to verify your method
works in a manner that won't compromise your method.  Limiting a test
to your own hardware proves nothing, as demonstrations are easily
faked.

[toc] | [prev] | [next] | [standalone]

#712

On Jan 4, 11:06 am, Jim Leonard <mobyga...@gmail.com> wrote:
> On Jan 4, 3:16 am, jules Gilbert <jules.sto...@gmail.com> wrote:
>
> > Doing this would show sufficient details that others would be
> > able to produce work-alike programs.
>
> Work-alike DEcompressors, sure.  But not COMpressors.  If you believe
> that someone could somehow reverse-engineer your entire compression
> method from a compressed file and a decompressor binary, you are
> mistaken.  You mentioned that you XOR the input stream with a random
> stream as part of your method -- without someone owning the compressor
> and being able to analyze that stream or how it is generated, how on
> earth is someone supposed to reverse engineer the entire method?
>
> Let's take a simple LZSS compressor/decompressor as an example.  If
> someone gives me an LZSS compressed file and a decompressor, I could
> run it and see it produces the same data as the input, verifying the
> method works.  I could also determine that the compressed file is made
> up of literal data and match offset+length data, which explains the
> compressed file format.  But there is no way I could determine *how*
> the compression method chose those particular match offsets+lengths --
> the actual decision-making process is hidden from me.  I might be able
> to make a workaline compressor that worked for *that specific set of
> input data*, but it would be suboptimal (or non-functional!) for all
> input sets.
>
> You still didn't answer my question about whether or not the
> compressed data + the size of the "correction vector" was less than
> the size of the original data.
>
> > isn't familiar with how easily an executable file can be turned back
> > into something that can be understood by a human, I don't know;  I
> > don't know his background.
>
> I am well-versed in disassembling x86 binaries.  That is not the
> point.  Just because I could disassemble the decompression process
> does not mean I, or anyone else, can magically divine the process that
> got the data in that state to begin with (see prior explanation).
>
> I don't understand why you won't allow people to verify your method
> works in a manner that won't compromise your method.  Limiting a test
> to your own hardware proves nothing, as demonstrations are easily
> faked.

Yeah, but XOR'ing with pseudo-RAD isn't all I do.  For example, I use
zlib.  That's a well know system, seeing where I access that would
likely teach someone a great deal.

Wait until I have posted here again.  I just need to think now.

[toc] | [prev] | [next] | [standalone]

#727

On Jan 5, 4:30 am, jules Gilbert <jules.sto...@gmail.com> wrote:
> Yeah, but XOR'ing with pseudo-RAD isn't all I do.  For example, I use
> zlib.  That's a well know system, seeing where I access that would
> likely teach someone a great deal.

Not really; it sounds like you're using zlib for compression of your
residuals -- which is both common (using an RLE or statistical back-
end for residuals), and also doesn't hint at the real meat of your
method (the prediction algorithm that produces the residuals).

[toc] | [prev] | [next] | [standalone]

#737

On Jan 6, 4:45 pm, Jim Leonard <mobyga...@gmail.com> wrote:
> On Jan 5, 4:30 am, jules Gilbert <jules.sto...@gmail.com> wrote:
>
> > Yeah, but XOR'ing with pseudo-RAD isn't all I do.  For example, I use
> > zlib.  That's a well know system, seeing where I access that would
> > likely teach someone a great deal.
>
> Not really; it sounds like you're using zlib for compression of your
> residuals -- which is both common (using an RLE or statistical back-
> end for residuals), and also doesn't hint at the real meat of your
> method (the prediction algorithm that produces the residuals).

I've written up a few responses Jim, but at the present time it just
wouldn't be smart for me to post.

[toc] | [prev] | [next] | [standalone]

#738

jules Gilbert wrote:

>
> I've written up a few responses Jim, but at the present time it just
> wouldn't be smart for me to post.

Admirable restraint.

[toc] | [prev] | [next] | [standalone]

#739

jules Gilbert wrote:
> On Jan 6, 4:45 pm, Jim Leonard <mobyga...@gmail.com> wrote:

<snip>

> I've written up a few responses Jim, but at the present time it just
> wouldn't be smart for me to post.

If there's ever a compression museum built, this quote has to go on a
plaque in front of the building.

[toc] | [prev] | [next] | [standalone]

#718

jules Gilbert wrote:
> On Jan 3, 2:19 pm, stan <smo...@exis.net> wrote:
>> Jim Leonard wrote:
>> > On Jan 2, 4:37 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
>> >> People say they want proof, really they want disclosure.
>>
>> > It is possible to provide proof without disclosing the exact method:
>>
>> <snip - man pulling back curtain to reveal the true nature of the wizard>
>>
>> Haven't we been here before? I did watch the twilight zone marathon
>> over the new year, nevertheless I think we've done this before.
>>
>> Sisyphus
>
> Don't worry Sisyphus, the idea that I can distribute a decompressor
> and associated compressed files and not have it reverse engineered is
> one of the most foolish assertions I have read;  Some have suggested
> that plan to me, I hope their motivations were innocent.

As noted, I'm sure I've heard this before. You don't think
verification is possible without disclosure, and you've stated so
repeatedly.

So if I have it straight, you are clever enough to come up with a
technique that nobody has ever seen and apparently even defies known
established science yet you aren't clever enough to come up with a
technique to provide verification without disclosure. 

With your fear of disclosure why even continue to talk about what you
are working on?  Aren't you afraid of terribly clever hackers
targeting you and your incredibly valuable technique?

Sisyphus, again

[toc] | [prev] | [next] | [standalone]

#725

On Jan 5, 10:06 pm, stan <smo...@exis.net> wrote:
> jules Gilbert wrote:
> > On Jan 3, 2:19 pm, stan <smo...@exis.net> wrote:
> >> Jim Leonard wrote:
> >> > On Jan 2, 4:37 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
> >> >> People say they want proof, really they want disclosure.
>
> >> > It is possible to provide proof without disclosing the exact method:
>
> >> <snip - man pulling back curtain to reveal the true nature of the wizard>
>
> >> Haven't we been here before? I did watch the twilight zone marathon
> >> over the new year, nevertheless I think we've done this before.
>
> >> Sisyphus
>
> > Don't worry Sisyphus, the idea that I can distribute a decompressor
> > and associated compressed files and not have it reverse engineered is
> > one of the most foolish assertions I have read;  Some have suggested
> > that plan to me, I hope their motivations were innocent.
>
> As noted, I'm sure I've heard this before. You don't think
> verification is possible without disclosure, and you've stated so
> repeatedly.
>
> So if I have it straight, you are clever enough to come up with a
> technique that nobody has ever seen and apparently even defies known
> established science yet you aren't clever enough to come up with a
> technique to provide verification without disclosure.
>
> With your fear of disclosure why even continue to talk about what you
> are working on?  Aren't you afraid of terribly clever hackers
> targeting you and your incredibly valuable technique?
>
> Sisyphus, again

I will have a general statement as to what I do soon, probably this
weekend.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web