HDTenEightyP/NetNews huggingface dataset:
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: *** WARNING *** PKZIP 2.04c is infected by a virus.
Date: 7 Jan 93 15:40:04 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

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

| Clearly some smart cracker have used their chance. It might take ages before
| everyone has a reliable PKZIP 2.0x. We can just hope the authenticy
| verification in PKZIP 2.0x will be strong enough to remove this
| problem in the future.

  Actually it seems that WUARCHIVE used an old virus checker which gave
a false positive and then went ballistic. This scares me for several
reasons, not only did they get a lot of people to trash perfectly good
versions of PKZIP (if there is such a thing) but they are checking with
old software which may miss current virus infections.

  Not a very good thing to happen at a major archive site, perhaps THE
major archive site.

  When I was moderator of cbip I check every file with McAfee, Fprot,
and whatever third checker was popular at the time. I sometimes used a
checker for a single virus if the bad guys were ahead and that was the
only way I could find it.

-- 
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: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Another PKZIP 2.04C bug... WITH bug test file
Date: 12 Jan 93 16:42:49 GMT
Organization: Academic Computer Centre Utrecht

In <1993Jan12.054807.9814@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:

>Here we go again.  I understand the special circumstances, but I
>still don't think this was a good idea. 

It doesn't happen often, but this time I have to disagree with you. Of
course posting binaries is not a very smart idea but,
   - the message is VERY small (size is major problem with most binary files)
   - this way the problem can be seen by PKWARE before they release
     a new version (PKWARE is on the internet as well)

>    5) Even should the binary posting be just a short minor one, it
>       may easily snowball by invoking others. Even if a single
>       binary posting need not be harmful in any way per se, the
>       danger of the snowballing effect must be kept in mind.

I don't believe this is true. In general the SIZE of messages should
be gaurded (ever seen a Brian Sturgil posting :-)).

>I'll be happy to send you our upload instructions if you email me
>for them. Or if you wish to FTP the instructions directly, they are
>available as garbo.uwasa.fi:/pc/UPLOAD.INF.

For some purposes the queue at garbo is too large.

>   All the best, Timo

Nico E. de Vries  (nevries@cc.ruu.nl  100115,2303) |-----*   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.research
From: "jonathan forbes" <jonathan.forbes@canrem.com>
Subject: improvements to lha
Reply-To: "jonathan forbes" <jonathan.forbes@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 12 Jan 93 21:55:28 EST

-> By the way, the basic algorithm of LHA is in my public-domain pre-LHA
-> experimental archiver ar002 (which I wrote when I was a high-school
-> teacher).  It's in CompuServe's IBMPRO Library and also on the disk

I was wondering if you have considered any improvements to LHA's
compression, or any increase to its speed.

What do you think programs such as ARJ are doing to get compression
improvements over LHA?  Simply increasing the buffer size from 8K to 24K
can't be all it is.  Perhaps there is a better way of encoding the
huffman tree and outputting it - there may also be a faster way of
generating the huffman tree.

Also, do you know of a faster way to locate matches (than the digital
hash trie used in AR002)?  It doesn't matter if it takes more memory;
I'm just looking for speed improvements in the match finding process.

AR002 is a great program!
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
From: abirenbo@rigel.cel.scg.hac.com (Aaron Birenboim)
Newsgroups: comp.compression.research
Subject: CELP vocoder refs
Date: 12 Jan 93 20:00:10 GMT
Organization: Hughes Aircraft Colorado Engineering Labs


  I aminterested in learning about CELP compression.  I have a masters
in DSP so my math is solid.  I'd like to know about a nice text
which will tell me about popular speach compression algorithms,
and if possible some up-to-date papers on the CELP standard.
( i believe there is one)

   thanks in advance,
--
Aaron Birenboim         | If a single yeast cell were given an optimal growth
birenb@hac2arpa.hac.com |  media, within two weeks it would cover the entire
W (303) 344-6486        |  surface of the earth with a depth of two feet.....
H (303) 871-8271        |     wouldn't that be nice.    -- Micah Millspaw
Newsgroups: comp.compression.research
From: quandt@cs.umr.edu (Brian Quandt)
Subject: video capture to drive
Date: Tue, 12 Jan 1993 01:36:38 GMT
Organization: University of Missouri - Rolla, Rolla, MO

I'm working on MPEG compression here at University of Missouri and
we are about to set up the lab so that we can actually capture video
to harddisk to be compressed using MPEG.  My question is essentially
how to do this.


Here is what I have found out so far (info for the group for once instead
of just always asking questions)

You can capture video at CCIR-601 resolution to the Abekas A-65/66.  This
device will connect directly to a D-1 type deck and then capture 20-50
seconds of video in real time to a highspeed harddisk.  The A-65/66 comes
equipped with both an (thick... groan) ethernet and scsi-ii connector.
Built into the A-65/66 is a minature unix like kernel with tcp-ip
support.  So essentially you can hook this beastie up to your network
and rcp/ftp to from it.  The SCSI connector can not be connected directly
into your Sun and configured as a hard-drive but you can hang an 
exabyte drive off it and then archive stuff to it later.  So the basic
process to use this thing is 
	1) dump from D1 to abekas
	2) transfer via ethernet to host computer
	3) do you stuff (encode it or whatever)
	4) send it back to the abekas
	5) off load from abekas to the exabyte hanging on the scsi
	6) go to 1 (get another 20-50 secs of video from the d-1)
	
	Cost:  
		a-66 $25k 
		ethernet support $5k
		if you want to use a non-d1 deck (e.g., $100k we don't have one)
			A/D conversion $5k
			D/A conversino $5k (yes you have to buy seperate A/D, D/A)

So this looks like a feasbile solution, but... well it just seems to
me there must be a better way.

What about using a disk array?  And some device that would allow me
to hook up a deck (component video or whatever) directly to the 
disk array.  Just running through the figures in my head to get the 
necessary bandwidth on the disk array at about $1500 (1gig)per drive
I get competitive pricing and more importantly I don't get stuck with
a device (the abekas) that will probably be more outdated then a studebaker
in about a year (at least as a device for compression research).

Okay now my question.  I really don't know a thing about disk arrays.
Who sells equipment to set one up?  Can I get about 27-30Megabyte/sec
throughput?  What about the missing device to go from an external
deck (conponent video or whatever) into this disk array?

					thanks
From: g44140g@nucc.cc.nagoya-u.ac.jp (Haruhiko Okumura)
Newsgroups: comp.compression.research
Subject: Haruyasu Yoshizaki
Date: 7 Jan 93 03:48:30 GMT
Organization: Matsusaka University, Matsusaka, Japan.

In article <1993Jan05.223521.48819@dcc.uchile.cl> wscheu@dcc.uchile.cl
(Wst) writes:

> We are interested in reaching Mr. Haruyasu Yoshisaki Yoshi, the 
> creator of the LHA compressor.  The reason we want to reach him
> is to find out if there is any posibility of obtaining the licence
> (i.e., *.obj or *.lib for MS-DOS) for his compressor to use it in
> a program we're creating.

Haruyasu Yoshizaki (aka Yoshi) can be reached at:

    Dr. Haruyasu Yoshizaki, Obihiro Kyokai Hospital,
    Higashi 4-jo Minami 12, Obihiro 080 Japan

By the way, the basic algorithm of LHA is in my public-domain pre-LHA
experimental archiver ar002 (which I wrote when I was a high-school
teacher).  It's in CompuServe's IBMPRO Library and also on the disk
accompanying Mark Nelson's The Data Compression Book (M&T Books,
1991).

If you happen to have ar002, please replace line 24 of maketbl.c

    while (i <= 16) weight[i++] = 1U << (16 - i);

by these three lines:

    while (i <= 16) {
        weight[i] = 1U << (16 - i);  i++;
    }

--
Haruhiko Okumura (g44140g@nucc.cc.nagoya-u.ac.jp)
Matsusaka University, 1846 Kubo-cho, Matsusaka 515 Japan
From: vporguen@unlinfo.unl.edu (victor porguen)
Newsgroups: comp.compression
Subject: Re: DID YOU KNOW DIET144.ZIP ?
Date: 9 Jan 1993 03:38:49 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
NNTP-Posting-Host: unlinfo.unl.edu

kko@fraser.sfu.ca (Samuel Ko) writes:

>TCSAR03@waccvm.corp.mot.com (Germain Leutwyler) writes:

>>It is a good alternative versus complete subdirectories archivers for
>>people being short in space with their HD. Try it and let me know your
>>feelings afterwards !

>I don't quite like diet ... 1) executables compressed with diet cause
>some false alarms with some anti-virus programs and 2) diet doesn't 
>work well on a hard disk that was doubled with Stacker and other 
>disk-doublers ... Use pklite (pklte115.zip) instead for executables
>(or pkzip or data) ....

Diet is a lot better than PKLITE... and considerably cheaper: it's 
totally free.. I would be interested in knowing just exactly what kind
of "false alarms" did you get and with what anti-virus programs. Some
so-called anti-virus programs belong in the garbage anyway.

Regarding using Diet on a "Stacker-doubled" disk, of course, why 
compress again that which is already compressed? Use Diet INSTEAD of
Stacker and you will double your disk space WITHOUT paying a penny to 
anyone. You won't need Stacker <g>.

Diet does work a little like some stealth viruses, monitoring file
opens and checking if they are compressed by itself (more or less
like a virus does check executables to see whether they are already
infected by itself, to avoid double infection). The technique is
similar, and works very well in both cases. The result, in one case,
is undesirable, in the other case is highly desirable. 

Same technique, different applications... use Diet, it's great!
And it's free, on top of that.

Newsgroups: comp.compression
From: Richard.Kooijman@dnpap.et.tudelft.nl (Richard Kooijman)
Subject: Re: PKZip 2.04c quick impressions
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Sun, 10 Jan 1993 15:50:42 GMT

roe2@ellis.uchicago.edu (Cave Newt) writes:

>I wrote:

>>:An even better solution would be to get rid of the bad disk entirely

>hartman@ulogic.UUCP (Richard M. Hartman) writes:

>>What is wrong with skipping the bad sector and continuing using the
>>rest of the disk?

>If there's one bad sector already, chances are another will show up
>sooner or later--either because the diskette is physically damaged
>and other parts of it might flake, or because it has "weak" sectors
>which will eventually fail as the diskette ages.  Either way, an ar-
>chiving utility should avoid such disks--you want your data to survive,
>n'est-ce pas?  And compressors in particular don't do very well when
>there's a bad piece in the middle of the compressed data stream.

Next thing you will be doing is showing us with mathematical proof
that diskettes that show no problems are less likely to expose
bad sectors than diskettes that already have bad sectors?

What about harddisks, they are sold with bad sectors on them! You
probably don't own one, now do you?



Richard.
--
-- ir Richard Kooijman ------------------- Email: R.Kooijman@ET.TUDelft.NL --
-- Intelligent Network Management Project (INEMA) ---------------------------
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786209 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
Newsgroups: comp.compression
From: eduard@htsa.aha.nl (Eduard Beijnes)
Subject: about posting pkzip 2.04c
Date: Fri, 8 Jan 1993 13:17:59 GMT
Organization: Hogeschool van Amsterdam, The Netherlands, E.E. & C.S. Dept.

When I read the comp.compression newsgroup I saw that pkzip >2.00 is out.

When I look at alt.binaries.pictures they post really BIG files

Why doesn't anyone post something like pkzip ?
(or did I miss it ?)
From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: comp.compression
Subject: Re: Source for Lempel-Ziv
Keywords: lempel
Date: 8 Jan 93 22:11:36 GMT
Distribution: comp
Organization: Amdahl Corporation, Sunnyvale CA

In article <kko.726457766@sfu.ca> kko@fraser.sfu.ca (Samuel Ko) writes:
>Ooooo ... that should be Nelson (Mark Nelson) ... IMNSHO, that is the
>best book on data compression ...

Well, maybe.  Bell/Cleary/Witten does a much better job of explaining the
WHY of things, but the sample code in Nelson makes up for some of the detail
that he omits.  I don't really care much for his programming style, but
that's a personal problem. :-)

The sections on context modeling and DCT are very good, though.

>| Samuel C. Ko (aka The Smart One / BOZO) <--> a celebrity & DOS/UNIX wizard :)
>:) kko@sfu.ca <--> Outspoken,Highly-talented,Charming... I post this for You! |

Hmm.

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
Newsgroups: comp.compression
Subject: Re: *** WARNING *** PKZIP 2.04c is infected by a virus.
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Date: Wed, 6 Jan 1993 00:22:07 GMT
Organization: Computer Science Dept. University of Auckland

In <3546@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

>According to warning messages on wuarchive.wustl.edu the PKZIP 2.04c
>is a virus infected version. The virus detected is the "Maltese Amoeba"
>one.

>Unclear is if there is a real PKZIP 2.0x which has been infected 10
>seconds after release or that there is just a cracked new 1.93a version.
>PKWARE has promised to release a new version 5 jan so there might also be
>a real one. 

>Clearly some smart cracker have used their chance. It might take ages before
>everyone has a reliable PKZIP 2.0x. We can just hope the authenticy
>verification in PKZIP 2.0x will be strong enough to remove this
>problem in the future.

Pkware are most welcome to use the HPACK authenticity mechanism (employing
digital signatures) to guarantee the authenticity of their products.
Unlike their own scheme, not everyone on the planet knows how to break it.

(Sorry, just couldn't resist :-)
Peter.
--
    pgut1@cs.aukuni.ac.nz || peterg@kcbbs.gen.nz || peter@nacjack.gen.nz
			    (In order of preference)
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.compression
Subject: Re: PKZip 2.04c quick impressions
Date: 7 Jan 93 06:16:06 GMT
Organization: University of Vaasa, Finland

In article <1igcumINNiip@crcnis1.unl.edu> vporguen@unlinfo.unl.edu (victor porguen) writes:
>Could it be that you've discovered yet another bug in the new PKZIP
>2.04c? So far, I have seen reports that it cannot recognize Volume
>labels when backing up to a series of floppies and that the
>passwording/encryption is a bummer! Now this.

Just a detail.  I am led to understand that the encryption and the
broken -AV labels are two different things.  I haven't heard of a
wholesale breaking of the former although there are even programs in
the underground circulation to break the latter.

   All the best, Timo

..................................................................
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
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: pkzip 2.04c / unzip v5.0 compatibility
Date: 8 Jan 1993 18:03:05 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


>>   I thought PKZip's and Info-Zip's compression engines were identical,
>> but maybe PKWare sacrificed some compression efficiency for speed, as

No, they are certainly not identical.  At least on the assumption that
the Katz patent has something to do with his compression algorithm.
However both algorithms can trade speed for compression by changing
some simple parameters.

What is identical is the *format* of the compressed data, which
essentially defines what a zip decompressor has to do.  It does not
put any restrictions on how that compressed data stream is generated.
In particular, it does not say how matching strings are found.

In this way you can have compressors with very different speed and
compression performance, yet a single decompressor can work with all
of them.

This basic principle is what allows competing companies to agree on
standard compressed data streams, like JPEG, JBIG, MPEG, etc.  The
standard allows common decoders for the format, but the companies
compete with more efficient and more effective *encoders*, as wellas
cheaper or better implementations of the decoders.

Mark Adler
madler@cco.caltech.edu
Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZip 2.04c Patent
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  5 Jan 93 16:24:48 GMT

rdippold@cancun.qualcomm.com (Ron Dippold) writes:

> BTW, the new PKZip says 

>   PKZIP Reg. U.S. Pat. and Tm. Off.   Patent No. 5,051,745

> Did the old one have anything similar?

Yup, the alpha version (1.93) says the same thing.

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
Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Re: PKZIP 2.04c vs. ARJ 2.39b (and LHA/ZOO) Compression Results
Date: Mon, 11 Jan 1993 23:34:01 GMT
Organization: Recognition Equipment, Inc.
Keywords: archive compress ARJ PKZIP LHA ZOO

ts@uwasa.fi (Timo Salmi) writes:

>>Why not make an Info-ARJ???

>Well there it is, out in the open.  Anyone with sufficient spare
>time?  There already is
>  35321 Nov 23 11:38 garbo.uwasa.fi:/unix/arcers/unarj230.tar.Z
>so go for it!  It is a very worthwhile idea.

Unfortunately, using this as starting code is not possible.  The source
license for R. Jung's UNARJ program specifically disallows using it as a
basis for an ARJ archiver program.

-- 
#ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       fuzzy@netcom.com
#define  TRUE   0  |
#define  FALSE  1  |  "911 Emergency Rescue Service - Can you hold, please?"
#endif             |
Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZip 2.04c quick impressions
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 11 Jan 93 20:39:07 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

> :Actually PKZIP does the opposite. If a sector is marked BAD in the
> :FAT its quick format removes the mark making it good again. A very
> :bad thing for file integrity.

> AAAAAAAAAAAACCCCCCCCCKCKKKKKKKKK!!!!!!!!!!

> Tell me you are joking!!!  Please!?!????!?!?!???????

Not at all, it depends on the option used. If you tell it to "wipe all
files on the disk", it will just zero the FAT and the root directory.
Now, if a cluster is marked as bad in the FAT, zeroing the FAT will
"mark" this cluster as a good one again.

Conclusion: if you have bad clusters on your diskettes, don't use the
-&w option; use -&f instead. Or even better - don't use those
diskettes.

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
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: PKWare Phone #??
Organization: University of Vaasa, Finland
Date: Tue, 5 Jan 1993 07:15:58 GMT

In article <1993Jan4.231945.1988@msus1.msus.edu> skriefal@eeyore.stcloud.msus.edu (Scott Kriefall) writes:
>Could someone please inform me of PKWare's new phone number?  There old
>number (1-414-352-7176) appears to have been disconnected.

Have you tried the one given in the authors' list:
  15460 Dec 17 14:40 garbo.uwasa.fi:/pc/pd2/author12.zip

(Please let me know if there is a problem with that too).

   All the best, Timo

..................................................................
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: robjung@world.std.com (Robert K Jung)
Subject: Re: More severe bugs in PKZIP 2.04c.
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 8 Jan 1993 13:57:17 GMT

robjung@world.std.com (Robert K Jung) writes:

>Using -3 -) on a vanilla DOS 5.0 (no config.sys, no autoexec.bat) on
>a 486DX machine, I used PKZIP 2.04c to backup several Wing Commander
>EXE files to diskettes. (PKZIP -& -3 -) b:test *.EXE).  On compressing
>the last file onto the first diskette, PKZIP displayed "done" indicating 
>that it had finished the compression phase and then prompted for 
>the insertion of a new diskette.  Then PKZIP wrote about 60K of data on 
>that diskette.

>I immediately typed "PKUNZIP b:test".  PKUNZIP extracted all BUT the last
>file reporting a file CRC error with a "file has bad table" error message.

Apparently, a user reported a similar error to the PKWARE CompuServe forum.
They were backing up a 1.7 MB ZIP file (zipped with 1.1) and got the 
"file has bad table" error.  So I tried the same thing, creating a ZIP file
slightly larger than one diskette.  PKZIP 2.04 compressed it saving 1 percent
onto two diskettes.  This backup set produced the same "bad table" error
message.

*** PROCEED WITH CAUTION backing up ZIP files ***

Regards,
Robert K Jung
Newsgroups: comp.compression
From: dl211@randr.com ( David Laney      )
Subject: Compression Technique Source Code
Followup-To: None 
Summary: Looking for File Compression Source code
Organization: Reynolds+Reynolds, Dayton, Ohio
Date: Mon, 11 Jan 1993 21:51:26 GMT

       Hello, my name is David Laney and I am looking for some
source code or algoritims that I could use to implement file compression
for a new ascii file viewer that I am writing in the DOS environment.
The technique does not have to be modern or update just usable.

I would appreciate a reply by Email and perhaps the phone number for
a BBS system that I could dial into.  Thanking you in advance for any 
help that you could give me.


-David Laney


-- 

------------------------------------------------------------------------
    From:                        !
        David O. Laney           !  Internet:  dl211@windy.randr.com