Slashdot Mirror

Each letter in an english word only stores one bit worth of data on average.

see: http://www.maximumcompression....

And moist anjone can eaiily correc simxle errors automaxically while reeding in there heads.

I'm sure mistakes were made while carving stone tablets, and they just said 'Fuck it, it's fine.'

I was at a Pho shop the other day, with etched glass windows reading 'NODDLE SOUP' (in Comic Sans...)

How about false positives? Antivirus software that checks nested encrypted archives often crashes, or marks as a false positive, files that contain a large amount of compressed data. For example:

42.zip contains 4.5PB of data, compressed to 42kb. My university's mailserver marks it as a false positive.

selfgz.gz is a gzip file that decompresses to itself. My university's mailserver tries to decompress it forever to scan all the nested files. It marks it as a false positive, since it was unscannable.

Um, those both should be marked as positive hits, at least on bad things you don't want. One is intended to cause a denial of service with an incredibly large compressed file of nothing, and the other is intended to cause an infinite loop. Both were specifically designed to cause the problems listed, so there is not a "false" anything.

Anti-Virus programs should really be called anti-malicious programs, as virus scanning is not all they do.

How about false positives? Antivirus software that checks nested encrypted archives often crashes, or marks as a false positive, files that contain a large amount of compressed data. For example:

42.zip contains 4.5PB of data, compressed to 42kb. My university's mailserver marks it as a false positive.

selfgz.gz is a gzip file that decompresses to itself. My university's mailserver tries to decompress it forever to scan all the nested files. It marks it as a false positive, since it was unscannable.

Zip bombs are a false positive?

How about false positives? Antivirus software that checks nested encrypted archives often crashes, or marks as a false positive, files that contain a large amount of compressed data. For example:

42.zip contains 4.5PB of data, compressed to 42kb. My university's mailserver marks it as a false positive.

selfgz.gz is a gzip file that decompresses to itself. My university's mailserver tries to decompress it forever to scan all the nested files. It marks it as a false positive, since it was unscannable.

You don't say what kind of false positive it's flagged as. However, I would hope files like that get flagged in some manner, so I would say it's not a false positive. You do not want to start unzipping 4.5PB of data... if you truly have a tiny zip file with a huge amount of data, then manually deactivating or somehow making other provisions for such a unique case is perfectly acceptable. In all other instances, I want to be warned that there is something exceptionally strange about that file.

A self-decompressing .gz file? FUCK YES I want to know about that... a non-application file that can somehow execute itself? I would say that is exceptionally dangerous and should be flagged as such. That is not a false positive - there is something very strange about that file and is potentially exceptionally dangerous. Again, if you need this file for some specific reason, the manually making provisions to get it is perfectly acceptable.

So... in both cases you presented, I would definitely say that is not a false positive.

How about false positives? Antivirus software that checks nested encrypted archives often crashes, or marks as a false positive, files that contain a large amount of compressed data. For example:

42.zip contains 4.5PB of data, compressed to 42kb. My university's mailserver marks it as a false positive.

selfgz.gz is a gzip file that decompresses to itself. My university's mailserver tries to decompress it forever to scan all the nested files. It marks it as a false positive, since it was unscannable.

The "winners" have special compression modes for .wav files, etc.

The "winners" have special compression modes for .wav files, etc.

http://www.maximumcompression.com/ is better source

Proper link for the lazy.

Poor article. Even the Wikipedia article is more "exhaustive." http://en.wikipedia.org/wiki/Data_compression

Even two minutes googling for "data compression" will get you more useful and better "compressed" information.

http://www.ics.uci.edu/~dan/pubs/DataCompression.h tml

http://datacompression.info/

http://www.maximumcompression.com/

http://www.compression-links.info/Link/248_Markov_ Predictive_Coders_PPMZ.htm

maximumcompression.com is an excellent site but it just compares compression ratio, not speed. Hence for some people, it's of limited use.

• they compress significantly better than any of the faster (and relatively obscure) programs
• the programs that compress significantly better take more than twice as long
• they're at the front of the pack for decompression time

Er... did ya check out the comparisons? As you can see here here jpeg at least can be compressed considerably with Stuffit. According to this the program can "(partially) decode the image back to the DCT coefficients and recompress them with a much better algorithm then default Huffman coding." I've no idea what that means, but it does seem to be more thorough and complex than what you wrote.

I read the article, got shocked at the time spent comparing the compression of MP3s and DiVX, and didn't read much further.

Google's top hit turns up this site which is chock full of data on every compressor you ever & never heard of:
http://www.maximumcompression.com/index.html

Wikipedia has nice charts to quickly see features and OS support for a handful of common compressors:
http://en.wikipedia.org/wiki/Comparison_of_file_ar chivers

The newsgroup comp.compression has been around awhile, and is maintaining an excellent FAQ:
http://datacompression.dogma.net/index.php?title=C omp.compression_FAQ

as its slashdotted

this site
http://www.maximumcompression.com/
has been up for years and performs tests on all the compressors with various input sources, much more comprehensive

http://www.maximumcompression.com/ ?

And a nice other link on lossless text compression. As you can see top3 programs all use PAQ-like compression engines: http://www.maximumcompression.com/data/text.php

There are some amazing compression programs out there, trouble is they tend to take a while and consume lots of memory. PAQ gives some impressive results, but the latest benchmark figures are regularly improving. Let's not forget that compression is not good unless it is integrated into a usable tool. 7-zip seems to be the new archiver on the block at the moment. A closely related, but different, set of tools are the archivers, of which there are lots with many older formats still not supported by open source tools

I'm not sure if you imply that bzip2 is actually good at compression, but just in case you were: it is bad, slow and bad compression ratios. Some of the good common programs are 7zip and (win)rar. A benchmark can be found for example in http://www.maximumcompression.com/data/summary_mf. php.

this ones a bit better then that rojackpot one (more compressors/more info)
Ranked on compression ratio, efficiency, and compression time.
http://www.maximumcompression.com/

Since the original site seems to be really slow and split into a billion pages, those who aren't aware of it might want to look at MaximumCompression since it has tests for several file formats and also has a multiple file compression test that is sorted by efficiency. A program called SBC does the best, but the much more common WinRAR comes in a respectable third.

Since the original site seems to be really slow and split into a billion pages, those who aren't aware of it might want to look at MaximumCompression since it has tests for several file formats and also has a multiple file compression test that is sorted by efficiency. A program called SBC does the best, but the much more common WinRAR comes in a respectable third.

According to Maximum Compression, which is basically the best site for compression testing, Stuffit's new version is the best for lossless jpeg compression. I've got it and I can confirm that it does a much better job on jpegs than anything else I've tried. Unfortunately, it is only effective on jpegs not gifs, pngs, or even pdfs which seem to use jpeg compression. And, outside of the mac world, it is kind of rare.

There are some amazing compression programs out there, trouble is they tend to take a while and consume lots of memory. PAQ gives some impressive results, but the latest benchmark figures are regularly improving. Let's not forget that compression is not good unless it is integrated into a usable tool. 7-zip seems to be the new archiver on the block at the moment. A closely related, but different, set of tools are the archivers, of which there are lots with many older formats still not supported by open source tools

Nice trolling, but *nix has finally gotten a port of 7-zip after all this time, despite it being GPL'ed since its inception and compressing far, far better than bzip2 in every conceivable test.

The question is, why should windows users care about bzip2 when superior formats have been available?

benchmarks

but usually these compare different formats rather than how well each compresses zip files.

Igor Pavlov likes to claim that 7-zip creates smaller zips than anything else, but I haven't seen any third party comparisons even interested in that.

As far as size goes, WinACE2.0 compression is the best compression I've seen available.

winrar is better.
7-zip is better.
PAQ6 is better than pretty much anything.

benchmarks.