HDTenEightyP/NetNews huggingface dataset:
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Info wanted about PKLITE 1.12
Date: 27 Dec 92 12:53:26 GMT
Organization: Academic Computer Centre Utrecht

In <92361.114137SXK129@psuvm.psu.edu> SXK129@psuvm.psu.edu (Spaceman Spiff) writes:

>Is PKLITE 1.12 an authorized version? I heard that there was a PKLITE trojan
>which was uploaded at several sites which corrupts .exe and .com files.

It can be someone made a cracked version of PKLite 1.12 but there is a real
1.12 which has been released by PKWARE.

>thanx,
>sunil

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. 
Newsgroups: comp.compression
From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
Subject: Re: encryption with pi
Organization: MIND LINK! - British Columbia, Canada
Date: Tue, 29 Dec 1992 05:49:21 GMT

Oops, that one slipped out without a :-). Sorry, too fast on the SEND
when I mean CANCEL ... :-).

--
Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
                 or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
*-*-*-*-*-*-*-*-*-*-*
Engineers think equations are an approximation of reality.
Physicists think reality is an approximation of the equations.
Mathematicians never make the connection.
Newsgroups: comp.compression.research
From: revtek@world.std.com (Jacques A Vanschouwen)
Subject: PowerDrive available for Sun workstations
Organization: The World Public Access UNIX, Brookline, MA
Distribution: all
Date: Mon, 4 Jan 1993 00:15:08 GMT


Revolution Technologies First To Unveil Transparent Low Cost
Disk Compression Software For SPARCr Workstation Users.

NATICK, Mass. -- January 4, 1993 -- Revolution Technologies (tm) today
introduced PowerDriveTM, a software product designed to transparently
increase the file storage capacity of SPARC workstations and servers.
With PowerDrive, users can store more files and applications at much
lower cost than purchasing additional disk drives.

+ DOUBLES DISK DRIVE STORAGE CAPACITY 

The PowerDrive product is intended for users who want to store additional
applications and files on their workstations than would typically fit.
With PowerDrive, files are compressed to 50% of their original size on
average. This significant reduction virtually doubles the drive's storage
capacity.

+ EASY INSTALLATION IN MINUTES

The PowerDrive software installs in minutes and allows the user to
immediately take advantage of the additional disk space. During
PowerDrive installation, existing files on the system are compressed
into the PowerDrive format -- making more room to store new files.
When a file bearing the PowerDrive format is accessed, it is
transparently decompressed for use by the user.  The PowerDrive
software is fully configurable and works easily with all file types
including text files, object files, and executables.

+ IMMEDIATE AVAILABILITY

PowerDrive is available now for the Solaris 1.0 (SunOS 4.1.x) operating
system.  A version for Solaris 2.x will be available in March, 1993.
Revolution Technologies is offering a special introductory price of $99
until March 31, 1993. PowerDrive is available via anonymous FTP at
world.std.COM (192.74.137.5) in the directory pub/revtek.  Download
files powerdrive.tar and powerdrive.README.

PowerDrive can also be ordered by calling Revolution Technologies at
(508) 650-1490 or by sending a FAX request to (508) 655-8860.

Users can try out PowerDrive at no cost for 30 days by obtaining a demo
license from Revolution Technologies.

Revolution Technologies and PowerDrive are trademarks of Revolution
Technologies.  SPARC is a registered trademark of SPARC International, Inc.
From: rpawluc@ino.qc.ca (Rafal Pawluczyk,243,x363)
Newsgroups: comp.compression.research
Subject: Info on Fractal Transforms
Keywords: Fractal Transform, IFS
Date: 31 Dec 92 02:14:10 GMT
Reply-To: rpawluc@ino.qc.ca
Organization: National Optics Institute, (Quebec), Canada

Hi there!!!
I am new to the usenet world, so maybe someone can give me some pointers. I have spotted some articles and replies about fractal compression several days ago, but when I tried to read them my news reader ( 'nn' ) gave 'cancelled or expired' messages. Can
anyone tell me where this group is archived? Or if not, how would anyone go about finding where it is archived?  Thanks in advance.  

P.S. I am aware that this is probably not the best place to post this message, but I would like to read these messages ASAP, and do not want to wait until I figure out the whole usenet. If it causes any inconvenience, please yell. Thanks again
rafal pawluczyk
national optics institute
Newsgroups: comp.compression
From: franti@polaris.utu.fi (Pasi Fr{nti)
Subject: Any sources on Vector Quantization available?
Summary: Info needed, AGAIN! :-)
Keywords: VQ, PCX
Organization: University of Turku, Finland
Date: Wed, 30 Dec 92 10:46:42 GMT

We are about to implement some form of Vector Quantization for
reserach purposes. Before doing this I'm asking if there is any
Pascal- or C-sources available of VQ?

Also I'm looking for some specifications of PCX-format. I have
routines that can read and write version 2 and 3 PCX Run Length 
format (b&w-images only). However, now I have an image that my 
routines can't read properly, and that image is in version 5.

Newsgroups: comp.compression,alt.security.pgp
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Possible HPACK x PGP screwup
Keywords: beware, becareful, behappy, merry christmas
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 21 Dec 92 10:47:22 GMT

gmribeir@david.wheaton.edu (Glauber) writes:

> This is the scoop: PGP secret keys need to be converted
> before they may be used by hpack. Gutmann says he has to add
> some material to the key because of copyright problems, or
> something like this. I did the conversion, and HPACK is
> working fine with the converted key, but now PGP DOESN'T
> WORK ANYMORE! :-( :-( :-(


Hmmm... Very strange... I used KEYCVT too and both PGP (2.0 and 2.1)
and HPACK work without problems for me... I really don't understand
what has happened in your case...

> Any help on this topic is appreciated. Note that
> theoretically something else may have corrupted my key, but
> i really can't think of any possibility. Besides, HPACK
> works nice and fine (but PGP doesn't) so it really looks
> like KEYCVT was the bad guy here.

In fact, KEYCVT adds a new packet to your secret keyring. PGP uses the
first (the original) packet and HPACK uses the additional one. Either
of them can become corrupted. This will disable one of the programs,
but not both. It seems that in your case the first packet is
corrupted...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
From: cadams@hpspdla.spd.HP.COM (Chris Adams)
Date: Tue, 22 Dec 1992 05:22:30 GMT
Subject: Re: What Happened to MIT's Subband HDTV Scheme?
Organization: HP Stanford Park - Palo Alto, CA
Newsgroups: comp.compression

/ hpspdla:comp.compression / steve_krause@qm.sri.com (Steve Krause) /  6:44 pm  Dec 19, 1992 /
I've got a copy of the original MIT HDTV proposal to the FCC (dated
February 1991), which clearly lays out the intraframe coding as subband
coding. However, in the latest IEEE Micro ("Digital Video Coding Techniques
for U.S. High-Definition TV"), it has the now renamed MIT/GI system using a
DCT. The reference to the system is from an April 1992 document, so I
assume that somewhere between 2/91 and 4/92, MIT decided that the earlier
system with subband coding wasn't going to work out. Is this what happened?
Does anyone know why? Finally, is the current compression method in the
MIT/GI Channel Compatible DigiCipher MIT's or GI's?

----------
MIT did not have the necessary money to fund the prototyping and FCC
testing of their system.  MIT's test slot at the ATTC (Advanced
Television Test Center) was considered valuable since it was the last
one.  General Instruments more or less bought the test slot from MIT.
The CCDC (Channel Compatible DigiCipher) is a merging of both GI and MIT
technology.  One of the biggest differences between the DC and CCDC is
that DC (DigiCipher) is interlace scan and CCDC is progressive scan.  At
the time that GI bought MIT's test slot progressive vs. interlace was
one of the biggest issues of contention.  GI hedged their bet by
proposing one system of each type.  Major algorithm improvements of the CCDC vs. DC are adaptive motion block size and vector coded DCT coeffecient selection.

Chris Adams
Hewlett Packard
cadams@spd.hp.com
From: dannyb@panix.com (Daniel Burstein)
Newsgroups: comp.compression
Subject: new pkzip -almost- ready
Date: 3 Jan 93 00:00:52 GMT
Organization: Panix, NYC

per the notice on the PKWARE BBS (1-414-354-8670) on Jan 2nd, 1993, 
  
  The NEW PKZIP will be shipping Jan 5th, 1993.

So, all of us who've been holding our breaths can now relax.

dannyb@panix.com
From: ericb@hplsla.hp.com (Eric Backus)
Date: Tue, 22 Dec 1992 23:39:49 GMT
Subject: Re: Widespread bug in "compress" and GIF compressors
Organization: HP Lake Stevens, WA
Newsgroups: comp.compression

Tom Lane writes:
>I've discovered a small bug in the standard Unix compress(1) utility.
>The bug is also present in many derived implementations of LZW compression,
>notably common GIF graphics file writers such as ppmtogif and xv.
>
>The bug does NOT pose any risk of loss of data.  What it does do is to cause
>inefficient compression of some files containing many runs of zero
>characters (nulls).

Wow, thanks!  Who'd have thought there was a bug there.  Note that
cpio and tar tend to put out strings of null bytes, to pad out
archives to a multiple of the blocksize, so this could help a little
when compressing those archives.
--
					Eric Backus
					ericb@lsid.hp.com
From: tim@maths.tcd.ie (Timothy Murphy)
Newsgroups: comp.compression
Subject: Re: New PKZIP expected to ship week of Jan 4 1993
Date: 24 Dec 92 13:20:47 GMT
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.

afc@klaatu.cc.purdue.edu (Greg Flint) writes:

>I just logged off the PKWARE BBS where I read a message dated 23 Dec 92
>that repeated that the new PKZIP was in final beta, but then added that
>PKWARE expected to start shipping the week of 4 Jan 93.  

Are PKZIP/PKUNZIP compatible with ZIP/UNZIP?
Why do we have all these compression programs?
In my experience the difference between them is marginal.
The trouble caused by the multiplicity of programs
vastly outweighs -- IMHO - any advantage gained
by minuscule improvements in compression.

Please don't produce any more programs!
There is absolutely no need for them.

Happy Xmas (XCOMPRESSED Christmas) ...


-- 
Timothy Murphy  
e-mail: tim@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: New PKZIP expected to ship week of Jan 4 1993
Date: 29 Dec 92 19:31:49 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <725364826rommel.root@jonas.gold.sub.org>, rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:

| Go ahead and use compress for the rest of your lifetime. Nobody will
| disturb you. But beware, FSF is about to introduce a compress
| replacement for the GNU system - it uses the zip 1.9 compression
| engine ... it may or may not become a standard for other Unix systems
| as well, we will see.

  As long as they don't call it compress, they can introduce anything
which pleases them. What we *don't* need is an incompatible program
which has the same name.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.compression
From: GUEST@SCC-TERM1 (Guest)
Subject: What's the differents between PKZIP & UNZIP ?
Keywords: pkzip
Organization: Natinal Centeral University Computer Center, Taiwan, R.O.C
Date: Tue, 22 Dec 1992 11:25:04 GMT


Hi all !
 Anyone please tell me what's the differents between PKZIP & UNZIP.
                                    
                                                Carlos Shyu

                                         E-mail : u224267@twncu865.ncu.edu.tw
From: cyberman@exucom.com (Stephen R. Phillips)
Newsgroups: comp.compression
Subject: Re: Pkzip 2.x on genie
Date: 25 Dec 92 02:04:05 GMT
Organization: ExuCom Multimedia Inc.
X-Newsreader: TIN [version 1.1 PL7]


Thanatos (io@expert.cc.purdue.edu) wrote:
: 
: Some peole have told me there is a copy of Pkzip 2.x avaliable on the genie
: service.  SI this a true version from them or is it yet anothe test version of
: the 2.x materials.  I was told it is a release from Pklabs, and that it will un
: compress 1.1 files, so maybe it is?

Until Pkware anounces it DON'T touch it.
It is a good way to get burned.

Cyberman
--
This is my sig file!
Read rec.games.programer!

Cyberman/Stephe
From: rommel@jonas.gold.sub.org (Kai Uwe Rommel)
Newsgroups: comp.compression
Subject: Re: New PKZIP expected to ship week of Jan 4 1993
Distribution: world
Date: Sat, 26 Dec 92 11:13:46 MET
Organization: Private

In article <1992Dec26.041734.18508@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:
>
>>In article <1992Dec24.132047.9908@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>>>Why do we have all these compression programs?
>
>>For *you* there may be no need. If you are one of those "happy" DOS
>>users who think DOS is all and everything, you may be right.
>
>Actually, I hardly ever use MS-DOS.
>I'm a Unix/Minix/MacOS user.
>As far back as I can remember, compress/uncompress
>(producing .Z files)
>has been the universal standard under Unix.
>This has worked perfectly well;
>I never heard anyone complaining.
>I've no doubt compression could be improved by 1-2%
>by some complicated maneouvre.
>But who cares?

I care. Take any sample comp.sources.misc/unix posting of, say, 250k.
Compress it with compress and zip 1.9. The version compressed by zip
will be about 35% less in size than that compressed with compress.

>Cars would probably go faster if the wheels were larger,
>or else smaller.
>Trains would run more efficiently
>if the gauge was slightly increased, or perhaps decreased.
>Of course you would have to change trains
>every time you went from one system to another.
>But that minor inconvenience would be well worth it.

Why don't you still use your CP/M or MP/M 64k Z80 computer? It worked
perfectly well. Shame on you that you have switched. :-)

>>And, don't forget, if there were no people who wrote *new*
>>compressors, we would still be stuck with ARC or compress only and
>>their inferior compression rate.
>
>You're making me weep.
>You mean I wouldn't have to spend hours
>looking for the latest version of UNZIP?
>Instead I'd have to spend 50 cents on another floppy.

Go ahead and use compress for the rest of your lifetime. Nobody will
disturb you. But beware, FSF is about to introduce a compress
replacement for the GNU system - it uses the zip 1.9 compression
engine ... it may or may not become a standard for other Unix systems
as well, we will see.

>99% of the hype about new compression algorithms
>is unscientific waffle.
>Their perpetrators should be publicly flogged on prime-time TV.

Apparenty you are not worth another article. I'll stop with this.

Kai Uwe Rommel
Info-ZIP

--
/* Kai Uwe Rommel                                      Muenchen, Germany *
 * rommel@jonas.gold.sub.org                       Phone +49 89 723 4101 *
 * rommel@informatik.tu-muenchen.de                  Fax +49 89 723 7889 */

DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be.                -Russell Williams
Xref: sparky comp.compression:4281 comp.ai.philosophy:7183
From: markh@csd4.csd.uwm.edu (Mark)
Newsgroups: comp.compression,comp.ai.philosophy
Subject: God's Compression (was: Re: Compressing decimal expansion of pi...)
Date: 31 Dec 1992 19:31:29 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.7.4

In article <C03vCz.78v@iat.holonet.net> ken@iat.holonet.net (Ken Easlon) writes:
>>.. the task of creating an intelligent machine may be nothing more than
>>creating a universal data compressor.
>
>If the sole function of intelligence were to answer questions, I would
>agree.  However, I think intelligence requires not only answering
>questions, but ultimately doing something with the answers, like surviving,
>growing, evolving, etc.

If survival is a function of intelligence then I can pose the question
"how do I survive" as the one being answered.

Back to compression: since the number of things that will ever be uttered
or displayed is less then 2^256, there exists a finite (and this, computeable)
function that maps every object one-to-one to 256-bit numbers.

Since the function is finite and one-to-one, its inverse is also a finite,
one-to-one function, and thus computeable.

In this way, an algorithm is proven to exist that will compress everything
that has or will ever exist to 256 bits.
Newsgroups: comp.compression
From: io@expert.cc.purdue.edu (Thanatos)
Subject: Pkzip 2.x on genie
Organization: Purdue University Computing Center
Date: Wed, 23 Dec 1992 15:48:24 GMT


Some peole have told me there is a copy of Pkzip 2.x avaliable on the genie
service.  SI this a true version from them or is it yet anothe test version of
the 2.x materials.  I was told it is a release from Pklabs, and that it will un
compress 1.1 files, so maybe it is?
Newsgroups: comp.compression
From: pcarmack@gimp.kpc.com (Phil Carmack)
Subject: Anyone know where H.261 spec really is?
Organization: Kubota Pacific Computer
Date: Mon, 28 Dec 1992 20:15:35 GMT


The FAQ for this group says that H.261 spec is found on src.doc.ic.ac.uk 
in /doc/ccitt-standards/ccitt/1992/h/h261.doc.Z, but I am unable to find
the directory /doc/ccitt-standards on that machine.  Does anyone know 
where it really is?  Or does anyone know of another machine where the spec
can be found?  Please send me e-mail if you know the answer.

Thanks in advance,

Phil

-- 
Philip Carmack				| pcarmack@kpc.com	(408)987-3336
Kubota Pacific Computers, Inc.		|
Newsgroups: comp.compression,comp.dcom.fax,comp.graphics
From: dave@pipi.iis.u-tokyo.ac.jp (David Wuertele)
Subject: What is the IEEE CICC?
Organization: Institute of Industrial Science, University of tokyo.
Distribution: comp
Date: Sun, 3 Jan 1993 21:44:36 GMT

A litle while ago tgl+@cs.cmu.edu (Tom Lane) posted excerpts from an
article called "Video Compression Options," by J. Boomer, et al., in the
6-May-92 edition of the IEEE CICC.

What is CICC?  Is this article something that is put out periodically?  Or
was it just a one time review?

What I'm really looking for is a sort of "Thomas's Guide for compression
hardware.

Dave
-----
David Wuertele, Yasuda Lab, Electronic Engineering, Institute of Industrial Science,
University of Tokyo.				dave@windsor.iis.u-tokyo.ac.jp
From: teodor@proxxi.uf.se (Teodor V{{n{nen (proxxi))
Newsgroups: comp.compression
Subject: J/MPEG Chips question...
Summary: A question about J/MPEG Chips.
Keywords: MPEG,JPEG,chips,question
Date: 22 Dec 92 04:13:08 GMT
Organization: proxxi


Hi there !
I bet this question has been asked before, and it might even be a FAQ,
but I always manage to miss the postings that has the info I need...

Is there anyone that has some kind of list of companies that makes and sells 
JPEG and MPEG compression/decompression chips? I'm building a computer on
my spare time, and I'm planning to use specific JPEG / MPEG compression
chips to take some load of the main processor(s), and ,of course, speed
the system up a little bit... By the way, if you happen to know about
any chips that perform non-lossy compression, you can throw in that info
as well, I'm certain that I'll need that info later on...

I got an answer from a person that had the info, but I managed to erase
his adress during my monthly disk-space cleanup... So if you're reading,
please mail me the list...

And, if there's any interest, I'll post a list with the information
to this group, so that others can have access to the information too.

By the way IS this a FAQ? If not, why not include a list of chip
manufacturers in the FAQ,
because I have seen this question bounce up several times on this group.

Teodor V. <teodor@proxxi.se>


-- 
Teodor Vaeaenaenen		E-Mail:    teodor@proxxi.uf.se
Voice: +46 8 6693241		SnailMail: Langholmsgatan 7  3rd floor
Data: Not Existing (Yet)        	   S-117 33 STOCKHOLM, SWEDEN
Murphys law: Everything that can f--k up f--ks up.
From: tim@maths.tcd.ie (Timothy Murphy)
Newsgroups: comp.compression
Subject: Re: New PKZIP expected to ship week of Jan 4 1993
Date: 26 Dec 92 15:23:57 GMT
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.

rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:

>Go ahead and use compress for the rest of your lifetime. Nobody will
>disturb you. But beware, FSF is about to introduce a compress
>replacement for the GNU system - it uses the zip 1.9 compression
>engine ... it may or may not become a standard for other Unix systems
>as well, we will see.

Mea culpa.  Mea culpa.  Mea culpa.
I'd like to issue a public apology to K-U Rommel, the Pope, et al.
My posting was made under the malign influence of Sinead O'Connor.

May a 1000 compressors flourish!

I have tested K-U's assertion, and he is RIGHT.

====================================================

Script started on Sat Dec 26 15:02:37 1992
salmon 17% zip -r ghostscript.zip /src/gnu/ghostscript-2.5
salmon 17% tar cvf - /src/gnu/ghostscript-2.5 | compress > ghostscript.tz
salmon 18% ls -ls *.tz
1200 -rw-r--r--  1 tim       1217329 Dec 26 15:13 ghostscript.tz
salmon 19% ls -ls *.zip
1016 -rw-r--r--  1 tim       1029762 Dec 26 15:04 ghostscript.zip
script done on Sat Dec 26 15:14:06 1992

====================================================

{\veryverysmall Sed movet}

-- 
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
From: dave@gctech.co.jp (Dave)
Subject: Re: J/MPEG Chips question...
Organization: GC Technology
Date: Sat, 2 Jan 1993 20:51:41 GMT

In article <34390002@hpspdla.spd.HP.COM> cadams@hpspdla.spd.HP.COM (Chris Adams) writes:
>  Companies in the JPEG/MPEG/Px64 chip business

>  C-Cube (San Jose,  CA)
>  Integrated Information Technology (Santa Clara)
>  LSI Logic (Milpitas)
>  AT&T
>  NEC (not sure if available yet)
>  SGS-Thompson
>  Zoran

If someone were interested in getting specs on any of these companies'
products, who would we mail to?

Does anyone have the mail/e-mail/fax contacts for any/all of these
companies?

Dave
----
David Wuertele, GC Technologies, Algorithm Research
dave@gctech.co.jp	dave@windsor.iis.u-tokyo.ac.jp
Newsgroups: comp.compression