HDTenEightyP/NetNews huggingface dataset:
From: andreas@greif.philosophie.uni-stuttgart.de (Andreas Eisele)
Subject: Appending to a compressed file
Reply-To: andreas@adler.philosophie.uni-stuttgart.de
Organization: IMS, University of Stuttgart, Germany
Date: Wed, 29 Jul 1992 09:23:19 GMT

Is there a way to append data to a large compressed (*.Z) file that is
more efficient than uncompressing+appending+recompressing?

I don't know much about compression techniques, but I think ist should
be doable in at least two ways:

(1) By scanning the compressed file, a program should be able to
compute the state the compressor was at the end of the original
compression. It could then continue in this state to compress the
appended data. This approach would at least prevent to re-write the
compressed file.

(2) In order to avoid re-scanning the compressed file, it might make
sense to store the state of the compressor explicitly in an additional
file. Of course this would decrease the effect of the compression, but
might still be worthwile (esp. if the result, i.e. the compressed file
w/o the state information is to be transfered).

Has anyone in the compressing community already thought about that?
Is there perhaps software available, already?

Thank you for any information,

Andreas Eisele

P.S. Please reply by e-mail, I will summarize if there is enough
interest.
--
+--------------------------------------------------------------------------+
|Andreas Eisele                Institut fuer maschinelle Sprachverarbeitung|
|Tel.:    +49-711-121-1357     Universitaet Stuttgart, Azenbergstrasse 12  |
|Fax.:    +49-711-121-1366   D-7000 Stuttgart 1,  Fed. Rep. of Germany     |
|Internet: andreas@adler.philosophie.uni-stuttgart.de    (NeXTMail ok)     |
+--------------------------------------------------------------------------+
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: tody@noao.edu (Doug Tody)
Subject: Re: Compression artifacts in NBC Olympic coverage
Reply-To: tody@noao.edu
Organization: National Optical Astronomy Observatories
Date: Mon, 27 Jul 1992 06:48:49 GMT

In article <1992Jul27.035759.153188@zeus.calpoly.edu>, jemenake@zeus.calpoly.edu (Joe Emenaker) writes:
> Well, bravo. I'm happy for you that you're smart enough to notice such
> things. I'm sure you must be a very bright little boy. To quote Monty
> Python: "Gee, we're all really impressed down here, I can tell you.".
> However, I'm sad for you that knowing that NBC is compressing the signal is
> ruining your experience of the Olymics so much...
>
> .. Is it REALLY that unbearable? For heaven's sake, just sit a few feet futher
> from the screen or take your glasses off or something.
>
> Granted, it is a subtle thing and I AM truly impressed that you caught it.
> And I acknowledge your attempt to use it to cash in on your 15 minutes of
> fame that Andy Warhol says each of us will have. But, I think that you're
> going overboard by expecting NBC to fork over more money to make the
> transmission absolutely perfect when so few people are even going to
> nitice... and fewer are even going to care.

Lighten up.  I (and I think many others) also noticed it - it was very
apparent, distracting, and mildly annoying.  Personally I would just ignore
it, I suspect NBC is just experimenting with some new technology and they
will probably get enough complaints so that something is done about it.

Doug Tody  (NOAO)
From: jjk1@ns1.cc.lehigh.edu (Konsultant Josh/fuzzy.happy.green.box)
Newsgroups: comp.compression
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 27 Jul 92 18:23:12 GMT
Organization: Lehigh University

>
>Well, bravo. I'm happy for you that you're smart enough to notice such
... extraneous, bandwidth-wasting BS deleted

>Joe Emenaker - Sexual Engineer | "After thinking a lot about the design of the 
>   jemenake@nike.calpoly.edu   |  human body, I figure it's a good thing that   
>   Pro-woman, anti-feminist    |  God is self-employed, because no company on
> (This is the .sig of the day) |  EARTH would ever hire him as an engineer" -Me
>

My my, quick to flame aren't we?

Perhaps you belong in another newsgroup, sir.  Perhaps, then again,
you may be qualified to make such judgments of who is and is not
arrogant; after all, your sig. file quotes yourself.  I suppose there
is the epitome of self-worship.  Take your unwanted, unwarranted, and
unneeded attitude to someone who will appreciate it.

--Josh
-- 
____________------------===========------------____________
                     from: Josh Kopper
                      jjk1@lehigh.edu
    
  Computer Engineering, CSEE Department, Lehigh University

  Systems Programming - Lehigh University Computing Center
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: graeme@labtam.labtam.oz.au (Graeme Gill)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Mon, 27 Jul 1992 04:21:01 GMT
Followup-To: rec.video
Summary: Probably PAL -> NTSC

In article <MONTA.92Jul26181344@image.mit.edu>, monta@image.mit.edu (Peter Monta) writes:
> While I was watching the US-Angola basketball game and the coverage
> of the early gymnastics compulsories, I thought I saw several image
> artifacts.  Finally I taped a segment of the gymnastics and waited for
> a particularly bad example, then went through it frame by frame.
> 
> There's no question about it:  there are block artifacts in the
> regions where a fast-moving object occludes or reveals the background.
> For example, NBC showed the compulsory floor exercise of Maria
> Neculita (Romania) at around 5:30pm EDT.  Look at the first tumbling
> run, in which Neculita's legs flash past the audience.

	Being from Europe the TV signal probably originated as a PAL signal
and has to be converted to NTSC, wich means both the colour encoding,
frame rate and number of lines has to be converted to the US standard.
Simple interpolation and smoothing of the frame rate (50Hz -> 60Hz) usually
leads to smearing of fast motion, so the "better" standards converters have
various "smarts" to recognize motion and transcode it specially. I guess the
motion estimation circuits work on a block basis, and you may be seeing these
block based motion artifacts. 

	Graeme Gill
From: dimitrov@lab.ultra.nyu.edu (Isaac Dimitrovsky)
Subject: announcing GIFBLAST 1.1 - a GIF compressor (new & improved)
Summary: a lossless GIF file compressor
Keywords: GIF,compressor,lossless
Organization: New York University Ultracomputer Research Lab
Date: Wed, 29 Jul 1992 01:08:17 GMT

[]
I have posted to alt.binaries.pictures version 1.1 of GIFBLAST, a program
that I have written for the PC.

What is GIFBLAST?
GIFBLAST is a compressor designed especially for GIF files. The usual file
compressors (PKZIP, ARJ, etc.) do not work on GIF files; GIFBLAST does.
When you run GIFBLAST on a GIF file X.GIF, you get a compressed file X.GFB
that is usually 20-25% smaller. In order to view this file you have to
decompress X.GFB to get back the original X.GIF file. The compression used
in GIFBLAST is lossless, i.e. it perfectly preserves all image pixels and
other information in GIF files.

What can I use GIFBLAST for?
The compression/decompression algorithm used in GIFBLAST is quite slow,
so you would probably not want to store frequently viewed GIF files in
compressed form. However, GIFBLAST should be useful in applications
where getting maximum compression is important, such as:
- Storing GIF files on bulletin boards for downloading.
- Posting GIF files on usenet.
- Transmitting GIF files via modem.
- Sending GIF files on floppy disk.
Because there is no loss involved when compressing with GIFBLAST,
the user need not be concerned with harming the image or introducing
compression artifacts.

Changes from version 1.0 of GIFBLAST:
- The compression algorithm is improved.
- Now works on images with fewer than 8 bits per pixel.
- Fixed a few bugs.

If there is interest, I will also post generic C code for GIFBLAST
so that people can use it on other platforms (if you're interested,
send me email - don't post).

Isaac Dimitrovsky (dimitrov@lab.ultra.nyu.edu)
"Sincerity is *the* most important thing in show business -
  so once you learn to fake that you've got it made."
- Joe Franklin
Newsgroups: comp.compression
From: lip@s1.gov (Loren I. Petrich)
Subject: Re: sizing huffman trees
Organization: LLNL
Date: Wed, 22 Jul 1992 00:32:39 GMT

In article <1992Jul21.220205.18507@math.waterloo.edu> bbobak@math.waterloo.edu (Brad Bobak) writes:
>  I was wondering if anyone has come up with an algorithm for determining
> the size of an encoded huffman tree from just the frequencies of the
> letters (sorted or unsorted, it doesn't matter).
>  Right now, to size a tree, I'm basically building it, and this is time
> consuming if I'm using alot of trees.
>  Any pointers, suggestions, etc. would be appreciated.

	There are several algorithms for building Huffman trees.
Perhaps the simplest is the original Huffman one.

Repeat to build all the nodes:

	Look through all the unconnected nodes and symbols to find
the two with the two smallest frequencies.

	Connect these to the new node and make the node's frequency
the sum of the two branches' frequencies.


	I'm sure that this will be fairly efficient unless one has a
terribly skewed distribution.

Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: jemenake@zeus.calpoly.edu (Joe Emenaker)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: California Polytechnic State University, San Luis Obispo
Date: Mon, 27 Jul 1992 03:57:59 GMT

monta@image.mit.edu (Peter Monta) writes:
>While I was watching the US-Angola basketball game and the coverage
>of the early gymnastics compulsories, I thought I saw several image
>artifacts.  Finally I taped a segment of the gymnastics and waited for
>a particularly bad example, then went through it frame by frame.
>
>There's no question about it:  there are block artifacts in the
>regions where a fast-moving object occludes or reveals the background.

Well, bravo. I'm happy for you that you're smart enough to notice such
things. I'm sure you must be a very bright little boy. To quote Monty
Python: "Gee, we're all really impressed down here, I can tell you.".
However, I'm sad for you that knowing that NBC is compressing the signal is
ruining your experience of the Olymics so much.

>How
>might NBC be convinced to stop doing this, or at least use a better
>coder?

Is it REALLY that unbearable? For heaven's sake, just sit a few feet futher
from the screen or take your glasses off or something.

Granted, it is a subtle thing and I AM truly impressed that you caught it.
And I acknowledge your attempt to use it to cash in on your 15 minutes of
fame that Andy Warhol says each of us will have. But, I think that you're
going overboard by expecting NBC to fork over more money to make the
transmission absolutely perfect when so few people are even going to
nitice... and fewer are even going to care.

-- 
Joe Emenaker - Sexual Engineer | "After thinking a lot about the design of the 
   jemenake@nike.calpoly.edu   |  human body, I figure it's a good thing that   
   Pro-woman, anti-feminist    |  God is self-employed, because no company on
 (This is the .sig of the day) |  EARTH would ever hire him as an engineer" -Me
Xref: sparky comp.compression:2857 rec.video.production:1187 rec.video:9719
From: cbb1@ra.msstate.edu (Chris B. Borchert)
Subject: Info about DPCM needed.
Organization: Mississippi State University
Date: Thu, 23 Jul 1992 15:29:23 GMT

Can anyone tell me where I can obtain additional information
about the DPCM algorithm.  I could also use some source code.
Particularly, I am interested in real-time applications
of DPCM but batch will do.

Chris BOrchert
cbb1@ra.msstate.edu
From: willy@csa.bu.edu (Kin W. Hui)
Newsgroups: comp.compression
Subject: NBC Olympic image request.
Date: 28 Jul 92 14:10:59 GMT

I wander if the orginal poster from MIT can post the "jerky" image in
24 bit TGA or TIFF format so other professional people can comment 
if that's a DCT or motion estimate artifact.
-Kin, willy@bucsf.bu.edu
Xref: sparky comp.compression:2860 rec.video:9734 rec.video.satellite:3853 rec.video.production:1192
From: steve@fulcrum.oz.au (Steve Taylor)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 29 Jul 92 05:53:11 GMT
Organization: The Fulcrum Consulting Group

In article <1992Jul27.035759.153188@zeus.calpoly.edu> jemenake@zeus.calpoly.edu (Joe Emenaker) writes:
>Well, bravo. I'm happy for you that you're smart enough to notice such
>things. I'm sure you must be a very bright little boy. To quote Monty
>Python: "Gee, we're all really impressed down here, I can tell you.".

Joe, pop a valium or something. Everyone but you is having a fine time.


							Steve
							steve@fulcrum.oz.au
Newsgroups: comp.compression,rec.video.satellite,rec.arts.tv,rec.video,rec.video.production,austin.forsale,houston.forsale,misc.forsale,tx.forsale
From: guri@apogee.sps.mot.com (Gurvinder Singh Ahluwalia)
Subject: Panasonic Multisystem World-wide VCR for SALE
Keywords: PAL, NTSC, MESA, SECAM, etc Multisystem
Reply-To: guri@apogee.sps.mot.com
Organization: Motorola
Date: Fri, 31 Jul 1992 16:02:52 GMT


I bought a Multisystem VCR while in transit at the Singapore Airport since 
I was keen on viewing PAL formats (from my home country, India).  The sales
person gave me into understanding that the VCR would work with any TV in the
USA.  On arriving back in the US, I realized that the VCR only runs for the
NTSC format with regular US TV's and needs a multisystem TV (PAL, at least) 
to run other formats (that the VCR supports).  

I haven't been able to locate a place that sells multisystem TV's around here 
and I wouldn't like to shop in Singapore again, at least not at the Airport.
Since I also have a "regular" VCR which I use routinely, this Panasonic model
has been virtually unused.  It is now up for sale.  I originally paid over 
$750 for it.  It comes with the box and original packing.  If someone can 
make a reasonable offer (well make an offer!), I'll even pick up the S&H 
expenses.  Here's some of the data on it:

PANASONIC MULTISYSTEM "World-Wide" VCR for sale.

Model:     NV-J700AM,

Condition: New

Features:  One-Touch-Timer Recording (OTR).
           Has the following system selections:

           - NTSC 3.58
           - NTSC 4.43
           - PAL
           - MESECAM
           - M-PAL
           - N-PAL
           - SECAM
           - PB NTSC/PAL
           - PB NTSC/M-PAL
           - PB NTSC/N-PAL
           - PB M-PAL/N-PAL

Asking: $700 (OBO)

I don't follow these newsgroups regularly; please email responses and queries.

__
Gurvinder Ahluwalia             guri@apogee.sps.mot.com
(512) 891-3310 (w)

Newsgroups: comp.compression
From: t7@elan.glassboro.edu (TEMP_7)
Subject: stacker command
Organization: Glassboro State College, Glassboro, NJ
Date: Wed, 22 Jul 1992 18:14:00 GMT



is there a command on stacker to write protect a drive? i'm not so much 
interested in that command as the command which will UN write protect my 
drive which, bizzarrely enough, somehow managed to GET write protected 
during a system crash.

any help?

t7
Xref: sparky comp.compression:2842 rec.video:9675 rec.video.satellite:3824 rec.video.production:1168
From: brown@vidiot.UUCP (Vidiot)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 28 Jul 92 03:56:31 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <1992Jul27.085214.4376@hparc0.aus.hp.com> doug@hparc0.aus.hp.com (Doug Parsons) writes:
<
<Oh, BTW - during an interview with a local interviewer and a spanish
<technician in charge of the broadcasts, he said that they were using ultra
<modern techiniques, including recording the entire Olympics in HDTV.

While HDTV will be at the Olympics, none of the cameras are on-line for the
world feed.  All of that is PAL (4:3).  The HDTV stuff will be used later to
show off the quality of HDTV.

Though, there may be some sites where HDTV can be seen live.  It was done for
the winter Olympics.  But, none of it (as far as I know) is being broadcast.
-- 
      harvard\     att!nicmad\          spool.cs.wisc.edu!astroatc!vidiot!brown
Vidiot  ucbvax!uwvax..........!astroatc!vidiot!brown
      rutgers/            INTERNET:vidiot!brown%astroatc.UUCP@spool.cs.wisc.edu
                                   brown@wi.extrel.com
Newsgroups: comp.compression
From: d88-jwa@dront.nada.kth.se (Jon W{tte)
Subject: Re: PKZip 2.x
Originator: d88-jwa@dront.nada.kth.se
Organization: Royal Institute of Technology, Stockholm, Sweden
	<1992Jul24.122630.1545@gandalf.ca>
	<1992Jul24.204620.10408@cco.caltech.edu>
Date: Sat, 25 Jul 1992 10:49:36 GMT

> madler@cco.caltech.edu (Mark Adler) writes:

   >I was wondering if the current ZIP file format fully machine and
   >platform independent; i.e., will it support extended file
   >attributes in OS/2, extended attributes/filenames in Unix, etc.

   To elaborate on a previous response, Info-zip's next version will
   support full OS/2 and VMS attributes.  Whether this is part of the
   "ZIP file format" depends on what you mean.

Will it support Mac resource forks as file info ?

In a way such that the other machines can get at it/create it too ?

-- 
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds.
### You have the 24-bit virus. This virus eats system memory like CRAZY.
Newsgroups: comp.compression
From: igor@hump.ihep.su (Igor Mandrichenko)
Subject: Re: My New Compression Algorithm
Apparently-To: inews@ihep.su
Posted-Date: Tue, 14 Jul 1992 12:59:12 +0400
Organization: IHEP,Protvino
X-Newsreader: Tin 1.1 PL4
Date: Tue, 14 Jul 1992 12:59:12 +0400

Phil Howard writes:
>This won't work.
>How can you distinguish between these files:
>    10111010001
>and
>    00010111010001
>:-)

	Why not to discard all leading non-signifacant zeros since the
compression/decompression algorithm does not use them ? :)
From: alehecka@sdcc13.ucsd.edu (Augustin Lehecka)
Newsgroups: comp.compression
Subject: Expanding/Unshrinking in ZIP
Date: 23 Jul 92 20:58:39 GMT
Organization: University of California, San Diego

Can anyone tell me what 'Unshrinking' and 'Expanding' messages 
in PKUNZIP mean?  It seems to me that the program is using
two different compressing algorithms and utilizes each on files better
suited for each algorithm. That is my theory. If you know, please
respond!
				Tnank you!
				AUGUSTINE 
				
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: trebor@foretune.co.jp (Robert J Woodhead)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Foretune Co., Ltd.
Date: Tue, 28 Jul 1992 02:19:44 GMT

doug@hparc0.aus.hp.com (Doug Parsons) writes:

>Oh, BTW - during an interview with a local interviewer and a spanish
>technician in charge of the broadcasts, he said that they were using ultra
>modern techiniques, including recording the entire Olympics in HDTV.

The Olympics are being sat-cast here in Japan in "HI-Vision."  Also,
Panasonic (I believe) is making a big deal of the fact that their
D-3 1/2" Digital Videotape Format is the official one for the games.

-- 
+---------------------------------------------------------------------------+ 
| Robert J. Woodhead, Biar Games / AnimEigo, Incs.    trebor@foretune.co.jp |
| "We're off to outer space, we're leaving Tomobiki!"                       |
|  -- Entry in the "Beautiful Dreamer" Extemporaneous Poetry Parody Contest |
Xref: sparky comp.compression:2837 rec.video:9655 rec.video.satellite:3818 rec.video.production:1160
From: johna@psdcae1.gvg.tek.com (John Abt)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 28 Jul 92 01:31:43 GMT
Followup-To: comp.compression
Organization: Grass Valley Group, Grass Valley, CA


All NBC Olypmics production is being done in the PAL standard. The NTSC standards
conversion occurs at the satellite feed, i.e., the last step before sending it
to New York. The newer standards convertors do use block motion estimation; they
are significantly more sophisticated than simple spatial/temporal interpolators.

I have noticed the motion artifacts, but I it thought wasn't too bad (it's pretty 
hard to be "perfect" in a real-time system). 

But the really bad artifact is the ghosting about 1/2 microsecond to the right of 
almost any vertical edge.
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: cee1@ra.msstate.edu (Charles Evans)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Mississippi State University
Date: Tue, 28 Jul 1992 01:44:19 GMT

Power@cup.portal.com (Ron A Uitz) writes:

>Digital "jerkiness" is apparent to me in all of NBC's coverage.  I guess
>they figure most people don't notice or don't care.  

I noticed it on the USA-angola game when they were moving the cameras 
back and forth as a person was running down court. It looked like nice
huge pixels.. thought it was kinda neat.

By the way, for some reason the triple cast is free here with our
cable company on ch. 33, 34, 35. 


-- 
Charles E. Evans           /  o     / Whereforeseeingwealsoarecompassedabout
cee1@ra.msstate.edu       / ./|\   / withsogreatacloudofwitnesses,letuslayaside
		         /   /|'  / everyweight,andthesindothsoeasilybesetus,
cee1@msstate.bitnet     /    , ' / andletusRUNwithpatiencetheracethatissetB4us.
Newsgroups: comp.compression
From: stevef@bony1.bony.com (Steve Faiwiszewski)
Subject: Re: Lets design an audio compressor (immediate summary)
Organization: Lost in NYC
Date: Tue, 21 Jul 92 22:26:44 GMT

Have you seen the Acomp article in the July issue of Dr. Dobb's?
Were you looking for something like this?

	- Steve -

-- 
Internet: stevef@bony1.bony.COM   |  ____________________________
bang : {uupsi,uunet}!bony1!stevef | / If cows could fly, everyone \
                                  ||| would carry an umbrella     ||
  Opinions? What opinions?        | \_____________________________/
Xref: sparky comp.compression:2848 rec.video:9699 rec.video.satellite:3834 rec.video.production:1177
From: carr@esl.com (Erik Ramberg)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: NBC Olympic coverage - reason
Date: 28 Jul 92 20:13:47 GMT
Followup-To: comp.compression
Distribution: rev.video.production
Organization: esl

In article <Bs2ACw.GBE@watserv1.uwaterloo.ca>, elball@sunee.waterloo.edu (Eric Ladd Ball) writes:
> 
> The reason for the artifacts is quite simple.  NBC is using digtal
> full-frame camaras.  These are sequential line instead of NTSC interlaced.
> 
> Deleted stuff
>
> CONs:
> 1> The artifacts of fast motion everyone has seen.  This is caused because
>    the interlaced lines appear on sub-sequent fields and look very wierd.
> 
> 

Not quite right...it's easy to convert from non-interlaced to interlaced
without artifacts.  The problem (assuming they are using digital cameras)
is in their compression algorithim for motion.  These types of routines
usually divide the screen into blocks and use a reduced resolution as well
as only transmitting the image differences, thus they get enormous decreases
in transmitted bandwidth with only a small decrease of picture quality.  The
tradeoffs are implied and they opted for more compression.

	-Erik