HDTenEightyP/NetNews huggingface dataset:
From: ST29701@VM.CC.LATECH.EDU
Newsgroups: comp.compression
Subject: Re: Where to find PKZIP2.04c and an updated F-PROT?
Date: Wed, 20 Jan 93 23:40:37 CST
Organization: Louisiana Tech University
NNTP-Posting-Host: vm.cc.latech.edu

In article <s0319198.29.0@let.rug.nl>
s0319198@let.rug.nl (E.B. Meijerink) writes:
 
>
>
>To all,
>
 
>I recently downloaded the new PKZIP2.04c but it wasn't dated at 12-28-92 at
>2:04. Someone on this newsgroup said that this 12-28-92 version was the
>correct one, so I didn't use the version I downloaded (I mean, with all the
>discussion 'bout whether or not it was infected I didn't dare to). But (as
>we all know) the virusalarm was false so I tried to download it again, but
>unfortunatelly it was gone...
>
>So, my first question is: 'Could anyone mail me the FTP-adress of a
>'reliable' site to download PKZIP2.04c from? And question #2: 'Could you
>also mail me the FTP-adress of a reliable site from which I can download the
>newest versions of McAfee's virus-scan and of F-PROT?'
>
>Thanks in advance!
>
>Erik Meijerink             || 'Life was so much easier with
>University of Groningen    ||  a ZX SPECTRUM...............'
>Email: S0319198@let.rug.nl ||
>
 
McAfee's SCAN and other products can be found at their own internet site
mcafee.COM  /PUB/ANTIVIRUS  and /PUB/UTIL and by ANONYMOUS FTP.
they also have VSUM virus listing in /PUB/VSUM.
to write McAfee support@mcafee.com   or mcafee@netcom.com
 
I got my copy of F-PROT form FRISK's internet address complex.is /pub/
to write him is fristk@complex.is
From: bsmith@mickey.NoSubdomain.NoDomain (Brian Smith)
Newsgroups: comp.compression
Subject: Re: JPEG compression
Date: 25 Jan 1993 17:47:52 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: mickey.cs.berkeley.edu
Keywords: JPEG, compression

In article <peterb.727926960@wambenger>, peterb@cs.uwa.oz.au
(Peter Bousfield) writes:
|> Hello fellow compressors,
|> 
|> It is my understanding that JPEG compression
|> works in basically two parts.
|> Step 1: DCT (Discrete Cosine Transform)
|> and
|> Step 2: Huffman Coding (for those of us
|> 			who don't wish to
|> 			pay for a license.)
|> 
|> I was wanting to know which of these
|> two steps contributes more to the compression.
|> That is, how good is the compression without
|> Huffman coding (eg is it 50% worse or only 10%
|> worse.)

The DCT doesn't really do any compression, it just concentrates the
energy of the image into a few coefficients, so that the coefficients
near zero can be set to zero.

I ran some experiments a while ago to get the answer to precisely this
question.  Twenty five 640x480 images were used in the experiment, with
the default quantization tables suggested in Annex K of the JPEG standard.
After quantization, an average of 3-4 of the coefficients in a typical
8x8 block were non-zero (the mean was 3.52). One was almost always the
DC component. The rest were zero.

Now, after quantization, JPEG codes the DC term and run-length encodes
the AC terms as (run,value) pairs.  In other words, every non-zero term
gives rise to two integers (this is a bit simplified, but good enough).
This leads to 5-7 ints that describe an 8x8 block, for an overall
compression of about 10:1.  The values are clustered pretty well around
zero, so Huffman coding gives an additional 2.5:1

Hope this helps.
-------
Brian C. Smith				arpa:  bsmith@cs.Berkeley.EDU
University of California, Berkeley	uucp: uunet!ucbvax!postgres!bsmith
Computer Sciences Department		phone: (510)642-9585
From: chmin@cislabs.pitt.edu (Cheol-hong Min)
Newsgroups: comp.compression
Subject: Re: USC database site?
Keywords: USC
Date: 22 Jan 93 03:51:10 GMT
Organization: University of Pittsburgh

In Ciaran Mc Goldrick's article 

>>Can someone please e-mail me the IP no. and directory
>>for the USC image database site, or one of its mirrors.


I am looking for the same kind of information. Can somone please
e-mail me too?
I am also looking for some NMR head images in 12-bit gray scale.
can someone please e-mail me where I can find these images?

Thanking you in advance.

Cheol-Hong  Min


Newsgroups: comp.compression
From: hansoo@kum (Kim HanSoo (Daewoo Elec.))
Subject: Help: CCITT test sequence for H.261
Organization: KAIST in Seoul, Korea
X-Newsreader: Tin 1.1 PL4
Date: Thu, 21 Jan 93 06:44:52 GMT

I lost the CCITT test sequence for H.261. Thus I want to know the place of those sequence which get by FTP. Wanted specifications of sequence is following:

  a. Sequence Name : TREVOR, MISS AMERICA, CLAIR, ALIXIS,
                     SWING, SALES MEN, ...
  b. Sequence Spec : CIF (Common Intermediate Format)
                     30 frame/sec or 25 frame/sec
                     352 pixels/line x 288 lines/frame
                     color component : Y, R-Y, B-Y

  If the sequence is encoded by any-algorithms (ex: GIF, ppm, etc), I want to also get the decoding software.

  Mail address : hansoo@kum.kaist.ac.kr (hansoo@128.134.1.1)

  Bye.
From: dboer@let.rug.nl (Ale de Boer)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04E now available...
Date: 28 Jan 93 09:53:27 GMT
Organization: Faculteit der Letteren, Rijksuniversiteit Groningen, NL

In article <1k5f8dINN23s@tom.rz.uni-passau.de> schaefer@kirk.fmi.uni-passau.de (Achim Schaefer) writes:
>What's about anonymous ftp. Where can I get it?

ftp garbo.uwasa.fi
cd pc/arcers
get pkz204e.exe
-- 
________________________________________________________________
Ale de Boer, Department of English, University of Groningen
Oude Kijk in 't Jatstraat 26            E-mail: dboer@let.rug.nl
9712 EK  Groningen                      The Netherlands
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04E now available...
Date: 28 Jan 1993 16:59:15 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


Can someone who downloaded pkz204e.exe directly from the PKWare BBS
please post the size of the file in bytes, and a zip crc, Unix sum,
or both?  Thanks.  (An MD5 signature would be nice too, but I'm not
picky.)

Mark Adler
madler@cco.caltech.edu
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: Which compressors under Unix?
Organization: University of Vaasa, Finland
Date: Thu, 28 Jan 1993 11:24:43 GMT

In article <1993Jan27.202444.19378@opus40.ix.de> hm@opus40.ix.de (Harald Milz) writes:
>I apologize if it's a FAQ... I'm new in this group.

There is nothing wrong with asking a FAQ.

>I found some of PC-world's compressors for Unix (LHA, GZIP).
>Are there already any other compressors ported to Unix? Where
>can I get them?

 125879 Nov 23 11:38 garbo.uwasa.fi:/unix/arcers/arc.tar.Z
 667464 Dec  5 16:43 garbo.uwasa.fi:/unix/arcers/hpack78src.tar.Z
  96999 Jan 11 07:24 garbo.uwasa.fi:/unix/arcers/lha101u.tar.Z
  35321 Nov 23 11:38 garbo.uwasa.fi:/unix/arcers/unarj230.tar.Z
 299288 Jan 15 08:42 garbo.uwasa.fi:/unix/arcers/unz50p1.tar.Z
 186591 Nov 23 11:38 garbo.uwasa.fi:/unix/arcers/zip10ex.tar.Z
 244565 Nov 23 11:38 garbo.uwasa.fi:/unix/arcers/zip19p1.tar.Z
 237093 Nov 23 11:38 garbo.uwasa.fi:/unix/arcers/zoo210.tar.Z

>Pointers to FAQ are also appreciated.

 107719 Jan 24 13:51 garbo.uwasa.fi:/pc/ts/tsfaq32.zip
  47206 Nov 27 16:14 garbo.uwasa.fi:/pc/doc-net/faqc9212.zip

"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      Co-moderator of comp.archives.msdos.announce
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

Newsgroups: comp.compression
From: eng10205@nusunix1.nus.sg (LING SIEW WEE)
Subject: Re: NEW PKZIP 2.04E 
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Distribution: usa
Date: Thu, 28 Jan 1993 19:09:09 GMT

Stan Brown (brown@NCoast.ORG) wrote:
: In article <rdippold.728169261@qualcom> rdippold@qualcom.qualcomm.com (Ron Dippold) writes:
: What's amazing (and annoying) to me is that PKWARE shipped out 2.04c as
: upgrade fulfilment to registered users.  How could they not have known
: about many of the bugs?  I mean, volume labels not working?  One test 
: would have shown them that.
: ......

BEcause they happen to be humans who does mistakes. Even computers makes
mistakes (hardware bugs) which of course are made by humans...




--
***********************************************************************
*Name	    : Wilfred Ling Siew Wee   | National University of S'pore *
*Internet   : eng10205@nusunix.nus.sg | Electrical Engineering        *
*Bitnet	    : eng10205@nusvm.bitnet   |                               *
***********************************************************************
From: jls11@po.CWRU.Edu (John L. Spetz)
Newsgroups: comp.compression
Subject: Pkware and Undocumented Dos WAS:Re: PKZIP 2.04c vs. ARJ 2.39b etc
Date: 28 Jan 1993 22:48:37 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: jls11@po.CWRU.Edu (John L. Spetz)
NNTP-Posting-Host: slc12.ins.cwru.edu


In a previous article, nevries@accucx.cc.ruu.nl (Nico E de Vries) says:

>It is interesting to notice in the beginning InfoZIP was used because
>is is compatible with PKZIP. I noticed (e.g. from Timo) that nowadays
>PKZIP is used because it is compatible with InfoZIP. That is quite an
>achievement. It would be nice to extend the file format in ways improving
>it and force PKWARE to follow. InfoZIP is obviously much better at this
>than PKWARE. It might take ages (and most noticably an improved ARJ :-))
>before PK starts working on something new again. 
>
	In all fairness I think that Pkware should be given credit for
doing something most archiver authors do not want/are not willing to do,
namely write their archiver in highly optimized *assembly code*.  I know
that Info-Zip is written almost entirely in C (as I compiled the zip
portion to get a copy with encryption) and I have heard that arj is
written in C/C++.  I know that using a high level language has
undeniable benefits as fair as ease of testing and, foremost,
portability are concerned.  There is something to be said for having the
courage and discipline to delve into the realm of assembly to squeeze
the last bit of efficiency out of a program.  It goes without saying
that a program written well in assembly will outperform something in a
high level language.  I tend to think that pkzip 204c runs into problems
because it uses undocumented features of dos, like the fast memory copy,
which may well conflict with the intricacies of complicated beasts like
Windows and OS/2.  I can well believe that undocumented dos functions
and tricks, since few programmers use most of them anymore, might well
cause problems that have not come up before.
	By the way, two questions.  One, if arj is written in C++ as I
heard how come a unix version has been so long in coming out?  Two,
since the new pkzip can be distributed with the encryption features
enabled both here and abroad, could the encryption enabled version of
zip1.9p1 be posted on wu, oak, etc???
Newsgroups: comp.compression
From: Ashley@chaz.demon.co.uk (Charles Ashley)
Subject: Re: How can I get hold of Iterated Systems? 
Distribution: world
Organization: Learned Information (Europe) Ltd.
Reply-To: ashley@chaz.demon.co.uk
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Date: Fri, 22 Jan 1993 12:06:56 +0000

In article <1993Jan16.230047.1091@aee.aee.com> gene@aee.aee.com writes:

>Greetings,
>
>        I am trying to get in touch with a company I have seen reffered to as
>Interated Systems. This company is developing image compression technology
>around fractal compression techniques, with amazing compression ratios. If
>any of you know how to get in touch with them, please e-mail me.
>
>Gene Kochanowsky
>
>gene@aee.com
>-- 
>Gene Kochanowsky                           | "And remember ....
>Associated Electronic Engineers, Inc.      |       The better you look ... 
>(904)893-6741 Voice, (904)893-2758 Fax     |       the more you will see."
>gene@aee.com                               |               Miss Lidia
>

Iterated Systems Inc.
5550-A Peachtree Pkwy., suite 650
Norcross, GA 30092
tel. 1-800-4FRACTL
fax. (404)840-0806

Hope this helps
C.
-- 
*****************************************************************************
*                          - Charles Ashley -                               *
*    Internet:   ashley@chaz.demon.co.uk        Learned Information Ltd.    *
*    CompuServe: 71333,624                      tel: +44 (0)71-278-3414     *
*****************************************************************************


Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Info-Zip VMS quirk?
Date: Thu, 21 Jan 1993 16:34:46 GMT
Organization: Recognition Equipment, Inc.

While archiving a particularly old directory yesterday, I discovered a
strange anomoly in Zip's processing on VMS.  I used this command line:

$ zip "-r9mVw" archive *.*;*

This, to my understanding, should archive all files in the current
directory and below (using -r), including older versions of existing
files.  When the archive finished the next day (sheesh, slow vaxes), I
found that some files had not been removed via -m option, and in fact
they did not appear in the archive, either.  The files left behind were
previous versions of files which had been archived.  Since I specified
my pattern to match as "*.*;*", I expected all files, including older
versions, to be archived.  Does anyone know why the files were not
included?  How could I change my command line so that they would be
included properly on the first go?

This is definitely not a complaint, because without Info-Zip, we VMS
users would not have any decent archiver that saves file attributes!!
Thanks very much, Info-Zippers.  :)

-- 
#ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       fuzzy@netcom.com
#define  TRUE   0  |
#define  FALSE  1  |         "S-O-C-K-S ?   Wow, Spanish *is* easy!!"
#endif             |
From: fxu@ccwf.cc.utexas.edu (Franklin Xu)
Newsgroups: comp.compression
Subject: problem w/ installing stacker 3.0
Date: 27 Jan 1993 16:20:34 GMT
Organization: The University of Texas at Austin, Austin, Texas
Distribution: world
Reply-To: fxu@ccwf.cc.utexas.edu (Franklin Xu)
NNTP-Posting-Host: sneezy.cc.utexas.edu

when i tried to install stacker 3.0 using setup.exe, it gave a "An error
occured when reading setup1.com" msg. i know that setup1.com is inside
setup.saf, but how do i get it? (saf stands for Setup Archive File)
do i need some "unsaf" utility to decompress setup.saf first? or is there
any option i need for setup.exe to decompress setup.saf first? 
please mail replies to  fxu@ccwf.cc.utexas.edu. thanx in advance. 
-Franklin



Xref: sparky comp.compression:4840 comp.misc:5024
From: jtan@cad071.NoSubdomain.NoDomain (Jeffrey Tan)
Newsgroups: comp.compression,comp.misc
Subject: Re: hard disk stacker?
Date: 27 Jan 93 18:30:11 GMT
Organization: Intel Corp.

|> Has anyone used one of these things? And if so how good/reliable are they
|> really? To me it sounds pretty risky.
Yes, the Stacker 3.0 is not bad, even though it just came out couple months
ago.  The average compression rate on most files is 1.7-1.8 times, not including
already compressed files, such as .zip and .gif.  No further compression could
be done to those files.  In the Stacker 3.0, it even allows user to compress
their hard drive up to 8x.  But you have to know, if the compression rate is
above 2x, the reliability drops and as well as the hard drive access rate.
I would say 2x to 3x would be the best.  If you look for something reliable,
use stacker 2.0.  It has been out for long time and many people used, and are
still using it.  The only advantage I found from Stacker 3.0 is that you can
use a trick to fool the program to compress your RAMdrive.  I have my RAMdrive
doubled from 2MB to 4MB.
From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: comp.compression
Subject: Re: JPEG compression
Date: 25 Jan 93 14:06:27 GMT
Organization: Rechnerbetrieb Informatik - RWTH Aachen
Distribution: world
NNTP-Posting-Host: messua.informatik.rwth-aachen.de
Keywords: JPEG, compression

peterb@cs.uwa.oz.au (Peter Bousfield) writes:

>Hello fellow compressors,

>It is my understanding that JPEG compression
>works in basically two parts.
>Step 1: DCT (Discrete Cosine Transform)
>and
>Step 2: Huffman Coding (for those of us
>			who don't wish to
>			pay for a license.)

>I was wanting to know which of these
>two steps contributes more to the compression.
>That is, how good is the compression without
>Huffman coding (eg is it 50% worse or only 10%
>worse.)

Of course you forgot the most important Step 1.5:
Throwing away information. THAT really contributes.
From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: comp.compression
Subject: Re: Is This Possible (or is it B.S)? [200:1 Lossless Compression]
Date: 22 Jan 93 19:54:37 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <1jndtq$odg@agate.berkeley.edu> forrest@nobozo.CS.Berkeley.EDU (Jon Forrest) writes:
>                                    Is this B.S. or should I raise
>my arms and cry hallelujah?

If it's (a) revolutionary and (b) held in room 608-7, you won't have ROOM
to raise your arms, and the chest expansion necessary to cry "hallelujah"
would probably crush those around you.

>                                                     A model
>based on the theory consists of an  energetically  conserva-
>tive  field of uniformly distributed photons and an observer
>randomly walking through this field.  Observations are  made
>with  a bandwidth-limited set of transducers (an "eye") that
>respond to events during the walk.

This kind of post is dangerous to respond to... either it's a joke and you
look like an idiot for making a serious reply, or it's serious and you look
like an idiot for treating it like a joke.  Compressing text by walking
through photons just seems, shall we say, a bit weird.

>                             The  output  signals  from  the
>input  set  of transducers are "observed" by a second set of
>transducers (a mid brain), except the bandwidth limit of the
>second  set  of  transducers is a non-overlapping lower fre-
>quency range than the bandwidth of the first set  of  trans-
>ducers,  and  only  events from the first transducer set are
>"seen" by the second.

Got all that?  My brain hurts.  If it's serious, post a summary.

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
Xref: sparky comp.compression:4852 comp.misc:5035
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Newsgroups: comp.compression,comp.misc
Subject: Re: hard disk stacker?
Date: 27 Jan 93 18:25:46 GMT
Organization: Texas Instruments Inc
Cc: little_j@kosmos.wcc.govt.nz

In <1k4puvINN8nu@golem.wcc.govt.nz> little_j@kosmos.wcc.govt.nz (jon little	(little_j@kosmos.wcc.govt.nz)) writes:

>Hi,

>I have a copy of a hard disk stacker for a PC that is suppose to 'double' the
>capacity of you HD.

>Installing it is a one way street - once installed the only way to uninstall it
>is to reformat your HD!

>Has anyone used one of these things? And if so how good/reliable are they
>really? To me it sounds pretty risky.

Rather depends on which one you're talking about and just how you
install it, how much you know about your machine, etc.  A bit more
information might let people give you a better answer.

>As I don't regularly read these groups could you *please* e-mail replies to:
>     			little_j@kosmos.wcc.govt.nz

If you don't read them, why do you expect help from them?

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Xref: sparky comp.compression:4806 sci.image.processing:1714
From: pss1@kepler.unh.edu (Paul S Secinaro)
Newsgroups: comp.compression,sci.image.processing
Subject: Looking for JPEG reference images
Date: 22 Jan 1993 13:20:49 GMT
Organization: University of New Hampshire  -  Durham, NH
NNTP-Posting-Host: kepler.unh.edu

I'm trying to help out a friend of mine.  He claims that, when the
JPEG standard was developed, there was a certain set of test images
that were used to investigate/optimize different algorithms.  He would
like to obtain these images for his own research.

My question is, if such a set of images exists, is it available for
FTP somewhere on the net?

Thanks,

Paul

-- 
Paul Secinaro
pss1@kepler.unh.edu
Synthetic Vision and Pattern Analysis Laboratory
UNH Dept. of Electrical and Computer Engineering
From: kari@hpspdla.spd.HP.COM (Kari Santos)
Date: Tue, 26 Jan 1993 23:54:28 GMT
Subject: video quality
Organization: HP Stanford Park - Palo Alto, CA
Newsgroups: comp.compression

I'm trying to get a handle on video quality.  For instance, I'd like to
be able to compare the quality of, say, an analog Betacam video with
a CCIR 601 digital video with X:1 JPEG compression.  Basically,
I'd like to create a table in some way with analog and digital video
standards, different types of compression (JPEG, MPEG I, MPEGII, and
some type of lossless compression), and compression levels (ie 20:1,
100:1, etc)

To start with, I think I need some basic facts:
And I have a couple questions:

What are different resolution standards for digital video?
I know of CCIR 601, CIF and SIF, but I am having trouble tacking down
their exact resolutions.

How can I compare analog quality to quality of compressed digital?
Signal to noise vs ???

Any good references to these sort of issues?

Thanks for any ideas.

Kari Santos

Newsgroups: comp.compression
From: osyjm@cs.montana.edu (Jaye Mathisen)
Subject: Re: NEW PKZIP 2.04E 
Organization: CS
Distribution: usa
Date: Wed, 27 Jan 1993 20:08:26 GMT

In article <1993Jan27.184012.21784@ucsu.Colorado.EDU> cuffell@spot.Colorado.EDU (CUFFELL TIMOTHY MICH) writes:
>What happened to 2.04d?

There's gotta be one in every crowd...
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@cs.montana.edu
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04e BUG?
Date: 28 Jan 93 18:36:53 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY


  I find the list of bug fixes in 204e to be rather amusing, in that
they claim they corrected for bugs in Windows3.1, OS/2, QEMM and
Desqview. It's pretty obvious that when the whole world deos something
one way and they do it another, that PKware had a problem, not all the
popular memory managers.

  It's also pretty obvious that the 204c version went out the dorr with
virtually no testing at all, since many of the bugs are pretty blatent,
such as the memory managers and not working with batch files. That was
on the fix list, wasn't it?
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	A terible poker player can have a great hand,
	A obnoxious fool can have a good idea.
	Both are winners, regardless of who has them.