HDTenEightyP/NetNews huggingface dataset:
From: cjcho@yise.ysi.co.kr (Cho Chang Je)
Subject: Good compressor for binary image ?
Organization: Yeonjoo Systems, Inc. Seoul Korea.
Date: Mon, 13 Apr 92 01:22:37 GMT

Dear Netman:

I am looking for a compression algorithm or source program
to compress a binary image (a bit per pixel). I was implmented
a CCITT group 3/4 algorithms. But their compression ratio 
is about 1/10.  Are there programs wih greater compression ratio?
Although it takes more time to compress an image,  I want
it has geater  compression ratio  and it is not destructive.  
Recently I read fractal compression algorithms. 
It has very high compression ratio, but it is desructive. 




-----------------------------------------------------------
Chang Je Cho

cjcho@yise.ysi.co.kr
Yeonjoo Institute of Systems Engineering 
-----------------------------------------------------------
Newsgroups: comp.compression
From: epang@fraser.sfu.ca (Eugene Pang)
Subject: Re: PKZIP encryption contest
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 15 Apr 1992 07:15:53 GMT

I've been trying to follow this thread, and I thought I'd throw in my two
cents.  Since PK says there's a message inside, it's not necessarily a
12K message.  In fact it may be a small message (say 1 line), that's
perfectly legible (once you find it), surrounded by useless data.  The effect
is that you would have to test your decryption key on the whole file, rather
than looking at just the first 10-20 bytes, for example.  And with a very
low signal to noise ratio, I suppose a message surrounded by random data,
would look like random data to some compression methods.
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 8 Apr 92 07:01:55 GMT
Organization: Academic Computer Centre Utrecht

In <1992Apr08.011951.1454@donau.et.tudelft.nl> cornet@duteca.et.tudelft.nl (Jan-Pieter Cornet) writes:

>nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>>In my PKLite, DIET, LZEXE comparission I noted the existence of an utility
>>to reverse the "irreversable compression" oprion of PKLite. I never got
>>so much responses to one single item. Everyone wants to know where to get it.
>>I uploaded it to garbo for general availability.

>Interesting... I wrote DISLITE some months ago, and heard it has taken
>an enourmous flight everywhere. I didn't realize that people would be
>so interested in this...
>I uploaded it to nic.funet.fi, but I never heard a single word from them.
>I figured they regarded the program too much as "hacker software" rather
>than as a useful tool.

>I do hope, Nico, that you uploaded the most recent version, 0.92, dated
>30-12-91. Well, the differences aren't that bad. 0.92 basically handles
>the pkzip 1.93alpha properly.

I did, I did.

>...
>The reactions I got so far on the program are mainly from PKLITE prof.
>owners, saying that "their investment is now worthless". Well, I didn't
>know _why_ they bought PKLITE, but PKWARE only _sells_ compression, not
>encryption (which was also, if I'm not mistaken, said by a PKWARE
>representative on a compuserve conference). And besides, the people with

Is this an excuse for their very weak AV schmeme and their not so strong
encryption scheme? (BTW I am aware of the fact that ARJ is even worse
in this respect but I know Robert Jung is working hard on improving
this)

>enough knowledge to hack a program, can quite easily do the job of DISLITE
>by hand, it is not that hard. (Maybe except for the fixup table reorganiser.)

I agree. Using Turbo Debugger and a few seconds is anough to break PKLite
anyway.

>...
>Regards,
>-- Jan-Pieter
>cornet@duteca.et.tudelft.nl

Nico de Vries
---------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl
VOICE : +31-3404-24931
BBS   : +31-30-341401 (Nico De_vries)

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
Newsgroups: comp.compression
From: venkat@vidcom.csc.ti.com (Venkat Venkateswar)
Subject: H.261 test sequences
Organization: Texas Instruments
Date: Thu, 9 Apr 1992 15:35:07 GMT

I would like to get a hold of some standard test sequences like:
(1) Miss America (2) Salesman etc. Are these sequences stored in
any public domain ftp sites? Are they available for distribution 
by any other means (tape ..)? 

Thanks in advance,
Venkat

Newsgroups: comp.compression
From: harry@neuron6.jpl.nasa.gov (Harry Langenbacher)
Subject: Re: question about "zoo xp foo.tar.zoo foo.tar" usage
Organization: JPL Pasadena CA
Date: Thu, 9 Apr 1992 17:17:16 GMT

In article <+prjh1c.ead@netcom.com> ead@netcom.com (Eric De Mund) writes:
>    % zoo xp foo.tar.zoo foo.tar | tar -xvf -

>doesn't work because foo.tar is prepended with:

>    ********
>    foo.tar
>    ********

>is there any way a non-filter zoo file can be made to behave this way?

>eric de mund
>ead@netcom.com

zoo xpq foo.tar.zoo foo.tar | tar -xvf -

-- 
Harry Langenbacher 818-354-9513 harry%neuron6@jpl-mil.jpl.nasa.gov
Neuroprocessing & Analog Computing Devices Group, FAX 818-393-4540
JPL,  M/S 302-231, 4800 Oak Grove Dr, Pasadena CA 91109        USA
From: tetsu@kutsuda.kuis.kyoto-u.ac.jp (UEHARA Tetsu=TaLow)
Newsgroups: comp.compression
Subject: LHa for UNIX has been released.
Date: 8 Apr 92 12:55:34 GMT
Reply-To: tetsu@kutsuda.kuis.kyoto-u.ac.jp
Organization: Kyoto Univ. dept. of Info. Sci. Tsuda Lab.

LHa for UNIX Version 1.00 has been posted to fj.sources.
It is also available on some anon-ftp sites in Japan.

(From archie)
Host theta.iis.u-tokyo.ac.jp   (157.82.96.67)
    Location: /local
      FILE      rw-rw-r--     88479  Apr  2 13:52   lha-1.00.tar.Z

Host ftp.kuis.kyoto-u.ac.jp   (130.54.20.1)
    Location: /utils
      FILE      rw-r--r--     93221  Apr  3 16:40   lha-1.00.tar.Z

Unfortunately, some of the documents are written in Japanese.
But even without these documents, I suppose you can easily port it
to your machines.

Known problems of the version are:

1) If you have Suns with OS4.0.3, you must not add -DUSESTRCASECMP
   to the compiler option (A bug in the document).

2) If your compiler cannot recognize `void', you may have a problem
   in util.c. Then you must remove the line 199 of the file.

If you have any troubles, mail to me. Thanks & enjoy.
---
Sorry for my troubled English.... I'm a typical Japanese.
UEHARA, Tetsutaro / JUNET:tetsu@kuis.kyoto-u.ac.jp / NIFTY:TAE02013
TEL:+81-75-753-5394 / FAX:+81-75-753-4829
Newsgroups: comp.compression
From: N02@csci1.csci.unt.edu (Orion)
Subject: Re: 16: 1 data compression
Keywords: bogus, compression
Organization: University of North Texas
Date: Wed, 8 Apr 1992 15:27:34 GMT

In article <1345600001@igc.org> An-Ly Yao <anlyyao@igc.org> writes:

>Hi Carl,

>Of course you can compress any file 16:1. Actually - considering the prices
>for 8:1 compression and 16:1 compreeion - I really have to think about
>offering a compressor for 32:1 or 64:1. 

>There is one problem however: the *de*compression. But that's annother story!
>:-)  :-)  :-)  :-)  :-)

>so long (or short), Goetz

>Seoul 1992/04/07

I invented a compression algorithm last week that compresses everything down 
to one bit.  I'm still working on the decompression part, though.

                 --Orion
----------------------------------------------------------
                          Orion Auld                      
----------------------------------------------------------
  Win 3.0 multitask: Choke on gum and trip simultaniously!
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: Stupit compressor idea (but interesting).
Date: 13 Apr 92 16:33:25 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <2367@accucx.cc.ruu.nl>, nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:

|  Suppose we take a compressed file (doesn't matter which compressor) and
|  we remove a single byte. The first one. Now what the decompressor does
|  is trying ann 256 options and takes the file which looks most likely (this
|  is the weak part of cource but we could try decompression an compressio
|  and if the decompressor goes wrong we just don't remove the byte).
|  This seems to work to me.

  A CRC from the original file would make "looks most likely" a lot
easier to identify. Other than that, as you say, it's interesting.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: pdh@netcom.com (Phil Howard )
Newsgroups: comp.compression
Subject: Re: 16: 1 data compression
Keywords: bogus, compression
Date: 16 Apr 92 18:54:33 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

>I invented a compression algorithm last week that compresses everything down 
>to one bit.  I'm still working on the decompression part, though.

This is solvable.

Hint: ask the user what was in the original file.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/
From: weber@gacvx1.gac.edu
Newsgroups: comp.compression
Subject: ?compress algorithm source
Date: 17 Apr 92 01:59:01 GMT
Article-I.D.: gacvx1.1992Apr16.195901.1
Organization: Gustavus Adolphus College, St. Peter, Minnesota
Nntp-Posting-User: weber


Could anyone either send me or tell me the source
of some algorithms that can be used to compress
text files. It would be good if the algoritms
were expressed in C, however pseudocode would be
fine.
Please e-mail
weber@gacvx1.gac.edu
thanks,
Les
Newsgroups: comp.compression
From: kurt@tc.fluke.COM (Kurt Guntheroth)
Subject: Too much lossy encoding?
Keywords: PASC, audio
Reply-To: kurt@tc.fluke.COM (Kurt Guntheroth)
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Date: Wed, 8 Apr 1992 16:03:00 GMT

Is it just me or is anyone else out there concerned that we are using lossy
encoding "too much" as a substitute for denser storage and better transmission
methods?

Analog recording and storage methods are inherently lossy, but the loss
depends on the quality of the recording and playback mechanisms.  As
mechanisms improve, the quality of the recorded, stored, and played information
improves.

Digital recording and storage methods have a fixed quality that depends on
the way the data was encoded.  Once a format has been selected, no further
gain in quality is possible, only reduction in the effects of aging on the
digital bits.

Digital storage mechanisms like audio CD's force us to accept a (Nyquist)
limitation on the stored data, even though they encode the full imput
waveform.  While the conventional wisdom is that we cannot hear sound above
22 KHz, this is not completely true; we are sensitive to phase changes at
higher frequencies.  Now proposals like PASC and audio MPEG are coming along
that are lossy; they filter out sounds "we can't hear anyway".  We are moving
down from being "about as good as a phonograph" to "about as good as FM radio"
to achieve playback on media that are still undergoing rapid development.

It's just the same in the video world; complex formats based on removing
visual data "we can't perceive anyway" are multiplying.  Only it isn't
always true.  There are problem images, like sports and other fast motion
subjects.  

Ten or twenty years from now, when storage densities are far higher,
transmission facilities have more bandwidth (for instance fiber optic
cable to your phone and TV), and better picture tubes and amplifiers have
appeared (as they always have before), aren't we going to be really pissed
off that we accepted so much lossy encoding that we can in fact detect?
I hope everybody implementing this technology will think about this.  You
are going to have to live with your decisions.
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.compression
Subject: Re: Stupit compressor idea (but interesting).
Date: 13 Apr 92 20:20:56 GMT
Organization: CWI, Amsterdam

In article <1992Apr13.163325.1245@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
 > In article <2367@accucx.cc.ruu.nl>, nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
 > |  Suppose we take a compressed file (doesn't matter which compressor) and
 > |  we remove a single byte. The first one. Now what the decompressor does
 > |  is trying ann 256 options and takes the file which looks most likely (this
 > |  is the weak part of cource but we could try decompression an compressio
 > |  and if the decompressor goes wrong we just don't remove the byte).
 > |  This seems to work to me.
 > 
 >   A CRC from the original file would make "looks most likely" a lot
 > easier to identify. Other than that, as you say, it's interesting.

Of course.  You add redundancy, so it is easier to identify.  But why a CRC?
Why not a simple checksum?  In this case the latter will achieve its goal
(retrieving the lost byte) easier.  The original goal of CRC's and checksums
(detecting errors) is already lost of course.

Back to the original idea of removing the first byte.  The decompressor has
to do 256-way decompression, many of which might lead to a dead alley.  Some
remain as valid decompressions.  Checking which of those are valid is a non-
trivial task.  My biggest problem with the scheme is that for most kinds of
compression you have increased the time to decompress by a factor of 256.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
dik@cwi.nl
From: rem@public.BTR.COM (Robert E. Maas  rem@btr.com)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Date: 11 Apr 92 08:11:10 GMT
Organization: BTR Public Access UNIX, MtnView CA. Contact: Customer Service cs@BTR.COM

I have an idea that will simultaneously protect against unauthorized copying
of digital music/video media and provide a backup in case the original analog
studio master gets damaged or deteriorates over time:

Resample the master with slightly different bias adjustments and timing
skew, so that each digital production disk is unique. Compute a checksum for
each disk and that can be the serial number. Keep track of who buys which
serial number. Then if you ever find two people with disks that have the
same checksum, or anyone has a checksum that matches somebody else's registered
serial number, you have proof somebody copied a disk without authorization.
If the master gets damaged, collect a bunch of distribution disks and combine
their signals to make a new master which won't be quite as good as the original
but will be a lot better than any single distribution disk.
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Organization: California Institute of Technology, Pasadena
Date: Fri, 10 Apr 1992 22:53:01 GMT

In article <22537@alice.att.com> jj@alice.UUCP (James D. Johnston) writes:
>Pardon me?  While, if you are using a strict reading, the
>ear does not do a Fourier analysis, it does do a frequency analysis,
>and due strictly to the mechanical nature of the cochlea.

I agree completely.  My question then is, what does 22 KHz mean in terms
of the ear's frequency analysis?  The ear does not split things into
impulse functions in the frequency domain, even though we can approximate
that analysis (probably with a lot of brain involved) to about 1/1200
of an octave.  (Well I can't, but piano tuners can.)

>Given this, your blanket assertion, presented as fact, that
>there is no physical reality to the frequency domain, is 
>shown as utterly false, by the counterexample of the human
>hearing apparatus.  It is in fact shown more than false,
>it is shown as exactly opposite the facts.

Certainly if you interpret what I said as that the concept of frequencies
are useless, then yes, I was completely wrong.  If I said that, I certainly
didn't think it.  I know the cochlea does a sort of frequency analysis.
My point was that that analysis is not a Fourier analysis, and dropping
all Fourier components past 22 KHz probably has little validity with
respect to the signal decomposition that the ear (and brain) does do.

I think this is a valid topic of discussion on this newsgroup, and so it
is not really benficial to tell people to not post things that are false.
The beauty of newsgroups is that if you post something false, there is a
good chance that someone will correct you.  As you have done.  It is also
not necessary to precede every posting with "what follows is opinion and
misconceptions based on hearsay and sometimes total fabrication", since
everyone who reads newsgroups already knows that about every posting they
see.  I don't think anyone would read a posting and then run out and
invest a bunch of money based on what they read.  I know I wouldn't.  :-)

Mark Adler
madler@tybalt.caltech.edu
Newsgroups: comp.compression
From: chet@netcom.com (Eric Chet)
Subject: Info
Date: Sun, 05 Apr 92 23:38:38 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

Hello
     I'm looking for some sources.  I need the latest lha source for unix.
I'm alos looking for Gene Olson's COMPACT that was submitted to comp.sources.
misc and Dr Dobbs compression contest.  Does any body know the Volume
In comp.sources.misc it can be found?

Thanks in advance

Eric


-- 
~
/**************************************************************************
 * Eric Chet       | Amiga does it better
 * chet@netcom.com | Ray Tracing and other graphics techniques 
 * BIX: chet       | "Use what is useful, simply to simplify"
 */
Newsgroups: comp.compression
From: mmastand@isis.cs.du.edu (Mark Mastandrea)
Subject: unix compress alternative
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Distribution: usa
Date: Wed, 8 Apr 92 02:22:49 GMT

Hi,
I am currently using the unix compress to compress Oracle database
partitions and am looking for suggestions to use something else that
would acheive the same types of compression ratios at a faster speed.
I realize that compression is a factor of the data being compress and
am looking for a compression technique that generally outperforms
the unix compress. Please mail all replies to mmas@gwl.com.

Thanks in advance

Mark
From: cornet@duteca.et.tudelft.nl (Jan-Pieter Cornet)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 8 Apr 92 01:19:51 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>In my PKLite, DIET, LZEXE comparission I noted the existence of an utility
>to reverse the "irreversable compression" oprion of PKLite. I never got
>so much responses to one single item. Everyone wants to know where to get it.
>I uploaded it to garbo for general availability.

Interesting... I wrote DISLITE some months ago, and heard it has taken
an enourmous flight everywhere. I didn't realize that people would be
so interested in this...
I uploaded it to nic.funet.fi, but I never heard a single word from them.
I figured they regarded the program too much as "hacker software" rather
than as a useful tool.

I do hope, Nico, that you uploaded the most recent version, 0.92, dated
30-12-91. Well, the differences aren't that bad. 0.92 basically handles
the pkzip 1.93alpha properly.

>The main reason most people wanted to have it was that crackers use PKLite
>to hide viruses into executables and nobody knows for sure virus scanners
>are capable of handling that. Also recompression by other EXE compressor
>was mentioned several times. 

That's two important reasons why I wrote it. But also, of course, to be able
to patch executables (from changing fixed build-in filenames upto cheating
games). And to store executables on compress partitions (stacker, speedstor),
etc.etc...

The reactions I got so far on the program are mainly from PKLITE prof.
owners, saying that "their investment is now worthless". Well, I didn't
know _why_ they bought PKLITE, but PKWARE only _sells_ compression, not
encryption (which was also, if I'm not mistaken, said by a PKWARE
representative on a compuserve conference). And besides, the people with
enough knowledge to hack a program, can quite easily do the job of DISLITE
by hand, it is not that hard. (Maybe except for the fixup table reorganiser.)

Taking Nico's words into consideration: please do not mail me asking to
send you the package. It will soon be available for anonymous ftp, I hope. 

Regards,
-- Jan-Pieter
cornet@duteca.et.tudelft.nl
From: thom@f517.n107.z1.ieee.org (Thom Henderson)
Newsgroups: comp.compression
Subject: Re: Where is the new PKZIP?
Date: 9 Apr 92 23:00:00 GMT
Article-I.D.: zeus.13570.29E7AF43
Organization: FidoNet node 1:107/517 - SEAboard HST, Clifton NJ


 # I suppose Thom wants us to believe that PK took the source to ARC and
 # then compiled it under a different compiler that would give PKARC its
 # significant  speed advantage.

Nope.  They took the sources and rewrote the innermost 10% to speed it up. 
The remaining 90% of the code was ours.  

 # Oh, and sorry Thom, but since you settled out of court, *nothing* has
 # been proven on either side.  Certainly your lawyers told you that
 # much?

Wrong.  We have here a paper that says judgement for plaintif.  Our lawyer
(singular -- we're a very small company; it was PKWARE that had three lawyers)
says we won.  

 # Also, why has not NoGate Computing been charged with the same
 # thing, since their product, formerly GSARC, now PAK, uses the same
 # file format, and the same algorithms?  

Why would we sue NoGate?  We have no reason to think that they stole our
sources.  I don't know if a file format even CAN be copyrighted; an algorithm
cannot be.  

Believe what you want -- you will anyway.  

--- SEAmail 1.10
 * Origin: System Enhancement Associates  (107/517)
--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Thom Henderson - Internet: thom@f517.n107.z1.ieee.org
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Stupit compressor idea (but interesting).
Date: 11 Apr 92 07:48:40 GMT
Organization: Academic Computer Centre Utrecht

Hi,

I just read Peter Gutmans aproach to decompressing 2 bytes to the complete
works of sheakespeare. He does it with a team of monkeys. This made me think
and I thought up the following:

Suppose we take a compressed file (doesn't matter which compressor) and
we remove a single byte. The first one. Now what the decompressor does
is trying ann 256 options and takes the file which looks most likely (this
is the weak part of cource but we could try decompression an compressio
and if the decompressor goes wrong we just don't remove the byte).
This seems to work to me.

Perhaps could this system be enhanced to compress even better (e.g. removing
each 4th byte and trying again and again to repair it. If decompression
fails we dont remove it.). An extra bit needs to be inserted to determine
if a byte has to be removed).

Probably this is the most stupit idea I ever had (whell...) but nevertheless
I wonder if there might be some truth in it.


Nico de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (comming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.