Packer. A set of test files.

Wed 25 Apr 2001, at 12:25:29 Dmitry Pyankov told Alex Astafiev about Packer.
Set of test files..

AM>>> which I saw beat Hrust and ZX-Zip by about 200-300 bytes. In
Now 1-1.5 kilobytes.

DP> How does the algorithm behave on data like code + text? As I understand it, the
DP> algorithm
On such files, the compression ratio will most likely be a little worse. In an ideal
option, before packaging it would be possible to analyze the contents of the file to
identify blocks of code/text in it.

DP> then
DP> is still a two-pass, so after the first pass you can decide which of the
DP> algorithm options to choose.
The text compression algorithm differs from the code compression algorithm only in that
texts are processed phrases of 2 or more characters in length, and when code compression - 3 and
more bytes.

I don’t know how much text is in the zasm_310.exe file (127 sectors), but it compressed it by
1200 bytes better than HRUST.

AA>> And RAR With what degree of compression? On one file?
On The Best. On different files. On some files the gain is up to 200-300 bytes, on others the gain is small - 10-20 bytes. For example, when compressing BASIC-48
there was a gain of about 150 bytes when storing with RAR.

AA>> Didn’t you try to compress the result with RAR?
The data is stored as a continuous bit sequence (and not asin
HRUM/HRUST - unpacked bytes in separate bytes, bit strings - in
separate bytes). Such information is either not compressed at all, or is compressed by
0.001%

AA>> One file is, alas, not an indicator.
We tried on different files.

AA>> The public is thirsty for adequate tests :)
DP> Indeed, it is! :).

DP> There is a proposal: collect a selection of test files, which include the most
DP> various files: text, music, code blocks from games, etc.
DP> File length - from 200 bytes to 42 kb. Create a full disk and carry out
DP> testing on these files.
Although it’s a pain in the ass, I’ll make a selection.

I can already say:
I compressed the pictures with a Laser Compact and the same pictures (converted to a columnar
format) with a RIP (this is the working name of the archiver - Real Information Packer).
Now I remember that the picture was Extremely? with Funtop'98 RIP compressed better by 120-something bytes.

When creating the Tryptomine Dream demo, the music was stored directly in the form of registers
of the coprocessor. A file with a length of 12040 bytes was compressed by HRUST into 1047 bytes, by RIP - into
882 bytes in Text mode and into 877 bytes in Code mode.

Texts are definitely compressed better than all Spectrum packers.

DP> If you have any files, don’t think it’s too much trouble, throw them on hru...@inbox.ru.
DP> In addition, such a selectionfiles will make life easier for packer writers - there will be
DP> on
DP> to rely on when choosing this or that algorithm.
Okay, I’ll make a selection and throw it in.

I’ve already written to you about this, but I’ll say it again that with files at the end
of which packed information is stored (which is not packed at all) we will
fight the same way as I did in my time (though manually using STS) in the Technogen demo, packaging it with HRUST. Before packing, you can specify the size of
the part of the file to be packed. The rest of the part is added unchanged following the
packed data. The compressed length, often plus the length
of the tail, is placed at the beginning of the file. Naturally, the depacker throws this entire block to the end of the unpacked file. As a result, the tail is placed in its rightful place.
The depacker does not undergo any changes.

By the way, the depacker uses about 64 bytes in the stack area (information is stored there when working with the Huffman tree). So if you don't like it, don't say you weren't warned.

Bye, Dmitry.
WBR, Vivid^Brainwave of the X-Project association.