|WikiProject Computing / Software||(Rated Start-class, Mid-importance)|
There is an old compression utility called PAQ from the MS Dos days and should be mentioned here to disambiguate
can sopmeone tell me if upack/mew archivers (pe compressors) use paq like algorithm or lzma algorithm? mew seems to use lzma, but upack??
I believe upack uses lzma, too. I believe this is not the right place to have this discussion.
Another interesting tidbid is version compability. I ended up here (via google) because I wanted to know if I can depack my Paq-1 archives with a current one.
Are the algorithms patent-encumbered in any country?
I agree that this is not the best place for discussions... but anway: No, paq has no up/downwards compatibility. But you can download all old versions from http://www.cs.fit.edu/~mmahoney/compression/
something more on-topic: the article is very outdated. I'll try to at least update the 'current' best compression programs Balou 20:04, 5 February 2007 (UTC)
The filesize of input files is limited to less than 2 GB. (Not for PAQ9) This should be mentioned somewhere - I am not sure in which section. Unfortunately not even the program description nor the manpages state this limitation. 184.108.40.206 (talk) 14:08, 17 February 2010 (UTC)
The second data set is private. It consists of 316,355,757 bytes in 510 files of various types.
PAQ8JD takes 47,558 seconds to compress the data (196'th place) compared to 4 seconds for the fastest program and 70,444 for the slowest.
316,355,757 bytes is 301mb. The best hard disks around now do about 80, 90mb/sec on read. So this much data could be read in about four seconds, but what about the write? the only way you'd get four seconds is to be writing to a second, equally fast hard disk at the same time.
Toby Douglass 10:52, 11 June 2007 (UTC)
- Makes sense that if you want to test an archiver you either write to a seperate disk or write or read in memory Nil Einne (talk) 18:28, 31 December 2007 (UTC)
Need an explanation of how the algorithm(s) work in general
The article starts ok (could be better, but reasonably clear). What should come next is a brief paragraph describing how the algorithm(s) works in general, in layman's terms if possible.
- Not only that, but the introduction really should explain what PAQ stands for as well. I couldn't find an explanation anywhere, and I think it's important that an acronym (pronounced "pack"?) or initialism (pronounced "pee ay queue"?) be explained.KyleGoetz 08:28, 11 July 2007 (UTC)
We've got a new winner!
KGB Archiver =
"KGB is basically PAQ6v2 with a GUI" is not supported by the reference given. I am changing it to "KGB is based on PAQ6". If anyone disagrees, feel free to revert and we can discuss the merits here. Also see my comments on the KGB Archiver talk page. 220.127.116.11 (talk) 09:25, 8 August 2009 (UTC)
I removed the benchmark reviews from the article. Even if the content of the reviews would be accurate, the page should be about the program and not about the benchmarks. For benchmarks and comparison we should refer to the Comparison of file archivers article. Having detailed reviews of benchmarks would suggest all the hundreds of compressors (had they be given a page in Wikipedia) list their latest "rank" in various benchmarks. I leave the LTCB table with ranks removed (ranks matter little because of the way benchmark works and they would change every time it is updated). --Samir000 (talk) 14:00, 26 September 2009 (UTC)
May be offtopic
(although at the expense of speed and memory usage)
18 hours to compress 1 GB?. I think the word 'great' should be put before 'expense'.