TEXTCOMPRESSION çddf,faa,afa,aaf,faf,ffa,aff ³-------------------------------------- ¾TextCompression - The Difficult Choice ¢By²:¹ Terrox/RAW Staff ³-------------------------------------- ²We have all used different compressors to compress text and articles. The quality and speed among these packers are very various, and I will try to help you finding the most suitable compressor for your perfect need. What is best compressor in Diskmags? Which compressor shrink the text most compact to hide away for later use? Which compressor decrunch fastest and which one may gives errors? How the test is done: I choosed 175 different textfiles and put them in one directory. The complete size became exactly 4,0Mb. I have tested the eight most normal packers. Included is also every interesting observations and results. First all the data is mentioned, then I have included a short comment to the just tested compressor. At the end I have put an brief summary, for those of you who are in a hurry. All files is crunched/decrunched automatic using DirectoryOpus to not give to false results due to waiting between the manual choosing of the files. For PowerPacker I used the automatic script function, and the efficiency of the packing was set to default, namely good. All results is given with a correct number of decimals, this means the number of ¶²decimals I can defend out of the test, as there are some faults in the manually taken time. The whole test was done under the same circumstances. Machine used is an Amiga 4000/030 with a 40Mhz 68882 co-processor. The final packing-results of 4,0Mb textfiles: ¾ Imploder v1.0: ¹Compression: 8min 21sec DeCompression: 2min 9sec Size Removed: 2,197,836 bytes(54,9%) CPU: 50-60% Operation was: Successful ²Uses the xpk-library and the Imploder compression technique. An old packer, which decompress very fast. The negative is the slow packingspeed. One of the best packers though. The quite low CPU-percent is good for the multitasking, and make you run other tasks without too much speedkilling. ¾ Nuke v1.0: ¹Compression: 3min 46sec DeCompression: 2min 9sec Size Removed: 2,247,928 bytes(56,2%) CPU: 50-60% Operation was: Successful ²Uses the xpk-library and the heavy Nuke compression technique. This is the most common packer among diskmags. The main reason is the very fast decompression speed and the good size compression compared to the other crunchers. I know that both RAW and ¶²Abnormalia, for mention some diskmag, use this method. Also nuke have a low CPU-percent, and it`s always trustable. ¾ Fast v1.0: ¹Compression: 2min 24sec DeCompression: 2min 8sec Size Removed: 1,695,616 bytes(42,4%) CPU: 60-75% Operation was: Successful ²Also Fast compression technique uses the famous xpk-library. Fast should as the name tells, be fast (everything should be simple, but not not simpler - Einstein). The most remarkable thing is that the decompression speed is a little bit faster than nuke. As nuke compress much better it`s therefore prefered. It also have a quite high CPU-percent compared to nuke and imploder. ¾ Shrink v0.1: ¹Compression: 11min 8sec DeCompression: 6min 31sec Size Removed: 2,211,584 bytes(55,3%) CPU: 70-100% Operation was: Not quite successful, error "data not compressed" ²Another known compressor which take use of the suitable xpk-library. This is a very interesting technique, and there are some points that have to be mentioned. First I noticed the very slow compression time and the six files which didn`t got compressed at all. Notice that even without packing ¶²these files, it was the packer with the second higest removed size. The CPU-percent take most of the taskpower, and should be run alone. The maybe most interesting is the low version number. Do the coder have any Revolutinary Academic Wit to make this compression a bit faster? I hope so, because it`s very interesting for the fastest machines around. ¾ BLZW v3.0: ¹Compression: 2min 31sec DeCompression: 2min 8sec Size Removed: 2,032,296 bytes(50.8%) CPU: 55-70% Operation was: Successful ²Uses the xpk-library and the BLZW compression technique. The coder Bryan Ford, says that this is based on the zoo-packing. It could be compared to the nuke compressor, but BLZW do not shrink the text as much as nuke does. BUT this could be a good replacement for nuke as it compress over 33 percent FASTER than nuke, and even decompress a bit faster too! Did all coders and editors got that? I am surprised myself! ¾ Rlen v1.0: ¹Compression: 2min 54sec DeCompression: 2min 21sec Size Removed: 0,377,352 bytes(9,40%) CPU: 55-75% Operation was: Successful (hmm) ²An quite unknown compressor which take use of the xpk-library. The funniest ¶²thing is the little time-difference between compression and decompression. It almost crunch as fast as it decrunch, but what so? Do we need such a packer? Rlen past the test successful, but I will not say it`s useful! Send this packer back to the coder, and ask for a super-duper-upgrade! Else: Let the magnetism send this file into non-existance, and save the smashing 1384 bytes! ¾ Huff v0.62 ¹Compression: 2min 51sec DeCompression: 2min 21sec Size Removed: 0,377,352 bytes(9,4%) (or was it size added???) CPU: 55-75% Operation was: Successful (hmm) ²Can you find three different things between Rlen and Huff? I can: the name, the version number and even the compression-speed. Yeah, what a stunning difference! Three very useful seconds faster compression - this coder have even added 1312 more marvellous smashing bytes to the file. And for free? What a handsome coder! The best with Huff is the fitting word (at least in norwegian). The coder should have that honour, but why not make it v4.0 as it`s such a nice compressor? ¾ PowerPacker v4.3 ¹Compression: 8min 59sec Size Removed: 2,123,361 bytes(53,1%) ¶²All was set to normal settings, and I used the built in script-routine. Some files was skipped due to data-overflow, but though the size removed is very good. The advantage with PowerPacker is that you may read it in for example DirectoryOpus without decompression it first. Thank you Nico (almost dead) Françuis. I love your work! Summery for Super-busy people: The four most useful packers tested here is; Imploder, Nuke, BLZW and PowerPacker. The three first use of the xpk-library, and must be decompressed before use. PowerPacker have the advantage that it may be run from directly from DirectoryOpus etc. without unpacking it. Nuke is most used among Diskmags, but I actually recommend coders to take a look into the BLZW-packer. It decompress faster than nuke, and compress stunningly 33 percent FASTER too! The new Diskmag Packer? I say that BLZW is the winner for daily packing use! Shrink is exciting because of the low version number, but still a good size-removed packer! The so-what? packers is; Rlen and Huff! I guess it`s two brothers fighting about who is the first man in history making a negative packer. If you are going to bet, put your money on Huff - the name is just smashing. Maybe the Huff coder have seen the irony in his packer?