HDTenEightyP/NetNews huggingface dataset:
From: jj@alice.att.com (James D. Johnston)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Date: 10 Apr 92 19:18:50 GMT
Reply-To: jj@alice.UUCP (James D. Johnston)
Organization: Signal Processing Research Department, AT&T Bell Labs

In article <1992Apr10.121359.10261@cco.caltech.edu> madler@cco.caltech.edu (Mark Adler) writes:
>
>That is that many people actually believe that there is physical
>reality to the frequency domain.  The Fourier transform is a mathematical
>artifice, and nature is not obligated in any way to analyze signals in
>that way.  When you hear things like " the ear can't hear anything past
>22 KHz", this implies that Fourier components above 22 KHz can be
>removed with no loss to the signal.  This simply isn't true.  The ear
>does not do a Fourier decomposition of the signal.

Pardon me?  While, if you are using a strict reading, the
ear does not do a Fourier analysis, it does do a frequency analysis,
and due strictly to the mechanical nature of the cochlea.

This continuously varying (in basilar membrane distance) mechanical
filter makes a superb frequency analyzer.  In fact, the
distance along the basilar membrane has been characterized
repeatedly as frequency on the "Bark" or "critical band"
scale.  This characterization has been derived both from
basic masking behavior of the ear (Bertram Scharf), to 
neural considerations involving frequency of excitation (Zwislocki and
Greenwood).  Numberous other experiments have confirmed
the existance of these frequency-selective cochlear filters.
(Allen, Ghitza, Hellman, Zwicker, Hall, Schroede, and
many others.)
 
Furthermore, the higher functions after the detection of the
signal on the basilar membrane make even tighter and
much more accurate detection of frequency.  If you doubt this,
check out Brian C. J. Moore's book on an introduction to
hearing.

Given this, your blanket assertion, presented as fact, that
there is no physical reality to the frequency domain, is 
shown as utterly false, by the counterexample of the human
hearing apparatus.  It is in fact shown more than false,
it is shown as exactly opposite the facts.

Please, gentlefolk, refrain from making blanket statements
of such an utterly false nature in such a presumptive,
authoritative fashion. It demeans science, and also provides
ammunition to those who would replace science with
superstition.
-- 
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: d88-jwa@hemul.nada.kth.se (Jon W{tte)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Date: 8 Apr 92 20:52:21 GMT
	<1992Apr8.160300.5981@tc.fluke.COM>
Organization: Royal Institute of Technology, Stockholm, Sweden
Originator: d88-jwa@hemul.nada.kth.se

.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?

   ...

   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?


Why should we ? The original tapes are still broadcast quality;
it's only consumer media that gets the degradation.

Are you mad at your scratchy vinyls just because CDs aren't
scratchy ? Digital technology was available when the compact
cassette was introduced; the first compact cassettes sounded
like SH*T but were still used; are you pissed at compact
cassettes ?

Each thing has its use.

-- 
h+@nada.kth.se; Jon W{tte, the Diplomat - NOT!
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.compression
Subject: Re: PKZIP encryption contest
Date: 12 Apr 92 21:13:28 GMT
Organization: University of Vaasa, Finland

In article <1992Apr12.125448.6667@ugle.unit.no> thaco@solan.unit.no writes:
>shold I send my file? Do PKZIP have any Internet addresses?

They have a Compuserve address.  I recently posted it, and you can
also find it in garbo.uwasa.fi:/pc/pd2/author02.zip along with many
other useful MsDos PD & SW authors' addresses.

...................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
From: umfehr06@ccu.umanitoba.ca (John Fehr)
Newsgroups: comp.compression
Subject: Re: PKZIP encryption contest available from garbo
Date: 11 Apr 92 21:06:12 GMT
Organization: University of Manitoba, Winnipeg, Canada

Is the encryption in the older PKZIP's the same as what is used in the
contest?  (Do I need to find the latest version of PKZIP?)  Also, does 
anyone know the location of a pk(un)zip for unix and/or amiga?
   Thanks
    John


-- 
-----------------------------------------------------
-  John Fehr                        -    DoD#505    -
-  umfehr06@ccu.umanitoba.ca        -    GPz550     -
-  umfehr06@silver.cs.umanitoba.ca  -  A3000 kicks! -
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: PKLITE, DIET, LZEXE continued
Date: 6 Apr 92 15:02:11 GMT
Organization: Academic Computer Centre Utrecht

Besides the response below. I uploaded DISLITE to garbo which is capable
of reversing PKLite -x like mentioned in my previous subjection. People
told me this would be usefull to allow virus checking of those .EXE files
and also for recompressing it with e.g. DIET.

In <1992Apr6.120541.134@mble.philips.be> stern@mble.philips.be writes:

>In article <2310@accucx.cc.ruu.nl>, nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>> Comparission between PKLITE, DIET and LZEXE.
>>...
>> "Save WOOD. Print on recycled paper. (You will get used to the gray, realy!)"

>Here are the result of a one-file comparing test I did;
>the file is the MAKE.EXE from the Borland C++ 2.0
>I ran the exec file automatically a lot of times (with no real execution)
>on a 33-MHz 386DX from a RAM-disk.

>PKLITE 1.13, LZEXE 9.1, DIET 1.20 (not resident)

>                  Normal file         diet            lzexe          pklite
>size                 41147           24324            24837          24187
>exec time            19''            55''             34''           33''

>Did I miss something to have a so bad decompression time with diet ?
Well I wouldn't call 1% less file size bad (especially since the diskspace used
by the two is the same (at least 48 512 byte sectors). My figure is the
avarage of a large collections of reletively small files (MS-DOS 5.0 files)
and I don't claim DIET being better on all files. The larger the file perhaps
the better PKLite but large files often contain overlays and they can't be
compressed anyway.
I suppose compression ratio depends on the nature of the data. Number of
0 filled blocks. data/code ratio etc. It is almost impossible to find
a true 100% benchmark. I hope in general my conclusions are right (I got
lots of mail indicating this).


Nico de Vries (nevries@cc.ruu.nl)              

#include <std disclaimer & my personal opinion.h++>     - O   Don't
Complaints about my spelling to DEV/NUL please.          |    worry,
I work for BITECH, I don't SPEAK for BITECH.            \_/   be happy!
From: cornet@duteca.et.tudelft.nl (Jan-Pieter Cornet)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 9 Apr 92 10:36:53 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

sean@ms.uky.edu (Sean Casey) writes:

>In article <1992Apr8.195926.20292@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>: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.
Hmm...

>I don't understand. Does Pkware own a patent that the decompressor is
>infringing upon? Or did you find Pkware code in DISLITE? Or perhaps
>the author is under some sort of non-competition contract with Pkware?
I signed nothing with PKWARE. I did not use PKWARE code. I am not aware
of any patent infringement caused by the decompressor. As also noted in
the DISLITE docs, I use the decompressor build into the executable to
decompress it, so DISLITE has a debugger inside it, not a decompressor.

>Is there some other reason an author should be required to
>obtain permission from Pkware before writing a decompressor?
I couldn't think of one.

PKware doesn't make the law, if they make an "undecompressable" compressor,
that virus programmers can exploit, do we have to just sit by and watch?

>I'm really curious about this.
How do you think I feel about it? ;)

-- Jan-Pieter
cornet@duteca.et.tudelft.nl
 
PS. I programmed DISLITE (in case anyone still didn't understand ;)
Newsgroups: comp.compression
Subject: Re: Strange Zip file.
From: gilf@vms.huji.ac.il (GIL FREUND)
Date: 7 Apr 1992 22:08 IDT
Distribution: world
Organization: The Hebrew University of Jerusalem
News-Software: VAX/VMS VNEWS 1.41    Lines: 12

In article <2325@accucx.cc.ruu.nl>, nevries@accucx.cc.ruu.nl (Nico de Vries.) writes...
>
>There are two possibilities. The program is compressed with PKZIP 1.93 (beta
>version) or with PKZIP 2.01 (cracked fake version). You are probably using
>PKZIP 1.10 which is not capable of handling those.
>
Sure enough it was ziped using PKZIP 1.93. Rather stupid, I should think, why
can't people wait for a formal upgrade... I have know someone over here who
couldn't wait for Version 6.0 of the norton utilities, so he pirated an alpha
version (!). Guess what, he managed to low level format his IDE drive (RIP).

Gil
From: thom@f517.n107.z1.ieee.org (Thom Henderson)
Newsgroups: comp.compression
Subject: Re: Where is the new PKZIP?
Date: 9 Apr 92 22:58:00 GMT
Article-I.D.: zeus.13569.29E7AF42
Organization: FidoNet node 1:107/517 - SEAboard HST, Clifton NJ


 # Hmm... If my memory serves, didn't SEA *win* that lawsuit?  

Yes, we did.  We were not, however, prepared for the PR campaign which
followed.  

This seems to be what happens when a small company sues a larger company and
wins.  

--- SEAmail 1.10
 * Origin: System Enhancement Associates  (107/517)
--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Thom Henderson - Internet: thom@f517.n107.z1.ieee.org
Newsgroups: comp.compression
From: jj@alice.att.com (James D. Johnston)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Date: 10 Apr 92 19:31:38 GMT
Reply-To: jj@alice.UUCP (James D. Johnston)
Organization: Signal Processing Research Department, AT&T Bell Labs

In article <1992Apr10.121359.10261@cco.caltech.edu> madler@cco.caltech.edu (Mark Adler) writes:
>
>Even though it is not
>essential to this argument, the current research indicates that the ear
>has a rather novel non-linear decomposition that can locate high frequency
>signals in time accurately and low frequency signals in amplitude (sooner
>or later we end up talking in terms of "frequency" since that's all we've
>known how to analyze for the last few hundred years--maybe wavelets will
>expand our viewpoint somewhat).

I find this statement also very provoking, and at least somewhat
inaccurate.  High frequency stationary signals have been shown time and
time again to gain localization strictly from amplitude, while
stationary lower frequency (less than 1kHz or so) signals can
gain significant localization information from phase.

These results are neither new nor in dispute.

It is also true that short-time, non-stationary signals
can be shown to localize very strongly by time-information.
This is neither contradictory to the previous two paragraphs
nor surprising, given the binaural nature of the hearing
apparatus.

A classic example of the localization on stationary signals can
be found in Moore's book, in Chapter 5, regarding Binarual
Masking Level Differences, which are large at low frequencies,
and nearly unobservable at high frequencies.

Again, I beg of you, please be sure whatyou are saying before
you make authoritarian statements.

As to the ear being extremely non-linear in amplitude, we agree
entirely.  This non-linearity in no way refutes the basic function
of the cochlea/basilar membrane/auditory cortex as a superb frequency
analyzer.
-- 
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: jj@alice.att.com (James D. Johnston)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Date: 10 Apr 92 19:03:03 GMT
Reply-To: jj@alice.UUCP (James D. Johnston)
Organization: Signal Processing Research Department, AT&T Bell Labs

In article <1992Apr9.024700.408@csc.ti.com> rowlands@ra.ti.com (Jon Rowlands) writes:

>3. Forwards prediction. All the lossy audio, image and video compression
>schemes such as JPEG, MPEG audio and video and CCITT H.261 are forward
>predictive systems, meaning that the encoder alone makes the decision about
>which components of the signal are imperceptible. This inherently allows
>for full forwards and backwards compatibility with future improvements in
>compression algorithms and computationally more powerful encoders.

This is the only part I can't  agree with.  The current MPEG, JPEG,
and CCITT Px64 ALL place significant limits on the compression 
ability of the algorithms withe their choice of filter bank,
bitstream methodology, and such.  There can, will, and is technology
of the same complexity that works better.  Such are standards.
-- 
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.
Newsgroups: comp.compression
From: keithd@versyss.uucp (Keith Doyle)
Subject: Re: No AV number for SCANV89B.ZIP , VSHLD89B.ZIP etc...
Reply-To: keithd@versyss.UUCP (Keith Doyle)
Organization: VERSYSS Incorporated, Torrance, California
Date: Wed, 8 Apr 1992 20:21:53 GMT

In article <1992Apr3.041603.19906@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>It is like Keith said.  The "euro"-version pkz110eu.exe does not
>have encryption.  This is because of some totally unrealistic and in
>practice unenforcable US policy on encryption algorithms, and
>obviously -AV relies on that.  

BTW, did anyone else happen to notice that complete crypt source code that
just floated by in comp.sources.somethingorother that was posted from 
Australia?  Guess the cat is out of the bag now, eh?

Keith Doyle
From: cornet@duteca3.et.tudelft.nl (Jan-Pieter Cornet)
Newsgroups: comp.compression
Subject: Re: PKLite & CRC Check / Viruses
Keywords: PKLITE, CRC, Virus
Date: 15 Apr 92 00:35:40 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

bartlett@oasys.dt.navy.mil (Scott W. Bartlett) writes:
>This is a question regarding if/how/when PKLITE does a CRC check on a 
>compressed program file.

>      - does PKlite check the CRC of the .EXE file before decompressing

>      - OR does it check the CRC of the decompressed program image before
>           running it ?
I hope this can be adequately answered by: What CRC?

To my knowledge, there is no CRC whatsoever in the compressed image
(as upto PKLITE 1.13)

>The thought is that Macfee's SCAN/VSHIELD program would check the CRC of the
>compressed .EXE file and not run it if it was infected with a virus. BUT if
>the file was infected with a stealth virus then the .EXE CRC will come up ok,
This is the special "McAfee-signature" you are talking about now, I presume?
Stealth virii are exactly the weakness of this checking scheme.

>but then PKlite would flag the decompressed program as failing a CRC check. 
>This only works if PKlite checks AFTER decompressing.
I do not know exactly how the "McAfee-signature" on .EXE files work, but
I would dare a guess that it will not be found anywhere in memory after
loading the executable. PKLITE does not (re-) access the executable.
The compressed program image is loaded at the same time as the build-in
uncompressor. Therefore PKLITE can never access, let alone verify, the CRC
you mention.

Note, however that it is "virtually impossible"(1) to infect the compressed
PKLITE image after it has been compressed. Infecting the uncompressor
program itself, however, is trivial, but this can be normally scanned
using a virus scanner.

Regards,
-- Jan-Pieter
cornet@duteca.et.tudelft.nl

Note (1): "virtually impossible". I think it is possible, but it would
require such a specialized virus, and it would involve such an enourmous
amount of work, that I severly doubt whether this is at all feasable
given the "virus engineering constraints".
Newsgroups: comp.compression
From: u6637ap@vms.ucc.okstate.edu
Subject: Re: 16: 1 data compression
Organization: Oklahoma State University Computer Center
Date: Mon, 13 Apr 1992 18:22:55 GMT

In article <1213@lysator.liu.se>, boberg@lysator.liu.se (Stefan Boberg) writes:
> N02@csci1.csci.unt.edu (Orion) writes:
> 
>>I invented a compression algorithm last week that compresses everything down 
>>to one bit.  I'm still working on the decompression part, though.
> 
>   Hah! That's trivial! I've invented a method to compress files to 0 bits
> Yes, that's right: ZERO BITS! It's called `delete', or `rm' depending on
> which version you have. Now I'm going to sue Apple for 10 Billion dollars
> because they haven't paid the license fee for the MacOS TrashCan! They
> stole my code and I'm NOT going to let them get away with it! Those
> MacDweebs sure aren't going to get away with this one.
> 
>   Of course, I still haven't figured out how to decompress either, but 
> thats a completely different story.. I'll let you know when I'm done. :-)
> 
> --
> --
> Stefan Boberg - AP & EE student at Linkoping Institute of Technology, Sweden
> Author of LhA, ArjA and LhArcA. Co-author of Alien Breed, Project X, Full
> Contact and Miami Chase.

Decompression is EASY! Simply use the UNDELETE command... AMAZING how easy
this is... :-)

--
Barry Boone - EE student, Oklahoma State University, Stillwater, Okla.
"Gravity: It's not just a good idea, its the law."
From: jblst5@icarus.lis.pitt.edu (Jan B Larsen)
Newsgroups: comp.compression
Subject: Re: PKUNZIP problem
Date: 12 Apr 92 23:50:06 GMT
Reply-To: jblst5@icarus.lis.pitt.edu
Organization: University of Pittsburgh

In article 13042@cco.caltech.edu, madler@cco.caltech.edu (Mark Adler) writes:
>
>>> Probably you have UnZip 4.2 whoch I believe is capable of handling PKZ1.93
>
>Nope, it doesn't.  Unzip 4.2 still only handles shrunk, reduced, and imploded
>entries.  Unzip 5.0 (out Real Soon Now) will handle deflated entries as well.
>
>Mark Adler
>madler@tybalt.caltech.edu


Actually, I have UnZip v4.1 of 5-13-91. I guess this version only is capable
of handling PKZ1.10.
Any other possible solutions to my problem?

- Jan
From: mas@mdavcr.mda.ca (Michael Smayra)
Newsgroups: comp.compression
Subject: Fractal Image Compression
Keywords: fractal
Date: 16 Apr 92 23:23:27 GMT
Organization: MacDonald Dettwiler, 13800 Commerce Parkway, Richmond, BC, Canada  V6V 2J3


Hello everybody,

I'm looking for a good introduction to fractal image compression.
A journal, conf. papers, and books that talk about Fractal Image
Compression would be greatly appreciated.
Also, I would like to know if there are any public domain algorithms for
this compression scheme.

In return, I will post a summary on the net summarizing the info sent to me.

Thank you in advance,
-Michael
michaels@fs0.ee.ubc.ca     or    mas@mda.ca

Newsgroups: comp.compression
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: Re: PKZIP encryption contest
Organization: DSG, Stanford University, CA 94305, USA
Date: Sun, 12 Apr 92 19:42:30 GMT

In article <1992Apr12.125448.6667@ugle.unit.no> thaco@solan.unit.no writes:
>After 115000 tries a file dupmped at my HD called BREAKME.DAT. How
>the hell can I know if this is the right file?  Is there any chances
>that PKUNZIP would let me unpack with the wrong password? Where 
>shold I send my file? Do PKZIP have any Internet addresses?

I'm afraid you've only found a key that passes the 16-bit checksum in the
encryption header.  One wrong password in 65536 will do this.  (If anyone
wants a list of a couple hundred passwords that pass the initial check,
I would be happy to run zipcrack crunch on the header for an hour and
post the results.)  But these passwords won't pass the CRC test (well,
actually one in 4 billion will...there are an average of 256 these...)

You'll note that pkzip could NOT COMPRESS THE CONTEST FILE.  Something
fishy is going on if pkzip can't find any compressable sequences in the
data.  For all we know, they are feeding us the output of a random-number
generator or other unrecognizable junk (pkzip is a good compressor, and
any ordinary/recognizable data would have been compressed).  While it's
possible that they shut off the compressor (you have to hack PKZIP to do
this) there is no mention of this in the contest docs.  Because the
encryption works by XORing the data with its 32-bit keys (see APPNOTE.TXT),
random bytes going in will make random bytes come out, and the whole thing 
becomes meaningless.  To make this a real challenge, PKWARE should accept
any user-supplied file, encrypt it, and send back the output...

-- Paul Kocher

________kocherp@leland.stanford.edu_________kocherp@jacobs.cs.orst.edu________
I am an undergrad at Stanford seeking summer work or contract jobs programming
(IBM PC), doing technical writing, or assisting with research. Send e-mail for
resume if interested!  - Paul Kocher/Box 13554/Stanford CA 94309, 415/497-6438
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: PKUNZIP problem
Date: 11 Apr 92 16:58:16 GMT
Organization: California Institute of Technology, Pasadena


>> Probably you have UnZip 4.2 whoch I believe is capable of handling PKZ1.93

Nope, it doesn't.  Unzip 4.2 still only handles shrunk, reduced, and imploded
entries.  Unzip 5.0 (out Real Soon Now) will handle deflated entries as well.

Mark Adler
madler@tybalt.caltech.edu
Newsgroups: comp.compression
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Too much lossy encoding?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 11 Apr 1992 05:46:36 GMT

madler@cco.caltech.edu (Mark Adler) writes:
+---------------
|                          ...the current research indicates that the ear
| has a rather novel non-linear decomposition that can locate high frequency
| signals in time accurately and low frequency signals in amplitude (sooner
| or later we end up talking in terms of "frequency" since that's all we've
| known how to analyze for the last few hundred years...)
+---------------

How true. And the ear's "novel non-linearities" can be used to cute effect.
Several years ago a friend of mine discovered that even though "humans can't
hear 40 KHz", in fact humans *can* demodulate baseband (300-3000Hz) audio
AM modulated on top of 40 KHz audio. So he built a nice little high-power
ultrasonic driver, with modulator, and started playing. The cute thing is
that the victim\\\\\\ experimental subject is able to hear the baseband
signal, but cannot locate it, as all the directional cues come from the
loudness of the 40 KHz carrier. And in a normal room, there are so many
echos that you get lots of standing waves ("ghosts", so to speak). A *very*
small motion of one's head is enough to make the apparent source of such
a signal jump across the room. Some people get very upset listening to this...


-Rob

Newsgroups: comp.compression