HDTenEightyP/NetNews huggingface dataset:
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: DELETE PROTECTION AND FILE FIX UNDER ON-THE-FLY COMPRESSION
Date: 13 Aug 92 12:00:46 GMT
Organization: Academic Computer Centre Utrecht

In <1992Aug11.172604.29703@ncsu.edu> Webbge@che17.ncsu.EDU (Greg Earl Webb) writes:

>The program stacker creates a device driver that emulates your hard disk
>drive.  This emulation makes stacker ALMOST indectable (i.e. anything
>you can do in DOS you can do on this device driver).  I have heard of

Almost true. One thing to keep in mind is that Stacker can wipe clear
unalocated clusters to allocate new space for allocated clusters. This
is needed to make sure the disk does not fill up in time. Since e.g.
erase protection from Norton does not actually dealocate clusters on
delete (the deleted fiels are placed in a hidden trashcan) it keeps
working flawlessly but less secure systems (old quick underase, PCTOOLS
unerase etc) become more dangerous under Stacker.

>complaints from other people, but in my experience I have had no problems
>working with stacker under dos 5.0.  Even Norton utilities recognizes the
>stacker drive and gives it special treatment.

What special treatment does Norton give? I fail to see any.

>Stacker drawbacks are this: it slows the drive down considerably.

Is strongly computer and hard disk speed dependent. Speed ups are
possible as well.

>Stacker benefits:  Stacker has allowed my a 1.6:1 compression.  It would
>be better, but I keep a lot of pkzip and pklite files on my hard drive
>which stacker cannot compress.

1:2.0 is not just an ad figure. I have a FOXpro drive which gets 1:3.0. No
unusual data is present on it (for FOXpro).

>I also have a question: does anyone know of an easy way to get stacker
>on and off the hard drive without causing any major problems?

No :-). Installing and removing Stacker is a disaster IMHO. Once running
it is a reliable, nice product. The only reason I no longer use it
on my main harddisk is OS/2 2.0 does not (yet) support it. (An OS/2 version
seems to be in beta BTW).

Also notice programs like DiskDoubler and XtraDrive BTW. PKWARE is working
on a own version as well I believe. All of these might install/uninstall
better (can't be worse).


Nico E. de Vries
_ _
O O  USENET nevries@cc.ruu.nl  FIDO 2:281/708.1  COMPUSERVE "soon" ???? 
 o   This text reflects MY opinions, not that of my employer BITECH.      
\_/  This text is supplied 'AS IS', no waranties of any kind apply.      
     Don't waste your time on complaining about my hopeless typostyle.

"I would admit my mistakes, if I had any ..."  (Bumper Sticker)
From: hnr@ecs.soton.ac.uk (Harvey Rutt)
Newsgroups: comp.compression
Subject: Compression hardware, compressed stereo images.
Date: 17 Aug 92 13:34:03 GMT

As a NON specialist in this area, I would be grateful for information
on the following.

i. For normal monochrome video signals what commercial hardware is available to
compress and decompress the digitised signal in real time. Chipsets? Complete
hardware? Is it available at all? For what video standards?

ii. For algorithms entailing some information loss is there any
information on the effect of the resulting 'errors' in the
decompressed images on the use of stereo image pairs? 

Thanks in advance,
Harvey Rutt, Southampton UK
From: lip@s1.gov (Loren I. Petrich)
Newsgroups: comp.compression
Subject: HDTV and Teleconferencing Standards?
Date: 20 Aug 92 12:32:48 GMT
Organization: LLNL


	Does anyone know where one can find draft copies of proposed
HDTV standards?

	What would be the most interesting to me are:

	Horizontal and vertical dimensions in pixels [I presume that
the pixels include all three colors and are square].

	Number of frames per second.


	Also, I'd like to find out teleconferencing standards -- what
dimensions and frame rate for teleconferencing TV, and what target
bandwidth and other performance standards.
Newsgroups: comp.compression
From: u343167@twncu865.ncu.edu.tw
Subject: ??
Organization: Computer Center, NCU, Taiwan, R.O.C.
Date: Fri, 21 Aug 1992 14:28:23 GMT

Hi,friends:
   dos.es anyone know what is the .TZR file type?
and where can find the corresponding uncompress program?
Thanks!
Newsgroups: comp.compression
From: jpl@fct.unl.pt (Joao Prospero Luis [ps])
Subject: JBIG
Organization: Universidade Nova de Lisboa -- Lisbon, Portugal
Distribution: comp.compression
Date: Wed, 19 Aug 1992 11:43:35 GMT


Hello, 

Where can I find information about JBIG ? I have already read the FAQ but
there isnt enough information there.

Please mail and I will post if enough interest shown.

Thanks in advance,

		JPL
--
Joao Prospero Luis                | BITNET/Internet: jpl@fct.unl.pt
Universidade Nova de Lisboa       |            UUCP: jpl@unl.uucp
FCT - Dpto. de Informatica        | Fax:   (+351) (1) 295-5641
2825 Monte Caparica, PORTUGAL     | Phone: (+351) (1) 295-4464

Newsgroups: comp.compression
From: Giovanni Resta <resta@iei.pi.cnr.it>
Subject: Help on the LZRW family
Organization: IEI-CNR Pisa (Italy)
X-Useragent: Nuntius v1.1
Date: Wed, 19 Aug 1992 10:21:09 GMT
X-Posted-From: mac-resta.iei.pi.cnr.it
X-Posted-Through: sol.ctr.columbia.edu

Hi,
I have runned the LZRW3-A program (cited in the FAQ) on a Mac, with
a main() doing only a compression and a decompression, in memory,
and testing if the final size of the 
compressed-then-decompressed file was OK. To have a portable code
I did not use the 68000's fast_copy routine.
The program worked.

Then I tried to run it on a MSDOS machine, same code, same main(),
changing just a little the file port.h.

The program does not work: the size of the 
compressed-then-decompressed file is different from the original size!!

Has anybody experienced something similar (and know why) ? 
Has anybody a MSDOS-working version of LZRW3 or LZRW3-A, together with
the appropriate *.h files and a mini-example of procedure calls?

If ANSWER=YES please let me know or send me the files at
Giovanni Resta 
resta@iei.pi.cnr.it

Thanks!
Newsgroups: comp.compression
From: ttw@beta.lanl.gov (Tony Warnock)
Subject: Re: Compression technique mentioned in PCW
Keywords: snake oil, something for nothing
 
 
   I think that the letter writer wants to use the fact that
   127/1000 is nearly equal to 7/55 (=.1272727..) which is the
   closest 3-digit fraction. That is, if one knows that 3 digits
   are needed, then 7/55 allows recovery of the information and
   perhaps the 7/55 can be stored with fewer bits than 127/1000.
 
   There is always a fraction p/q that approximates an arbitrary
   real X with error less than 1/q**2. The problem is that as
   X ranges between 0 and 1, p ranges between 1 and q-1 so the
   same number of bits are needed to transmit both p and q as
   to transmit X.
 
                           Tony Warnock
 
 
                                        Less is more.
                                      - Robert Browning (1812-1889)
Organization: Los Alamos National Laboratory
Date: Wed, 19 Aug 1992 14:27:45 GMT

Newsgroups: comp.compression
From: maddie@crash.cts.com (Tom Schenck)
Subject: ARJ de-compressing...
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 18 Aug 92 23:17:27 PDT

Howdy. I'm a Game Developer, and I'm looking for a way to save myself some
space on the cartridges we develop for. I've noticed that ARJ has the overall
best compression I've seen so far, and was wondering how I could go about
getting the source to de-compress ARJ files?

Thanks in advance,
Tom Schenck
Knight Technologies
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: Compression technique mentioned in PCW
Date: 19 Aug 92 12:37:04 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Aug18.173306.742@news.uiowa.edu>, williams@herky.cs.uiowa.edu (Kent Williams) writes:

| This sounds like arithmetic compression.  Some people who don't care about
| compression time or memory usage have come up with really effectic arithmetic
| compressors.

  There are applications for which the effort to compress is not
important, as long as it is possible. These usually involve
distributions. For example, when I distributed comp.binaries.ibm.pc, zoo
was chosen as the compressor because it did a better job than zip in
terms of the output fileszie. The same would hold true for a vendor
distributing commercial software on floppy, where the savings of one
disk can be a significant reduction in production, storage and shipping
costs.

  Packing files for distribution on a BBS is another example, although
many sites there have elected to use zip because of the speed advantage
over zoo/lha. The BBS has no incentive to make the file a little
smaller, because the cost are not bourne by the system doing the
compression.

  Usenet news is still using compress because it's fast, and because
major feeds are usually done uncompressed over WAN. Feeds to small
systems by phone are often done over modems at least 4x faster than were
in use three years ago, and the compression in the modems is such that
it may be easier to run the feed uncompressed, if disk space permits.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.compression
Subject: Re: Compression technique mentioned in PCW
Summary: You can't win.
Keywords: golden ratio
Date: 20 Aug 92 03:14:52 GMT
Reply-To: Joe Keane <jgk@osc.com>
Organization: Versant Object Technology, Menlo Park, CA
Weather: sunny, high 75, low 55
Moon-Phase: waning gibbous (63% of full)

In article <1992Aug18.155518@sees.bangor.ac.uk> mather@sees.bangor.ac.uk (Paul
Mather) writes:
>However, in the compression scheme mentioned in the letter, instead of
>using a stout piece of oak :-), the decimal fraction was compressed by
>determining two numbers, a and b, such that a/b = N.  To transmit the
>original file, one need only transmit a and b.  Decompression would
>involve calculating a/b and enumerating the result.

>When my friend asked me what I thought of the proposed method, my gut
>reaction was to say that finding the values of a and b sounded pretty
>intractable to me.  It also occurred to me that it was likely that for
>some N the enumeration of the integers a and b could be longer than N
>itself but my number theory is very rusty so I didn't speculate on that
>to my friend. :-)

This trick of turning decimals into rationals doesn't buy you much.  Of course
you should suspect that, since if it worked all the time, you would have a
general method of compressing anything.  The only exception i can think of is
that if you know your digits string ends with a repeated pattern, then you may
be able to get some gain.  But then there are simpler ways to take care of
this case.

We want to find the smallest p and q such that p/q starts with a given string
of digits.  This is a simple exercise in continued fractions.  You can look up
theorems about approximating with rationals to see how big we expect p and q
to be.  The answer is that if you want to match N digits, the length of p and
q will usually be around, surprise surprise, N/2.

--
Joe Keane, amateur mathematician
jgk@osc.com (uunet!amdcad!osc!jgk)
Newsgroups: comp.compression
From: wyman@rtsg.mot.com (Mark S. Wyman)
Subject: Re: John Toebes' Dealings With W. E. B. Technology
Keywords: WEB Technologies 16: 1 compression
Organization: Motorola Inc., Cellular Infrastructure Group
Distribution: na
Date: Fri, 14 Aug 1992 15:46:42 GMT

Hey!!!! I think I bought some swamp land from that Earl
character!! :)

Mark
From: leo@ipmce.su (Leonid A. Broukhis)
Newsgroups: comp.compression
Subject: *** Latest patch of Freeze/melt compression program
Keywords: algorithm reference freeze
Date: 19 Aug 92 12:50:58 GMT
Reply-To: leo@ipmce.su
Organization: unknown


	Hello all,

Several days ago I've posted patch 5 for freeze 2.3. There is a new idea
used in the string matching part of the algorithm and I forgot to mention
the author of the idea:

	kadach@isi.itfs.nsk.su (Andrew Cadach)

This message should be treated as an official reference until the
next patch.
-- 
	Leonid A. Broukhis
From: thom@f517.n107.z1.ieee.org (Thom Henderson)
Newsgroups: comp.compression
Subject: OS/2 compression
Date: 20 Aug 92 02:01:00 GMT
Organization: FidoNet node 1:107/517 - SEAboard HST, Clifton NJ


 # Along that vein, has anybody heard of any announcement for a
 # PKZip for OS/2?

There is an OS/2 version of ARC, including a program to make OS/2 self-extracting archives.  

--- SEAmail 1.20
 * Origin: System Enhancement Associates  (107/517)
--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Thom Henderson - Internet: thom@f517.n107.z1.ieee.org
From: rol@grasp1.univ-lyon1.fr (Paul Rolland)
Newsgroups: comp.compression
Subject: ZIP Algorithms Wanted
Keywords: PKZIP, Algorithms
Date: 20 Aug 92 00:30:44 GMT
Article-I.D.: grasp1.16ub1kINNdl6
Organization: INSA Informatique, Lyon, France
NNTP-Posting-Host: grasp1.univ-lyon1.fr

Hi Folks,

	Because I'm trying to developp an universal PKWare compatible
compressor decompressor, I'd like to get as much information as possible
concerning the differents systems supported by PkZip (information related to
file attributes,...).

	What's more I'd like to have the Ziv-Lempel-Welch and Shannon-Fano Tree
algorithms for compression and decompression. I already have a program that can
displays all the informations contained in a ZIP file, and suppress a file (or
more) from an archive. Next step will be file extraction, and then compression.

	Thanks in advance for your help,
	Paul Rolland
	rol@grasp1.univ-lyon1.fr

	PS : I'd prefer answer using Email rather than news, but if required,
	I'll summarize for the Net.
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: [Commercial?] Text/Speech Publishing?
Date: 13 Aug 92 12:11:01 GMT
Distribution: comp
Organization: Academic Computer Centre Utrecht

In <LAWS.92Aug11115949@sunset.ai.sri.com> laws@ai.sri.com (Kenneth I. Laws) writes:

>Hi!

>A friend is thinking of adding a floppy or CD ROM
>to a textbook on speech analysis and natural language
>processing.  She'd like to know what compression
>technology is readily available for packing text,
>speech clips, and perhaps music/songs onto digital
>media.

Probably non-destructive compression is wanted. For text this is trivial,
for analyzable audio this is the common way to go. The program ARJ seems
to me the best choise currently available to do the job. It is available
on garbo.uwasa.fi etc. 

The compression of audio can be inproved by pre/post processing it. A simple
program taking differences is enough. e.g. the sample 234 236 236 236 233
231 would become (234) +2 0 0 -3 -2. 

>Leads to commercial services or to university software
>would be helpful.  Does anyone on comp.compression
>have experience with these matters?

Why do you think it is called comp.compression :-). 

>Dr. Kenneth I. Laws, (415) 493-7390, laws@ai.sri.com.


Nico E. de Vries
_ _
O O  USENET nevries@cc.ruu.nl  FIDO 2:281/708.1  COMPUSERVE "soon" ???? 
 o   This text reflects MY opinions, not that of my employer BITECH.      
\_/  This text is supplied 'AS IS', no waranties of any kind apply.      
     Don't waste your time on complaining about my hopeless typostyle.

"I would admit my mistakes, if I had any ..."  (Bumper Sticker)
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: ARJ de-compressing...
Organization: University of Vaasa, Finland
Date: Wed, 19 Aug 1992 10:25:57 GMT

In article <1992Aug18.231728.18639@crash> maddie@crash.cts.com (Tom Schenck) writes:
>best compression I've seen so far, and was wondering how I could go about
>getting the source to de-compress ARJ files?

Take a look at

 50619 Oct 22  1991 garbo.uwasa.fi:/unix/arcers/unarj221.tar.Z

and / or

 13567 Aug  5 15:12 garbo.uwasa.fi:/pc/pd2/author10.zip

..................................................................
Prof. Timo Salmi
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: lindholm@ucs.ubc.ca (George Lindholm)
Subject: Reading incomplete zip files
Organization: University Computing Services, UBC, Canada
Date: Thu, 20 Aug 1992 01:02:56 GMT

Is there any way to extract any information from an incomplete zip file?
My disk filled up during the transfer and I would like to avoid having to 
do the transfer again unless I have to. Thanks

   George

-- 
George Lindholm                                  phone:    (604) 822-4375
University Computing Services, UBC               fax:      (604) 822-5116
6356 Agricultural Road, Vancouver, B.C., Canada  internet: lindholm@ucs.ubc.ca
V6T 1Z2                                          bitnet:   USERGNL@UBCMTSG
Newsgroups: comp.compression.research
From: rjohnson@shell.com (Roy Johnson)
Subject: Sound and Light
Organization: Houston, TX
Distribution: comp
Date: 12 Aug 92 10:44:18

Has there been any audio compression done that locates and stores
peaks in the sound wave and reconstructs the wave with splines?

How feasible do you think such a technique is?

Would there be an analogous method for 2-d data (like the DCT is
to FFT)?

Thanks,
Roy
--
Roy Johnson, Shell Development Company (but speaking for myself)

Newsgroups: comp.compression.research
From: al045@cleveland.Freenet.Edu (Gergely Tapolyai)
Subject: Moffat
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Tue, 18 Aug 92 01:29:39 GMT


I am looking for all references to PPM compression in any form
or shape.  I am looking in particuliar, for A Moffat's 1988 paper
on PPMC' discussions.
Thanks,
-- 
TAPOLYAI, Gergely                al045@cleveland.freenet.edu
                                 Cleveland, Ohio U.S.A.
From: kpatel@woodstock.cs.berkeley.edu (KETAN DASHARATH PATEL)
Newsgroups: comp.compression.research
Subject: MPEG decoder
Keywords: MPEG
Date: 20 Aug 92 18:28:08 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: woodstock.cs.berkeley.edu

Hi out there.
I am currently working on an mpeg decoder and am coming across the 
inevitable snags. I was wondering whether or not there are a lot of
other people doing this kind of work (i.e. mpeg decoders) and if
there was any interest in starting comp.compression.mpeg or perhaps
an e-mail list so that we could share our problems, sources, and 
solutions. 

Also, although the XING mpeg files have been helpful, are there any
sources of data that more strictly adheres to the standard?

Finally, does anyone have any suggestions on efficient methods of 
choosing an RGB colorspace that will facilitate conversion from
the compressed YCrCb data? Or even the proper matrix to use for
straight MPEG YCrCb -> RGB conversion? 

Thanks in advance.

ketan patel
kpatel@postgres.berkeley.edu
From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.compression.research
Subject: EEG data compression
Date: 17 Aug 92 13:46:55 GMT
Organization: CSD., University of Erlangen, Germany

Has anyone a pointer to a good compression method for electro encephalogram
recordings (multichannel). An article or even source code? Do you have
experiences with standard techniques (entropy coding, delta coding,
linear prediction, backprob. net based predictors, ...). A lossy
encoding is not acceptable, because the algorithms used to search signals
in the brain noise will perhaps also react on smallest periodic artifacts.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
-A distributed system is one in which the failure of a computer you didn't-
-even know existed can render your own computer unusable. (Leslie Lamport)-
Xref: sparky comp.compression:3059 comp.compression.research:126
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: Reading incomplete zip files
Organization: University of Vaasa, Finland
Date: Thu, 20 Aug 1992 07:12:42 GMT

In article <1992Aug20.010256.3873@unixg.ubc.ca> lindholm@ucs.ubc.ca (George Lindholm) writes:
>Is there any way to extract any information from an incomplete zip file?
>My disk filled up during the transfer and I would like to avoid having to 
>do the transfer again unless I have to. Thanks

There is an alternative.  Consider using Zmodem crash recovery to
download the rest of the file. 

..................................................................
Prof. Timo Salmi
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: bho@ocf.berkeley.edu (Bing Ho)
Newsgroups: comp.compression
Subject: Re: DELETE PROTECTION AND FILE FIX UNDER ON-THE-FLY COMPRESSION
Date: 14 Aug 92 23:02:48 GMT
Organization: U.C. Berkeley Open Computing Facility
NNTP-Posting-Host: tornado.berkeley.edu

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

>For larger .EXE .SYS .COM files diet etc do better. Anyone using Clipper
>will be very glad about that :-).

That's very interesting to know.  Which of the compressors, pklite,
diet, or lzexe does best for compression?

>This is not the main reason. The main reason archivers etc do better than
>Stacker is the speed vs ratio limit. Stacker is faster than most
>archivers but therefore has a worse compression ratio. Also notice there
>are compressors even slower than ARJ with more compression. The limit
>seems to be the Ashford compressor taking hours for an file at about
>30% more compression than ARJ (see comp.compression FAQ for more info). 

That's true for perfectly programmed algorithms.  However, until that
occurs, there are many ways to optimize existing schemes for speed.
There is always an inverse proportion to speed and compression, but
I find that optimizing still has a lot to do with speed.  The question I
would like answered is if Stacker's scheme is inherently worse than the
prevalent zip, arj, lzh schemes.

>Nico E. de Vries


Bing Ho
bho@ocf.berkeley.edu
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: OS/2 compression
Organization: California Institute of Technology, Pasadena
Date: Sat, 22 Aug 1992 05:34:13 GMT


 # Along that vein, has anybody heard of any announcement for a
 # PKZip for OS/2?

The just-released Info-Zip Zip 1.9 and UnZip 5.0 work under OS/2,
and also support full OS/2 attributes.

Mark Adler
madler@tybalt.caltech.edu
From: vuong@broue.rot.qc.ca (Daniel Vuong)
Newsgroups: comp.compression
Subject: Expert HELP needed
Date: 14 Aug 92 14:50:55 GMT
Distribution: world
Organization: Groupe de Recherche Operationnelle en Telecommunication (ROT)
X-Newsreader: Tin 1.1 PL4



  Dear Expert,

  I wish someone can help me by giving me some informations:

1) Where to get the "BEST" compression program?
   I'v ebeen trying: arj, pkzip, zoo, lharc, lha, pak
   and I found that: arj seemed to be the one that compressed the most ...
   if someone know a better one ... please tell me
   and show me where to get it also ...

2) Is there some source code (full) about compression program that I can
   find on the net to sse how it's written?


Thanks,

-Dan (vuong@rot.qc.ca)