HDTenEightyP/NetNews huggingface dataset:
From: tope@enea.se (Tommy Petersson)
Newsgroups: comp.compression
Subject: Re: Is This Possible (or is it B.S)? [200: 1 Lossless Compression]
Date: 22 Jan 93 18:40:33 GMT
Organization: Enea Data AB
X-Newsreader: Tin 1.1 PL3

forrest@nobozo.CS.Berkeley.EDU (Jon Forrest) writes:
: I'm the first to admit that I don't know anything about compression.
: That's why I'm extremely puzzled by the following abstract of a talk that's
: going to be given here at Berkeley. Is this B.S. or should I raise
: my arms and cry hallelujah?
: 
: ---
:                           CS 298-9
:                     Sequoia 2000 Seminar
: 
:             Joe Bugajski, Founder and President
:                         Triada Ltd.
: 
:                  TRIADA'S 200:1 (LOSSLESS)
:                   DATA COMPRESSION ENGINE
: 
:                   Friday, January 29, 1993
:                    1:00 p.m. - 3:00 p.m.
:                       608-7 Evans Hall
: 
: 
:      Triada, a development stage company located  in  Michi-
: gan,  has  developed  an encoding transform capable of up to
: 200:1 lossless data compression.  The theoretical  underpin-
: ning of the transform is believed to extend classical infor-
: mation theory. a.s.o.

Maybe now is the time for "WEB II, The Universe Implodes"???

Note that he wrote "up to 200:1"...

-- 
=============================================================================
 Tommy Petersson              tope@enea.se              Enea Data AB, Sweden
=============================================================================
From: gt0040a@prism.gatech.EDU (Tom Sorensen)
Newsgroups: comp.compression
Subject: Re: PKZip 2.04: c vs. e
Date: 28 Jan 93 18:54:19 GMT
Organization: Georgia Institute of Technology

In <1993Jan28.042957.3302@samba.oit.unc.edu> alewis@gibbs.oit.unc.edu (Andrew Lewis) writes:

>Could someone (perhaps the maintainer of the 2.04c bugs list) post an
>independent evaluation of the differences between 2.04c and 2.04e?  I have

Well I myself am waiting to see if there are any bug reports... so far it seems
good. They DID fix the volume label (checked that). I haven't had time to run
extensive tests though.

There are already a couple new bugs dealing w/ the multidisk spanning. I will
post a list tomorrow. Hopefully it'll include any bugs that are posted before
I post it.

>the item (unlike revision c, I'm using it), but I'd like to see a list of
>what was broken that has been fixed; what was broken that hasn't been
>fixed; what wasn't broken, but was maybe a little bent, and whether it got

Hmm... good idea. I'll probably edit the 4th release severely and post a fairly
small message detailing what was supposably fixed.

>Should I advise my local BBS operators to stay away from this version, too?

I would suggest that you convince anyone using 2.04c to start usiing e. Anyone
still on PKZ110 should probably stay there for a week. By then we'll know the
count. If its good then I'm going to suggest that local BBS operators start the
gargantuan job of switching.
      Tom Sorensen
-- 
---------------------------------------------------------------------------
Tom Sorensen              gt0040a@prism.gatech.edu
"I believe OS/2 is destined to be the most important operating system,
and possibly program, of all time." - Bill Gates, November, 1987
Newsgroups: comp.compression
From: rdippold@qualcom.qualcomm.com (Ron Dippold)
Subject: Re: NEW PKZIP 2.04E 
Organization: Qualcomm, Inc., San Diego, CA
Distribution: usa
Date: Wed, 27 Jan 1993 21:14:21 GMT

cuffell@spot.Colorado.EDU (CUFFELL TIMOTHY MICH) writes:
>What happened to 2.04d?

Probably an internal only beta (unlike 2.04c, the public beta (yes, I
know it was supposed to be an actual release)).
-- 
How can I laugh tomorrow, when I can't even smile today? -- Suicidal Tendencies
From: vporguen@unl.edu (victor porguen)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04E now available...
Date: 27 Jan 1993 04:28:33 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
NNTP-Posting-Host: unlinfo.unl.edu

caeser@csd4.csd.uwm.edu (Robert Michael Trotter) writes:

>	Just got off the PKWARE BBS, the new PKZIP 2.04E is now available
>	for download. though some would find that interesting here.

>	Caeser
>-- 


Hey! You mean somebody succeded in fixing PKZIP so that it works now??
Fantastic!

Why don't you give a copy of it to Phil Katz - it may teach him how
to write computer programs.

Newsgroups: comp.compression,comp.misc
From: mkaufman@mcs.kent.edu (Michael Kaufman)
Subject: Re: hard disk stacker?
Organization: Kent State University
Date: Thu, 28 Jan 1993 15:16:46 GMT

I have STacker 3.0, and found it a lot better than STacker 2.0.  It has a 
coupla more options in the Stac menu, one of which is password protecting your
Stacker drive. when you boot up, or mount the Stacker drive, it'll ask you
for the password.  Not right, won't mount.  Pretty cool.  Also, Stacker 3.0
has a little better compression ratio.  For instance, when I used v2.0, and
did an SDIR on my root, I found that the maximum comression, even on straight
ASCII files was only 3.5:1.  Now, I get a compression ratio of 16:1.  
	I've had no problems with v3.0, so, even though 2.0 may have been out
longer, I  believe v3.0 will be just as usefull, if not more, than 2.0.
If you have thge money, go out and get it, I highly recommend it.  Also, 
as to the original question of Stacker being a "one-way street"  v3.0 solves
that problem.  It checks how much data is on the STacker drive, and how much
the physical drive can hold, it then tells you if you need to delete some files,
or if it is okay to UnStack the drive, and then tells  you how much space 
will be left after UnStacking.  v2.0 didn't have that, as you say, and you
had to delete the Stacvol.dsk files if you wanted to use the physical drive
again.  you don't necessarily have to re-format your drive, just, as I said, 
delete teh drive file.  
	Buy it, try it, if you don't like it, send it back to get a refund.
simple.


Mike

mkaufman@mcs.kent.edu
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: PkWare BBS phone # wanted
Organization: University of Vaasa, Finland
Date: Thu, 28 Jan 1993 18:20:56 GMT

In article <93028.25393.LJ01066@LMSC5.IS.LMSC.LOCKHEED.COM> LJ01066@LMSC5.IS.LMSC.LOCKHEED.COM writes:
>Could anyone please give the phone number for pkwares BBS so I can
>get a copy of PKZIP204E as I can't get anywhere else I have access
>to. E-mail or post is fine. Many thanks in advance.

Please see
  16213 Jan  8 14:14 garbo.uwasa.fi:/pc/pd2/author13.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". 

   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: law40003@nusunix1.nus.sg (TAN YEW KEONG)
Subject: Re: PKZIP 2.04E now available...
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 27 Jan 1993 15:14:43 GMT

Robert Michael Trotter (caeser@csd4.csd.uwm.edu) wrote:
: 	Just got off the PKWARE BBS, the new PKZIP 2.04E is now available
: 	for download. though some would find that interesting here.
: 
: 	Caeser
: -- 
If you want it by ftp it is available in garbo.uwasa.fi in the pc/arcers
directory, filename pkzip204e.exe

Enjoy!
--

_________________________________________________________________________
Michael Tan Yew Keong | law40003@nusunix1.nus.sg | law40003@nusvm.nus.sg|
Final Year Law student - OH GOD, IT'S BEEN A HELLUVA LONG TIME!!!       |
________________________________________________________________________|
Newsgroups: comp.compression
From: elmar@gulasch.hanse.de (Elmar Folba)
Subject: Re: Is This Possible (or is it B.S)? [200:1 Lossless Compression]
Organization: Spare-time Hacker, Hamburg, Germany
Date: Fri, 22 Jan 1993 19:00:49 GMT

In article <1jndtq$odg@agate.berkeley.edu> forrest@nobozo.CS.Berkeley.EDU (Jon Forrest) writes:
>I'm the first to admit that I don't know anything about compression.
>That's why I'm extremely puzzled by the following abstract of a talk that's
>going to be given here at Berkeley. Is this B.S. or should I raise
>my arms and cry hallelujah?
>
>... (bigger part of quote deleted)
>                   1:00 p.m. - 3:00 p.m.
>                      608-7 Evans Hall
>
>     Triada, a development stage company located  in  Michi-
>gan,  has  developed  an encoding transform capable of up to
>200:1 lossless data compression.  The theoretical  underpin-

So what?
'Up to' does not mean anything. Run-length encoding a file of one million
equal bytes will give you a much better compression ratio ON THAT FILE.
What counts in practical life is how much, and at what costs, a particular
algorithm (still more precisely: a particular implementation of a particular
algorithm) will compress YOUR data.
On the other hand, the theoretical limit to data compression has been
established long ago, and challenging that makes about as much sense as
challenging the laws of thermodynamics.
What remains is finding algorithms that do more of the theoretically possible
compression, for a wider range of statistics, at less costs: and here
we should certainly remain open, nay, eager for any new development.


-- 
Kind regards,			Elmar Folba
				Hamburg, Germany
				elmar@gulasch.hanse.de
From: laplante@sun490.fdu.edu (Phil Laplante)
Newsgroups: comp.compression
Subject: Session on Real-Time Image Processing
Date: 22 Jan 93 21:29:36 GMT
Organization: Fairleigh Dickinson University




            * * * C A L L    F O R    P A P E R S * * * 


Papers are requested for  a special session on "Real-Time Image Processing" 
to be held at the 1993 IEEE Systems, Man, and Cybernetics Conference 
in Le Touquet France, October 17-20, 1993.

The IEEE SMC conference is the showcase gathering for the IEEE SMC interest
group.  IEEE SMC covers a broad range of topics in image processing, robotics,
and artificial intelligence.  The archival journal of the society is the
IEEE Transactions on Systems, Man, and Cybernetics.

Topics for the session include but are not limited to:

Real-time image processing applications
Real-time image processing protocols
Real-time image processing specification 
Real-time image processing architectures
Multi-media 
Virtual reality
Remote sensing and control
Real-time image compression

Papers should be 6-10 pages in length and will be published in the
conference proceedings.  Authors will be expected to make a presentation
at the conference.

The deadlines for submission to the conference are as follows:

Extended abstract submission   February 15, 1993
Preliminary acceptance         May 1, 1993
Full paper submission          July 15, 1993
Final acceptance               August 1, 1993

Please send extended abstracts via post, FAX, or email to:

Dr. Phil Laplante
Department of Mathematics and Computer Science
Fairleigh Dickinson University
Madison, NJ 07480
laplante@fdumad.fdu.edu
(201) 593-8680 (voice)
(201) 593-8886 (FAX)

If you need further information, please do not hesitate to call.
Newsgroups: comp.compression
From: christim@ifi.uio.no (Christian Moen)
Subject: PPMC archievers ?
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Fri, 22 Jan 1993 08:58:12 GMT
Originator: christim@hadd.ifi.uio.no

Are there any PPMC ("Prediction by Probability Method C") archievers
available ?

I know such a program might require vast amounts of CPU and memory,
have anybody bothered to make one in the PD ?

I'm looking for LZJ archievers as well.

Thanks in advance.

\||||
oo  |  Christian Moen, email: christim@ifi.uio.no
C   |
|_  |  "I had this dream, in which I swim with dolphins,
 \  |   in open sea of transparent blue, maybe you dreamt it, too ?"
From: cn659@cleveland.Freenet.Edu (Paul R. Sadowski)
Newsgroups: comp.compression
Subject: compression/archive file formats
Date: 23 Jan 1993 07:15:40 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cn659@cleveland.Freenet.Edu (Paul R. Sadowski)
NNTP-Posting-Host: hela.ins.cwru.edu


I'm looking for file format information for the popular (and not
so popular) compression programs - such as ARJ, LZH, ZOO formats...
etc. I don't want to decompress the files, just find the file info
such as filenames, time & date stamps, size...

I have the info for ZIP & ARC but I can't find the others. 
Newsgroups: comp.compression
From: fred@genesis.demon.co.uk (Lawrence Kirby)
Subject: Re: Unix release? (Was etc. 
Distribution: world
Organization: BT
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Date: Thu, 28 Jan 1993 18:40:51 +0000

In article <C1EArp.KL@unix.amherst.edu> djweisbe@unix.amherst.edu writes:

>Lawrence Kirby (fred@genesis.demon.co.uk) wrote:
>: 
>: The knapsack problem deals with a single knapsack (i.e. disk) and is NOT
>: NP-complete. It's a common example of dynamic programming where the optimal
>
>The Knapsack problem sure is NP complete.  I believe the following
>explanation is correct, if simple (check in comp.theory, though):
>
>There is an algorithm which is linear in N, the number of items, but
>the specification of N is of length proportional to log N, so the
>running time is actually exponential in the length of the input.

The input data to the problem isn't the number of items, it is in general a list
of the items. The size of this input data will be proportional to N, not log N.
The problem isn't even be exponential on the size of the knapsack since the
size is constrained by the total size of the items available.

>Just a humble undergrad,
>  David
>

Happy days!

-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------
Xref: sparky comp.compression:4817 comp.misc:5007
From: little_j@kosmos.wcc.govt.nz (jon little	(little_j@kosmos.wcc.govt.nz))
Newsgroups: comp.compression,comp.misc
Subject: hard disk stacker?
Date: 27 Jan 1993 01:53:35 GMT
Organization: Wellington City Council (Public Access), Wgtn, Nz
Reply-To: little_j@kosmos.wcc.govt.nz
NNTP-Posting-Host: kosmos.wcc.govt.nz

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.

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


Thanks in advance.

Jon Little                little_j@kosmos.wcc.govt.nz

'A dog with three legs will always run faster than a cat with no legs' - R T
Bend
Newsgroups: comp.compression
From: brown@NCoast.ORG (Stan Brown)
Subject: Re: NEW PKZIP 2.04E 
Organization: Oak Road Systems, Cleveland Ohio USA
Distribution: usa
Date: Thu, 28 Jan 1993 12:36:22 GMT

In article <rdippold.728169261@qualcom> rdippold@qualcom.qualcomm.com (Ron Dippold) writes:
>cuffell@spot.Colorado.EDU (CUFFELL TIMOTHY MICH) writes:
>>What happened to 2.04d?
>
>Probably an internal only beta (unlike 2.04c, the public beta (yes, I
>know it was supposed to be an actual release)).

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.

It's not as though they felt any great time pressure--after all, they
were advertising 2.0 a year before it was available.  Why could they not
have waited another week or two and done some testing?
-- 
Stan Brown, Oak Road Systems                    brown@Ncoast.ORG
Cleveland, Ohio, USA
"Compared to my life, the last man on a chain gang is thoroughly
enjoying himself."                   __Holiday__ by Philip Barry
Newsgroups: comp.compression
Subject: Another Info-ZIP problem
From: CHEGC@LURE.LATROBE.EDU.AU (CROSS,Graeme)
Date: Thu, 21 Jan 1993 22:44:56 GMT
Organization: La Trobe University
X-News-Reader: VMS NEWS 1.24

Back again with another Info-ZIP problem. I would have posted this earlier but
apparently our news feed has been down for 2-3 days and I wanted to read
replies to my first posting before posting this one.

Disclaimer #1: The Info-ZIP product is very impressive: especially given it's
multi-platform nature - I have started to use it to ship files between my VMS
account and my DOS and UNIX boxes, but anyway...

Problem #3: Put yourself in a directory, say E:\DOCS
            Create a ZIP file, eg. ZIP -m9 TEST *.txt
            Now move everything else in the directory into the ZIP file

If you say: ZIP -m9 TEST *.*    you will have no problems
If you say: ZIP -m9 TEST e:*.*  you will find that ZIP moves the original 
TEST.ZIP into the new TEST.ZIP file, resulting in an empty directory!

Now I have only tested this on the current DOS version, but be warned: it is
possible for your ZIP files to eat themselves! The problem is easily avoided,
but I had to rewrite a couple of batch files that I had. Note also that the
current release of PKZIP does not manifest this problem.


Graeme Cross                   |  chegc@lure.latrobe.edu.au
Dept. of Chemistry             |
La Trobe University            |  One day, by accident or design, a .sig will 
Bundoora, Victoria, Australia  |  just mysteriously appear here...
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04E now available...
Date: 29 Jan 1993 02:53:39 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


Alex Strasheim kindly provided:

>> file is 196424.  I'm not sure what you mean by a zip crc, but I did one of
>> these:
>>         pkzip stf pkz204e.exe
>> and when I listed the archive, the crc-32 column contained this entry:
>>         54a5bfd7

Thanks.  That's exactly what I meant by a zip crc.  Someone else
provided the Unix sum 23908, so now I'm satisified I have a good
copy.

And yes, the crc in the zip file is on the uncompressed data.  This
provides a check of both the fidelity of the zip file and the correctness
of the compression and decompression algorithms and implementations.

Mark Adler
madler@cco.caltech.edu
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: Another Info-ZIP problem
Date: 25 Jan 93 17:18:36 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)

Graeme Cross <chegc@lure.latrobe.edu.au> writes:

> If you say: ZIP -m9 TEST e:*.*  you will find that ZIP moves the original 
> TEST.ZIP into the new TEST.ZIP file, resulting in an empty directory!

The fix for this problem is given below.

> Note also that the current release of PKZIP does not manifest this problem.

Not this one, but a close friend:

C:\TMP>mkdir d
C:\TMP>echo hi > d\hi
C:\TMP>pkzip -P d\ghost d\hi
PKZIP (R)   FAST!   Create/Update Utility   Version 2.04c   12-28-92
[...]
Creating ZIP: D/GHOST.ZIP
  Adding: D/HI  Storing   ( 0%), done.

C:\TMP>pkzip -mP d\ghost d\ghost.zip
[...]
Updating ZIP: D/GHOST.ZIP
  Adding: D/GHOST.ZIP  Deflating  (44%), done.
Moving files, done.

C:\TMP>dir d
[...]
.            <REP>     01-23-93  12:07p
..           <REP>     01-23-93  12:07p
HI                   5 01-23-93  12:07p
        3 fichier(s)          5 octets


My patch was made in a few minutes, but I could not work on zip
until yesterday, sorry. Now wait for the same fix from PKWARE.

Please send bug reports on zip and unzip to zip-bugs@wkuvx1.bitnet.

Jean-loup Gailly
info-zip

*** zip19p1/fileio.c	Wed Aug 26 18:53:38 1992
--- new/fileio.c	Mon Jan 25 18:05:32 1993
***************
*** 305,310 ****
--- 305,313 ----
  
  /* Local globals (kinda like "military intelligence" or "broadcast quality") */
  local int exflag = 0;           /* Exclude flag */
+ local struct stat zipstatb;
+ local int zipstate = -1;
+ /* -1 unknown, 0 old zip file exists, 1 new zip file */
  
  #ifdef VMS
    typedef int statime;
***************
*** 1155,1160 ****
--- 1158,1182 ----
      }
      else
      {
+       /* Check that we are not adding the zip file to itself. This
+        * catches cases like "zip -m foo ../dir/foo.zip".
+        */
+       struct stat statb;
+       if (zipstate == -1)
+          zipstate = strcmp(zipfile, "-") != 0 &&
+                      stat(zipfile, &zipstatb) == 0;
+       if (zipstate == 1 && (statb = zipstatb, stat(n, &statb) == 0
+         && zipstatb.st_mode  == statb.st_mode
+ 	&& zipstatb.st_ino   == statb.st_ino
+ 	&& zipstatb.st_dev   == statb.st_dev
+ 	&& zipstatb.st_uid   == statb.st_uid
+ 	&& zipstatb.st_gid   == statb.st_gid
+ 	&& zipstatb.st_size  == statb.st_size
+ 	&& zipstatb.st_mtime == statb.st_mtime
+ 	&& zipstatb.st_ctime == statb.st_ctime))
+         /* Don't compare a_time since we are reading the file */
+            return ZE_OK;
+ 
        /* allocate space and add to list */
        if ((f = (struct flist far *)farmalloc(sizeof(struct flist))) == NULL ||
            (f->name = malloc(strlen(n) + 1 + PAD)) == NULL)
From: exuptr@exu.ericsson.se (Sunbird a la 400ci)
Newsgroups: comp.compression
Subject: Re: Is This Possible (or is it B.S)? [200: 1 Lossless Compression]
Date: 25 Jan 93 02:45:44 GMT
Organization: Ericsson Network Systems, Inc.
X-Disclaimer: This article was posted by a user at Ericsson.
              Any opinions expressed are strictly those of the
              user and not necessarily those of Ericsson.

In article <1993Jan22.184033.23504@enea.se> tope@enea.se (Tommy Petersson) writes:

>forrest@nobozo.CS.Berkeley.EDU (Jon Forrest) writes:
>: I'm the first to admit that I don't know anything about compression.
>: That's why I'm extremely puzzled by the following abstract of a talk that's
>: going to be given here at Berkeley. Is this B.S. or should I raise
>: my arms and cry hallelujah?
>: 
>: ---
>:                           CS 298-9
>:                     Sequoia 2000 Seminar
>: 
>:             Joe Bugajski, Founder and President
>:                         Triada Ltd.
>: 
>:                  TRIADA'S 200:1 (LOSSLESS)
>:                   DATA COMPRESSION ENGINE
>: 
>:                   Friday, January 29, 1993
>:                    1:00 p.m. - 3:00 p.m.
>:                       608-7 Evans Hall
>: 
>: 
>:      Triada, a development stage company located  in  Michi-
>: gan,  has  developed  an encoding transform capable of up to
>: 200:1 lossless data compression.  The theoretical  underpin-
>: ning of the transform is believed to extend classical infor-
>: mation theory. a.s.o.

>Maybe now is the time for "WEB II, The Universe Implodes"???

>Note that he wrote "up to 200:1"...

I'm thinking that if they are compressing image files (like bitmaps) of TEXT
ONLY content, this really isn't that outrageous.  Imagine how much bigger
a bitmap of that article would be than the text itself.
 -----------Visit the SOUNDING BOARD BBS 214-596-2915, a Wildcat! BBS--------
 ObQuotes:
 "Quick to judge, quick to anger, slow to understand..."
 "Ignorance and prejudice, and fear go hand-in-hand..."

    Patrick Taylor, Ericsson Network Systems
    exuptr@exu.ericsson.se                    "Don't let the .se fool you"