HDTenEightyP/NetNews huggingface dataset:
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: question about "zoo xp foo.tar.zoo foo.tar" usage
Date: 9 Apr 92 17:19:03 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <+prjh1c.ead@netcom.com>, ead@netcom.com (Eric De Mund) writes:
|  comp.compression people,
|  
|  i would like to be able to use a zoo archive in a way similar to how i
|  use a .tar.Z file:
|  
|      % zcat foo.tar.Z | tar -xvf -
|  
|  however,
|  
|      % zoo xp foo.tar.zoo foo.tar | tar -xvf -
|  
|  doesn't work because foo.tar is prepended with:
|  
|      ********
|      foo.tar
|      ********
|  
|  is there any way a non-filter zoo file can be made to behave this way?

  So use the q option, that's what it's for. This is in the man page,
the user's guide, and the big help (zoo H) screens.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: DIET revisited.
Date: 8 Apr 92 12:55:25 GMT
Organization: Academic Computer Centre Utrecht

Some time ago a wrote something about DIET vs PKLite and LZEXE. Due to
the response I got I think I should spend some more lines on the program.
First a comparrision for compression size:

EXE           PKLite 1.12    DIET 1.2
13568         8614           8245   (own exe)
106521        71283          71257  (TASM.EXE)

This seems to be tipical. Compressing a large collection of small files
is much more favorable with DIET than with PKLite. On larger files the
difference almost disapears. Someone repored to me some files are even
worse compressed by DIET, large ones that is.
I already reported that I didn't receive the profecional PKLite yet (they
have already charged our credit card) so I can't compare that one.

Some interesting features of DIET (besides .EXE .COM compression) are:

- also capable of making self extracting device drivers (.SYS)
- can also compress data files (any) DIET can be made resident
  and compresses/decompresses those files automatically (sort of
  poor mans stacker). It uses only 8kb of memory! (assuming EMS
  otherwise about 23 kb).
- it is FREE!

Nico de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (comming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
Newsgroups: comp.compression
From: pdh@netcom.com (Phil Howard )
Subject: Re: 16: 1 data compression
Date: Fri, 17 Apr 92 04:35:02 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: bogus, compression

obnoid@wet.UUCP (Mike Kirschner) writes:

>If you'll recall, the original point of this thread is the company WEB
>Technologies, and their claimed 16:1 lossless compression ratio. I just
>received their marketing materials on their products and, if it's true,
>we'll need to throw out all we've ever come to know, love, and hate about
>lossless data compression. They claim 16:1 and better. Not only on the first 
>pass, but on each subsequent pass! With 4 passes, they say that a 64MB file 
>can be compressed to 994 bytes. They don't address any specific type of
>binary data, but encompass it all. Encrypted files too? Can't be an April
>Fool's Day joke because the Press Release is dated Feb. 1!

Maybe it might take quite a while for anyone to come up with 2^7952
different states of a 64MB file, but once someone has state 2^7952+1
then clearly this algorithm's claim fails.

I think we need to consider WHAT kind of data is being compressed.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/
Newsgroups: comp.compression
From: umfehr06@ccu.umanitoba.ca (John Fehr)
Subject: Re: 16: 1 data compression
Keywords: bogus, compression
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 17 Apr 1992 03:58:16 GMT

In <h+1jl4_.pdh@netcom.com> pdh@netcom.com (Phil Howard ) writes:

>>I invented a compression algorithm last week that compresses everything down 
>>to one bit.  I'm still working on the decompression part, though.

>This is solvable.

>Hint: ask the user what was in the original file.

Better yet, just restore from the backup!

   John


-- 
-----------------------------------------------------
-  John Fehr                        -    DoD#505    -
-  umfehr06@ccu.umanitoba.ca        -    GPz550     -
-  umfehr06@silver.cs.umanitoba.ca  -  A3000 kicks! -
From: jblst5@icarus.lis.pitt.edu (Jan B Larsen)
Newsgroups: comp.compression
Subject: PKUNZIP problem
Date: 10 Apr 92 20:22:19 GMT
Reply-To: jblst5@icarus.lis.pitt.edu
Organization: University of Pittsburgh


I don`t know if this is the right place to post this question, but here
we go:

When I ftp ZIP-files from wuarchive.wustl.edu using binary mode, I allways
get this error message when I try to PKUNIZIP it on the PC:
Warning! Don't know how to handle: filename

If I ftp to my SunOS account and use UnZip (by S.H.Smith) it works just fine.

Help!

- Jan
From: joel@ce.ucsc.edu (Joel Darnauer)
Newsgroups: comp.compression
Subject: Q: Motion video files: where?
Date: 9 Apr 92 05:01:02 GMT
Article-I.D.: darkstar.32436
Organization: UCS Santa Cruz

I'm doing research in motion video compression.
Where can I get files that contain short sequences
of real video footage?  

I'm mainly looking for a few-hundred frames of 8-bit greyscale 
images containing a number of scenes.  Preferably they should
be losslessy encoded so that my results won't be biased
by the original encoding algorithms.

joel darnauer
-- 
Newsgroups: comp.compression
From: rcain@netcom.com (Robert Cain)
Subject: Re: Objective sound quality evaluation methods wanted
Date: Thu, 09 Apr 92 01:08:12 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

17 year old girls are the best sound quality evaluators known.  There is
actually a basis for this.  It represents a peak of a curve which increases
with development as perceptual circuits are built and then decreases as a
consequence of the steady loss of hearing acuity that begins at birth.
Why girls I have no idea.  So just put up a part time job notice at your
local high school's bulletin board.
-- 
Bob Cain    rcain@netcom.com   408-358-2007

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: Pkzip 1.1 to Pkzip 2.0 conversion
Date: 6 Apr 92 09:36:55 GMT
Organization: Academic Computer Centre Utrecht

In <rdippold.702324626@qualcom> rdippold@qualcom.qualcomm.com (Ron Dippold) writes:

>inde716@jane.uh.edu (92S02648) writes:
>>When the new release of Pkzip 2 comes out (whenever that may be), will there
>>be a conversion progam from the previous version of zip?  If so, will it be 
>>included in the pkzip 2.0 package?  Thanks for any help. 

>Well, if nothing else, you can use the REARJ that comes with ARJ.
>It'll also do any other conversion, including ZIP to ZIP.
>-- 
>Chemistry professors never die, they just fail to react
And if you are using REARJ anyway why not convert to ARJ 2.30/2.40 at once :-)
(sorry couldn't resist)

Nico de Vries (nevries@cc.ruu.nl  NEW ADRESS!)              

#include <std disclaimer & my personal opinion.h++>             - O   Don't
Complaints about my spelling to DEV/NUL please.                  |    worry,
This is a private (ACCU) acount and I don't speak for BITECH.   \_/   be happy!

"Save WOOD. Print on recycled paper. (You will get used to the gray, realy!)"
Newsgroups: comp.compression
From: rowlands@ra.ti.com (Jon Rowlands)
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Organization: Texas Instruments Computer Science Laboratory, Dallas
Date: Wed, 8 Apr 1992 20:19:44 GMT

In article <1992Apr8.160300.5981@tc.fluke.COM>, kurt@tc.fluke.COM (Kurt
Guntheroth) writes:
|> Is it just me or is anyone else out there concerned that we are using lossy
|> encoding "too much" as a substitute for denser storage and better
|> transmission
|> methods?
|> 
|> Analog recording and storage methods are inherently lossy, but the loss
|> depends on the quality of the recording and playback mechanisms.  As
|> mechanisms improve, the quality of the recorded, stored, and played
|> information
|> improves.
|> 
|> Digital recording and storage methods have a fixed quality that depends on
|> the way the data was encoded.  Once a format has been selected, no further
|> gain in quality is possible, only reduction in the effects of aging on the
|> digital bits.
|> 
|> Digital storage mechanisms like audio CD's force us to accept a (Nyquist)
|> limitation on the stored data, even though they encode the full imput
|> waveform.  While the conventional wisdom is that we cannot hear sound above
|> 22 KHz, this is not completely true; we are sensitive to phase changes at
|> higher frequencies.  Now proposals like PASC and audio MPEG are coming
|> along
|> that are lossy; they filter out sounds "we can't hear anyway".  We are
|> moving
|> down from being "about as good as a phonograph" to "about as good as FM
|> radio"
|> to achieve playback on media that are still undergoing rapid development.
|> 
|> It's just the same in the video world; complex formats based on removing
|> visual data "we can't perceive anyway" are multiplying.  Only it isn't
|> always true.  There are problem images, like sports and other fast motion
|> subjects.  
|> 
|> Ten or twenty years from now, when storage densities are far higher,
|> transmission facilities have more bandwidth (for instance fiber optic
|> cable to your phone and TV), and better picture tubes and amplifiers have
|> appeared (as they always have before), aren't we going to be really pissed
|> off that we accepted so much lossy encoding that we can in fact detect?
|> I hope everybody implementing this technology will think about this.  You
|> are going to have to live with your decisions.  

This is a good question. I believe that in the situations you describe, lossy
compression is the method of choice. I also believe
-- 
  _  ,                                               _
 / `- \ Jon Rowlands         phone: 1-214-995-3436 _| "--_ People say I sound
 \_--_/ rowlands@ra.csc.ti.com fax: 1-214-995-0304 \_  __/ like a corporation,
     ~ `-> Texas Instruments CSL, Dallas, TX <-?!-'  \_|  but I ain't no body.
From: jj@alice.att.com (James D. Johnston)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Date: 10 Apr 92 19:09:52 GMT
Reply-To: jj@alice.UUCP (James D. Johnston)
Organization: Signal Processing Research Department, AT&T Bell Labs

In article <D88-JWA.92Apr10140508@dront.nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes:
>No, the sampling is still made at 44,1 kHz, so you never can go
>above those 22 kHz with that signal, once quantisized.
>However, using LOSSY compression will most probably NOT retain
>phase consistency; if it did it perfectly, it would not be lossy,
>and we're talking lossy compression, not lossless.

I see two assertions here:

First, looking at the MPEG-Audio standard, the sampling rates
it's targeted for include 48kHz, making the first assertion false.
Looking at the bitstream, it's possible to define a
new sampling rate, even with the current algorithm. It's
certainly within the technology of both the encoder and
decoder, almost without thought or work, at least in the
software domain.

Second, the generalizations about lossy compression not
retaining phase are true only in the sense that added
noise can be interpreted as phase noise rather than amplitude noise.
(to a limit)  MPEG-Audio, PAC, ASPEC, PASC, MUSICAM, OCF, AC2,
and other perceptual audio compression algorithms all  have
phase-retaining modes, in fact, only MPEG-Audio, PASC, and
MUSICAM have non-phase retaining modes at high frequencies.

The coders add noise, but do not have non-linear-phase
filterbanks, so they are not compelled to add any
phase shift.

Please stick to the facts, and learn them before you 
complain.
-- 
Vote for    *Copyright alice!jj 1992, all rights reserved, except transmission
President 1992 *by USENET and like free facilities granted. Said permission is
___________________*granted only for complete copies that include this notice.
Just Say !!!NO!!!       *Use on pay-for-read services specifically disallowed.
From: An-Ly Yao <anlyyao@igc.org>
Newsgroups: comp.compression
Date: 12 Apr 92 01:26 PDT
Subject: Re: 16: 1 data compression
Nf-ID: #R:N02.22@csci1.csci.unt.edu:-1759980553:cdp:1345600002:000:337
Nf-From: cdp.UUCP!anlyyao    Apr 12 01:26:00 1992


As for compression, 0 bits may seem to be quite attractive. But I use a
compressor that generates -1 bits. I use the resulting files - obviously
to be referred to as antifiles - to recombine them with 1 bit files.
The process provides enough energy to run my pc without the need to
connect it to the mains.

highly sincerely yours
Goetz
From: obnoid@wet.UUCP (Mike Kirschner)
Newsgroups: comp.compression
Subject: Re: 16: 1 data compression
Keywords: bogus, compression
Date: 16 Apr 92 22:18:54 GMT
Organization: Wetware Diversions, San Francisco

If you'll recall, the original point of this thread is the company WEB
Technologies, and their claimed 16:1 lossless compression ratio. I just
received their marketing materials on their products and, if it's true,
we'll need to throw out all we've ever come to know, love, and hate about
lossless data compression. They claim 16:1 and better. Not only on the first 
pass, but on each subsequent pass! With 4 passes, they say that a 64MB file 
can be compressed to 994 bytes. They don't address any specific type of
binary data, but encompass it all. Encrypted files too? Can't be an April
Fool's Day joke because the Press Release is dated Feb. 1!

Mike Kirschner
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Date: 14 Apr 92 16:41:47 GMT
Organization: I.E.C.C.

>1.  People are "lowering the bar" for what is acceptable signal loss.

They sure are.  It may be morally reprehensible, but it's entirely the
case that most people would cheerfully give up signal quality for price,
convenience, or nearly anything else.  Look at VCRs vs. laserdisks.  A VHS
tape can't even record an NTSC picture without considerable loss.  Nobody
cares, except for the high end technophile market.  Or look at cable TV
which in many areas gives you a worse version of over-the-air signals than
you could get with an antenna on the roof.  People complain about cable,
but the inferior signal quality ranks far behind complaints about price,
program choice, and lousy customer service.

Or look at cassettes vs. records.  Cassettes were clobbering records long
before CDs came out, even though a totally untrained ear can easily hear
how much noisier a cassette is.  Even with CDs, the superior sound is nice,
but I believe that for most people it is equally important that they are
physically smaller than LPs, much less fragile, and allow random access.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
Newsgroups: comp.compression
From: jwl3885@zeus.tamu.edu (THIS SPACE FOR RENT)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 9 Apr 92 03:28:00 GMT
Organization: Texas A&M University, Academic Computing Services
News-Software: VAX/VMS VNEWS 1.41

In article <1992Apr8.195926.20292@uwasa.fi>, ts@uwasa.fi (Timo Salmi) writes...
>and I wish that they would change their policy.  Nevertheless there
>is no way I will accept this file to garbo FTP archives unless
>PKWare officially and explicitly sanctions such dislite programs. 
>Acquiring such a permission is up to the writer of a dislite.  We
>will _not_ be part in any compromizing situation. 

No flame intended, but I'm just curious why?  Is it illegal?  Could PKWare
have a basis for a lawsuit?  If so, on what grounds?

Cheers,
John

(Just)
(a)
(few)
(more)
(lines)
(so)
(I)
(can)
(Post!)
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: arj 2.4
Date: 15 Apr 92 16:34:08 GMT
Organization: Academic Computer Centre Utrecht

In <usgjej.703346350@gsusgi1.gsu.edu> usgjej@gsusgi2.gsu.edu (Jeffrey Johnson) writes:

>anyone know when arj 2.4 is expected....thanks

If PKZIP 2.0 is released it is supposed to follow in a few days (RJ has
it in beta now). If PKWARE keeps delaying to long it will be released 
sonner and PKWARE will have to compete with ARJ 2.50 :-)

Nico E. de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (coming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: PKZIP encryption contest
Date: 14 Apr 92 16:54:51 GMT
Organization: Academic Computer Centre Utrecht

In <1992Apr14.153223.15134@cco.caltech.edu> madler@cco.caltech.edu (Mark Adler) writes:


>Nico interprets:
>>> In other words they didn't want it to be as weak as it really is !!! This
>>> weakness is true and excisting so what is the point of the contest now?

>Actually Phil feels that it is secure enough even with the known bytes
>at the beginning of an imploded entry.  However Steve Burg talked him
>out of using an imploded one.

>So Phil thinks its secure.  But he doesn't appear certain enough about
>that to bet $1000 on it.

>Mark Adler
>madler@tybalt.caltech.edu

The main issue is how usefull this contest is. IMHO there are so many unrealistic ascpects to the contest like:
   - use of ALL 256 possible password characters (unlikely)
   - only a single file in the archive which is encrypted (uncommon)
   - special tricks to prevent PKZIP from imploding the file (strange)
It should be noted that for 99% of the users given the origional file and
the password they wouldn't even be capable of reproducing it!

Let me make clear I do think the PKWARE scheme is strong enough for real
life aplications assuming you use a long enough password. But I also think
the contest is useless except (and that is excactly the point) as a "stunt"
of PKWARE assuring there are no Brute Force problems.

I personaly think it would have been more usefull and more honest to the
PKZIP users if instead of the contest a good mini manual on password
choosing was released by PKWARE.

(btw I am aware of the fact that ARJ has even worse encryption, but for
example HPACK has much better (and yet fast) encryption so it IS possible
to do).

JMHO

Nico E. de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (coming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: PKZIP encryption contest
Organization: California Institute of Technology, Pasadena
Date: Wed, 15 Apr 1992 02:52:03 GMT


Paul Kocher notes:
>> pkzip -vt reveals that the file was stored using PKZIP version 1.1.

Well, it doesn't really reveal anything more than that the value 11 is
stored in some two-byte field.  For example, portable Zip with the -k
(Katz) option will make the file look like it was produced by PKZIP 1.1.

The real question is did PK make pkcontst.zip with the *distributed*
PKZIP 1.10, or did they use a hacked up version or some internal
utility?  Clearly this has a bearing on, for example, the expected
contents of the "random" data, as pointed out by Nico and Paul.

Mark Adler
madler@tybalt.caltech.edu
From: franti@polaris.utu.fi (Pasi Fr{nti)
Newsgroups: comp.compression
Subject: Where can I find CCITT tesdocuments?
Date: 13 Apr 92 13:51:47 GMT
Distribution: comp
Organization: University of Turku, Finland


	I'm looking for eight CCITT standard test documents.
	These documents are binary (two bit) images. Can anyone
	help me where could I look for these digidized documents?

	I also need to know  EMAIL address of Yao Wang
	(Dept. of Electrical Engineering Polytechnic University,
	Brooklyn, NY), who would propably help me about the first
	propblem. Does anybody know...?

	Thanks,

	Pasi Fr{nti / franti@utu.fi
From: cornet@duteca.et.tudelft.nl (Jan-Pieter Cornet)
Newsgroups: comp.compression
Subject: Re: DISLITE available for anonymous ftp
Keywords: DISLITE, PKLITE, ftp
Date: 14 Apr 92 01:29:30 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

me == cornet@duteca3.et.tudelft.nl (Jan-Pieter Cornet) writes:

>The filename to look for is DISLT100.LZH. You will need LHA to extract
>the program and the doc file.
Ouch... there is a *MAJOR* bug in the documentation for this version.
Please do not read this erroneous .DOC (especially the WARRANTY section).
Where was my head when I wrote that?

Anyway, you can look for DISLT101.LZH at the same sites. Also fixed
is a bug in the code, but that was unlikely to happen anyway.

>Sites:
>donau.et.tudelft.nl (130.161.144.100)
>directory pub/ (Well... it _might_ be in pub/irc/ too)

>dnpap.et.tudelft.nl (130.161.144.65)
>directory Msdos/
Or you could send a mail to the mail server there, dnpap@dnpap.et.tudelft.nl
with the body of the mail just containing "send Msdos/dislt101.lzh".

>Regards,
>-- Jan-Pieter
>cornet@duteca.et.tudelft.nl
From: schultz@halley.est.3m.com (John C. Schultz)
Newsgroups: comp.compression
Subject: Re: ZIP for a Macintosh
Date: 15 Apr 92 02:15:14 GMT
Distribution: alt
Organization: 3M Company, 3M Center, Minnesota, USA
In-reply-to: schultz@halley.est.3m.com's message of Tue, 14 Apr 92 19:10:12 GMT

I did find unzip for the Macintosh on ftp.apple.com (Thank you Archie!).  No
luck yet finding a ZIP routine however.
--
   John C. Schultz   +1 (612) 733-4047   schultz@halley.serc.3m.com
   How to include the taste of Glendronach in a multi-media system?
From: hardrock@underg.UUCP (hard rock)
Newsgroups: comp.compression
Subject: Re: PKZIP encryption contest
Date: Mon, 13 Apr 92 14:44:46 EDT
Organization: Underground Computing Foundation

Can someone please e-mail a copy of this sample zip file.  I am interested 
in trying to hack it out.  I *hope* a couple of sick days from school should 
do it. (grin)

---
Well I will see you in hell my Friend!