HDTenEightyP/NetNews huggingface dataset:
From: ski8032@tamsun.tamu.edu (The Man Behind The Curtain)
Subject: Re: compressing gif files
Organization: Texas A&M University, College Station
Date: Fri, 20 Nov 1992 21:16:47 GMT

Thus spake wardrb@cs.utexas.edu (Richard Byron Ward):
>In article <3309@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>|In <1992Nov8.114946.11060@ccsun7.csie.nctu.edu.tw> chuang@csie.nctu.edu.tw ( ** No Record **) writes:
>|>    You can use the gifblast.exe find in CCCA Garbo/pc/gifutil/gifbla11.zip.
>|>The author anounce that program can save about 25 to 30 percent of space.
>|>Most important of all ,It's looseless compress(JPEG format is loosely compress)
>|>So it's not so efficient as JPEG format in saving space but save the resolution 
>|I am reasonably sure (the author of GIFBLAST mentioned it I believe) that
>|GIFBLAST does use lossy compression.
>|
>The main selling point of GIFBLAST is that it performs lossless compression,
>it's certainly not speed!  The author did mention that the decompressed
>GIF may not match the original because of slight variations in the way that
>different programs encode GIFs, but that the information is unchanged.

There is a second way to compress GIFs as well... using GIFLITE, which *is*
a lossy compression, unlike GIFBLAST.  However, the author of the program
claims that the information which is discarded is only that which is
impossible to detect with the human eye.  Images worked on by GIFLITE
are still viewable, and I couldn't really tell the difference (though
the files were certainly different.)  I'm not sure how well these two
programs would work in concert, though I suspect there would be fairly
improved savings.

>Rick

-- 
Till next time,                \o/   \o/
                                V \o/ V     email:pinky@tamu.edu
<>  Sam  Inala  <>                 V

Newsgroups: comp.compression
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: Re: ARJ password cracker.
Organization: DSG, Stanford University, CA 94305, USA
Date: Tue, 17 Nov 92 00:44:14 GMT

In article <1992Nov16.141357.4098@memstvx1.memst.edu> ujacampbe@memstvx1.memst.edu (James Campbell) writes:
>In article <3327@accucx.cc.ruu.nl>, 
>>          ...Unfortunately most common ones are crackable (WP, PKZIP, ARJ).
>> I know of WP and PKZIP crack programs but unfortunately not of ARJ crack
>> programs. ARJ encryption is very weak but nooane seems to have made a tool 
>> for it.
>
>Why is ARJ's encryption "weak?"  Also, where did you see a crack program for
>PKZIP?  All I've seen has been a couple of brute-force pass phrase checkers.

With ARJ encryption the password is simply XORed onto the data stream, which
definitely qualifies as a "weak" algorithm.  A while ago I had a couple ARJ
files I wanted to crack, and tried writing a program to crack ARJ files in
general, but found that it was difficult to find enough redundancy in the 
compressed data stream to find passwords automatically.  I ended up doing
the same thing manually, and found the passwords with a few hours work.

The only program that I know of that can mount any sort of an effective
attack on PKZIP encryption is zipcrack, which I wrote about six months
ago.  Although it does a brute-force attack, it is fast enough that most
passwords can be found quite quickly.  (My '386-33 can test 100,000 passwords
per second.)  To my knowledge, the algorithm has not been cracked, but I also
have not heard of any real attempts to cryptanalyze the algorithm.

-- Paul Kocher

________Paul C. Kocher, Box 13554, Stanford, CA 94309, 415/497-6589_________
kocherp@leland.stanford.edu (preferred), root@kocher.stanford.edu.  Contract
programming work sought (PC assembly, security, etc) -- write/call for info.

Newsgroups: comp.compression
From: roe2@ellis.uchicago.edu (Cave Newt)
Subject: Re: InfoZip
Reply-To: roe2@midway.uchicago.edu
Organization: University of Chicago
Date: Sat, 21 Nov 1992 19:21:21 GMT

cuffell@spot.Colorado.EDU (CUFFELL TIMOTHY MICH) writes:

>>I just grabbed the InfoZip zip and unzip, and they work great for my Unix
>>account.  I noticed they had makefiles for various DOS compilers.  Is there
>>any compelling reason why I should use InfoZip rather than Pkzip?  

nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

>It is free and does have less bugs. Files which make PKZIP 1.10 fail for
>example don't make InfoZIP (PKZIP 1.10 compatible version) fail. No bugs
>with InfoZIP integrity are known (to me at least) and there are some
>in PKZIP 1.10 and PKZIP 1.93a (and of cource a lot in older PKZIP
>releases, especially PKZIP 1.01).
>
>Also the people making it are nicer :-)

Aw, gosh (warm fuzzies flooding the room, making it hard to breathe...)

There are a couple of other reasons, too:  both Zip and UnZip provide
means to translate EOLs (LF <--> CR/LF, etc.) between various operating
systems; there is no PKUNZIP capable of decrypting the new encryption
headers used by Zip 1.9 (well, unless PKZIP 2 was just released this
week at Comdex...); you don't have to remember some option to extract
subdirectory trees directly; you can use regular expressions in picking
which files to unzip; etc.  PKUNZIP, on the other hand, allows wildcard
zipfiles (coming soon in UnZip, but not yet there...) and is faster 
under MS-DOS (not by much under OS/2 2.0, however, but it can only do
non-deflated zipfiles).

Greg Roelofs
Info-ZIP guy
Newsgroups: comp.compression
From: eduard@htsa.aha.nl (Eduard Beijnes)
Subject: Re: compressor writing uuencoded files
Date: Fri, 20 Nov 1992 15:20:45 GMT
Organization: Algemene Hogeschool Amsterdam, Polytechnic Institute

I learned from the example you gave but..

it was not exactly wat I meant.

If you want to send a file which is bigger as 64k they say it will not 
work everywhere so people split it.
Something i would like is a program capable of

compress file | uuencode <file.Z > file.Z.uue | split file.Z.uue.spl
(with split I mean a program which splits file.uue in several chunks)

then someone reads news (or gets a email message with a program )

you should be able to:
read article (1 of 5) - save article as carbage.spl
read part 3 of 5 - save article as carbage.spl (appended)
read part 2 of 5 - save article as carbage.spl (appended)
read part 4 of 5 - save article as carbage.spl (appended again)
read part 5 of 5 - save article as carbage.spl (append)

then type:
mv carbage.spl file.spl.Z.uue (original name)
unsplit file.Z.uue.spl|uudecode file.Z.uue|decompress file.Z

(unsplit finds out him/herself out which order the carbage is.
and resort it.

another example:

garbo.uwasa.fi sends a file back to you (after you're request)
which is a bit messy (it contains several chunks :

mail part 35 of 100 
begin bigfile part 35 of 100
....
end of part 35 of 100

begin bigfile 1 of 100
....
end of part 1 of 100

etc....

It would be nice if you can type:

unsplit mboxfile|uudecode|decompress
rm mboxfile
and use the file(s) you asked

(BTW thanks for you're reply)
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: uuencode/decode & ".Z" compress.decompress files for MS-DOS
Organization: University of Vaasa, Finland
Date: Mon, 16 Nov 1992 09:13:04 GMT

In article <1e7bv8INNdnm@usenet.INS.CWRU.Edu> ck060@cleveland.Freenet.Edu (Eric L. Hinson) writes:
>I have an MS-DOS machine, and am looking for the .exe or .com files
>nessisary to uuencode/decode and compress/decompress using the ".Z" type of
>compression found on unix based ftp machines.

Covered in the Frequently Asked Questions, both the general
 115799 Sep 20 08:35 garbo.uwasa.fi:/pc/ts/tsfaq30.zip
and this newsgroup's newly released
  46460 Oct 30 14:35 garbo.uwasa.fi:/pc/doc-net/faqc9211.zip
For common, useful files, you can also see
  21795 Oct 24 00:58 garbo.uwasa.fi:/pc/filelist/useful19.zip

>Could someone who has these files please e-mail them to me uuencoded?  I

Why not use a mail server, if you supposedly do not have FTP?

"If you do not know how to go about getting this material, users are
welcome to email me for the prerecorded garbo.uwasa.fi instructions
(long, circa 29Kb).  North American users are referred to the Garbo
mirror on wuarchive.wustl.edu.  Australian users are referred to the
archie.au mirror.  For the Asian users there is the NCTUCCCA.edu.tw
mirror.  The mirrors may lag occasionally, or might not have all the
files.  If you do not receive my reply within five days, please ask
your own site's system manager to construct a returnable mail path
for you". 

..................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland
From: oien@tele.unit.no (Geir Oien-dr.ing student)
Newsgroups: comp.compression
Subject: References on fractal compression
Date: 17 Nov 92 08:19:08 GMT
Organization: Norwegian Institute of Technology

I am looking for recent references on the subject of fractal compression of images
(grey tone and color) to use in work on my Ph. D. thesis. Any conference papers,
journal articles, books, book chapters, preprints etc. written during the last
couple of years would be of interest. Please feel free to e-mail or write me directly.
Thanks!

		Geir E. Oien
		The Norwegian Institute of Technology
		Department of Telecommunications
		7034 Trondheim - Norway
		e-mail: oien@tele.unit.no
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: Unzip50 bug??
Date: 16 Nov 1992 22:12:48 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


Yes, I would call that an Unzip 5.0 bug.  Currently unzip does not
stop when it exceeds the uncompressed byte count--it assumes that
the input data is good, and that it will get an end-of-block marker
in the compressed data.  This is only true for the deflate method,
since the other methods don't have end-markers, they depend on the
counts (compressed or uncompressed) to stop.

This was partly a speed trade-off, and partly laziness.  I will look
into putting checks for compressed and uncompressed sizes.

This will always be a problem for funzip, since a filter generated
zip file doesn't have the sizes at the start, since they are not
known at the start.  funzip will continue to depend on the markers
in the compressed stream.

Mark Adler
madler@cco.caltech.edu
Newsgroups: comp.compression
From: bill@sees.bangor.ac.uk (Bill Denton (AD))
Subject: Re: Lossless Datacompression Source kit 1.0
Organization: University of Wales (Bangor)
Date: Mon, 16 Nov 1992 18:14:07 GMT

The following was posted sometime a while ago by nevries@accucx.cc.ruu.nl (Nico E de Vries)

>Hi,
>
>I made version 1 of the LDS (lossless datacompression sources) kit.
>I noticed lots of people want sources for datacompressors and it
>can be hard to get them. Especially good ones. I have spend a fortune
>on collecting compression sources (I need them for an archiver I
>am working on) and decided to create a package containing the ones
>I think are most wanted and interesting.
>
>The kit includes AR002 (comparable with ARJ 2.39, LHA, ZOO 2.11,
>PKZIP 1.93a, ZIP 1.9), LZW, Huffman, Splaytree's, Ashford, LZHUF,
>LZSS, LZARI, ARI, higher order ARI, LZRW1, etc. Most sources work
>with MS-DOS, UNIX etc. I included make files for Borland C++. 
>
>I uploaded the file LDS_10.ZIP (PKZIP 1.10 format) to garbo.uwasa.fi  
>
>Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
>_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
>| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
>| text is likely to contain spelling and grammar errors. |  A  A   I   P
>*---------------------------( Donate to GreenPeace! )----*  A  A  III  P
>
>"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.

Where is this package? I can not find it on garbo.uwasa.fi or src.doc.ic.ac.uk
(SIMTEL20 mirror).

Bill Denton
bill@uk.ac.bangor.sees
Newsgroups: comp.compression
Subject: Re: Pkzip 2.0 in the 23'rd century?
From: cs272017@eeyore.stcloud.msus.edu (cs272 user 017)
Date: 16 Nov 92 23:53:27 -0600
Organization: St. Cloud State Univ., MN

> SK>PKWare has stated (maybe this is *the* time) that PKZip 2.x will be
> SK>released at the end of November, and that it is in final beta.
>
> Sure, but which year?   (Sorry :-)
 
Quite all right :).  I feel that way, too.  The above message was 
just something that appeared recently on PKWare's BBS.
 
Scott
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: non-dictionary, non-statistical compression
Keywords: DMC PPM compression context state
Date: 23 Nov 92 17:36:21 GMT
Organization: Academic Computer Centre Utrecht

In <10003@blue.cis.pitt.edu.UUCP> mchst12@cislabs.pitt.edu (Mark    C Hahn) writes:

>We seem to have lots of sources available for various versions of
>LZ-derived dictionary methods, and some statistical ones using
>Huffman coding, arithmetic, etc.  Does anyone know of sources 
>some of the other techniques described in Cleary,Witten&Bell?

In a way almost all compression routines are derivates of the
"dynamic markov modeller". LZ compression and Huffman, Arithmetic
compressions are just subsets of this. Others include higher
order methods which are statistic, just like Huffman and
Arithmetic compressors, but use more info from the past
to predict the next character. A nice example of a compressor
which doesn't look like LZ, Huffman and Arithmetic compression
is the Finish compressor in my LDS_10 package. It is however
also member of the Markov family. 

>thanks, Mark.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at 
garbo.uwasa.fi /pc/programming. Make files for Borland C are included.
From: dieperin@masg35.epfl.ch (Alwin Dieperink)
Newsgroups: comp.compression
Subject: TMSFax experiences ?
Date: 16 Nov 92 12:58:15 GMT
Organization: Ecole Polytechnique Federale de Lausanne

Hi everyone !

Has anyone had some experience with TMSFax (for Windows and/or Macintosh) ?
Any information would be helpful.

-- Alwin Dieperink

dieperin@dma.epfl.ch

Newsgroups: comp.compression.research
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: C source for Fractal compression, huh !
Organization: Metaflow Technologies Inc.
Date: Tue, 17 Nov 1992 01:34:13 GMT

In article <1992Nov16.184754.3170@maths.tcd.ie>, tim@maths.tcd.ie (Timothy Murphy) writes:
|> Doesn't Information Theory set a limit
|> on the degree of compression (of given data) possible?
|> If you go beyond this limit
|> do you not necessarily lose information?

The short answer is:  No, information theory does not set an absolute
limit on maximum compression.  It does set bounds on compression in
a particular context, though.  I strongly recommend reading the excellent
FAQ in comp.compression.  If the FAQ doesn't satisfy your curiosity, the
references it gives will.
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.compression.research
From: md85-epi@hemul.nada.kth.se (Urban Koistinen)
Subject: Re: arithmetic coding
Keywords: when does it work ?
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Mon, 16 Nov 1992 11:27:26 GMT

In article <Nov.15.22.54.42.1992.14006@pepper.rutgers.edu> phalke@pepper.rutgers.edu (V. Phalke) writes:
  Supposing SIGMA = { 0, 1}
  If the probability P(0) is very high and P(1) is close to ZERO arithmetic
  coding doesn't seem to work !! 
  I mean supposing the string is pure ZEROES then arithmetic coding interval
  will decrease very slowly. This would result in a very long encoding. On
  the other hand the entropy of this data is very low!!
  Any help ??

If the interval doesn't decrease much, few bits need to be sent
giving good compression.
Many bits in, few bits out.
  
  phalke@paul.rutgers.edu         (908) 878-1602(h)       (908) 932-4635(o)

The great thing about arithmetic coding is that if you know how to
calculate the probabilities for the next character, you get a code
that is very near optimum.
The bandwith wasted by the encoding scheme is only about exp(-N*log(2))
per bit encoded.
(N is the number of bits used by the coder)

This mean, the quality of compression depend only on the statistical
model.

-- 
Urban Koistinen - md85-epi@nada.kth.se
Newsgroups: comp.compression.research
From: radford@cs.toronto.edu (Radford Neal)
Subject: Re: C source for Fractal compression, huh !
Organization: Department of Computer Science, University of Toronto
Date: 21 Nov 92 19:29:40 GMT

In article <1992Nov21.151212.20315@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:

>>Chaitin/Kolmogorov Algorithmic Information Theory does not give such
>>a limit, for the very reason you note - it depends on a particular 
>>choice of universal Turing machine.

>This is a complete red herring.
>All right, let us agree to take the universal machine
>defined in
>
>@book{davis73
>author = " Davis, M.",
>title = "Computability and unsolvability",
>publisher = "Dover",
>year = 1973,
>isbn = 0486614719
>}


Go right ahead and adopt this Turing machine for all your computing
needs if it makes you happy, but I suspect you'll find it a bit slow
and awkward, as well as difficult to get good repair service for.

As for myself, I'm happy to use whatever machine seems convenient at
the time. In particular, if I'm interested in storing images compactly
for later display, I'm happy to use a "machine" that is carefully
tailored so that there are short "programs" that produce images that
crop up a lot, at the expense of long "programs" for images that don't
occur very often.

What is it about data compression that induces so much confusion in
the layperson? Half of them seem to think it plausible that one
could compress any data set into practically nothing without any
knowledge of the source probabilities, while the other half think 
that knowledge of the source is irrelevant in light of mythical
"theoretical limits" . . .

     Radford Neal
Newsgroups: comp.compression.research
From: tim@maths.tcd.ie (Timothy Murphy)
Subject: Re: C source for Fractal compression, huh !
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Date: Mon, 16 Nov 1992 18:47:54 GMT

michael@pullet.lanl.gov (Michael I Angerman) writes:

>	for some very well defined, small finite set, fractal
>compression may work ok, but the general problem is far from there.


May an innocent ask a couple of questions.

Doesn't Information Theory set a limit
on the degree of compression (of given data) possible?
If you go beyond this limit
do you not necessarily lose information?

Is this view accepted by the fractal compression salesmen?
Do they perhaps accept that information is lost,
but claim that it is second-rate information?


-- 
Timothy Murphy  
e-mail: tim@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
From: z_youngwd@ccsvax.sfasu.edu
Newsgroups: comp.compression.research
Subject: exit
Date: 19 Nov 92 20:28:55 CST
Organization: Stephen F. Austin State University
Summary: FRACTAL COMPRESSION 


I have posted an updated version of my work on the problem of 
fractal image compression.

I have posted the files to lyapunov.ucsd.edu.
They are temporarily in pub/incoming (or pub/uploads .. i can't recall)
but should be in /pub/young-fractal in the file unifs10.zip

Source for compression and decompression is included.
Also, X-windows source for decompression is included.

Executables for compression, decompression, file conversion are (of course)
included.

The ".ifs" files are not compatible with past versions.

Thanks

Wayne Young
From: tim@maths.tcd.ie (Timothy Murphy)
Newsgroups: comp.compression.research
Subject: Re: C source for Fractal compression, huh !
Date: 18 Nov 92 02:49:12 GMT
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.

rschnapp@metaflow.com (Russ Schnapp) writes:

>The short answer is:  No, information theory does not set an absolute
>limit on maximum compression.  It does set bounds on compression in
>a particular context, though.

I don't know what this means.
As I understand it,
Chaitin/Kolmogorov Algorithmic Information Theory
does set an absolute limit to the degree to which
any given data can be compressed:
the string s cannot be compressed 
beyond its entropy (or informational content) H(s).
H(s) is precisely defined,
subject only to the choice of a particular universal Turing machine.
(This last proviso would not have any effect in practice.)

Although I must admit that I haven't looked into it carefully,
I've read explanations of Barnsley's "fractal compression",
and remain completely unconvinced.
Nothing in the comp.compression FAQ,
which I read at your suggestion,
changed my mind.

-- 
Timothy Murphy  
e-mail: tim@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Newsgroups: comp.compression.research
From: a.triulzi@imperial.ac.uk (Arrigo G.B. Triulzi)
Subject: Fractal compression source
Organization: Imperial College Mathematics Department
Date: Wed, 18 Nov 92 09:42:00 GMT

Regarding my posting on the Iterated Systems demo disk I have received vast
amounts of mail. Unfortunately the demo is NOT public domain, there is a
licence on the diskette envelope. I cannot, therefore, provide the source via
uuencode to anyone. I am sure, though, that if you contacted I.S. they would
probably be able to send you a copy of the demo disk free of charge.

	Arrigo

-- 
Arrigo G.B. Triulzi (a.triulzi@imperial.ac.uk) - PGP 2.0 sig. available
Mathematics Dept. - Imperial College of Science and Tech., London - UK
Newsgroups: comp.compression.research
From: stud05@cc4.kuleuven.ac.be (Ton Hospel)
Distribution: world
Date: Tuesday, 17 Nov 1992 12:55:21 +01
Organization: K.U.Leuven - Academic Computing Center
Subject: Re: compress for VM host wanted

In article <JT.92NOV12180224@FIZYK1.FUW.EDU.PL>, jt@fuw.edu.pl writes:
> Does anyone know where to get source of unix-compress-compatible
> program which can be compiled and used on mainframe IBM ?
> I tried compile the unix compress source - and get several screens
> of error messages. And I don't have the VM C compiler docs here,
> since I don't know what are differences between VM and standard C
> and cannot fix these errors myself.
> Thanks in advance for any reply, if possible by mail, too.
> (I don't read NetNews frequently and may miss reply in NN)

You will find compress (and zoo) for VM on LISTSERV@BLEKUL11 in the
C-CHEST filelist.


                                                          Ton

Ps: You will find VM versions of several interesting UNIX utilities there.
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression.research
Subject: Re: C source for Fractal compression, huh !
Date: 16 Nov 1992 22:10:07 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


>> Is this view accepted by the fractal compression salesmen?

This view, i.e. accepting lossy compression, is accepted by the
customers in the field of image and video compression.  And what
the customers accept is what's important, not what the salesman
accept.

However, the customers are very particular about the sort of
lossiness they get, and how that compares to the compression ratio.
They need to see lots of examples, not just a few, and they are
generally rather experienced in subjectively evaluating compressed
images and video.

Mark Adler
madler@cco.caltech.edu