crunchi5.htm: Little essay about the various methods and viewpoints of crunching

+HCU papers

Little essay about the various methods and viewpoints of crunching
~ version July 1998 ~
by Joa Part V

Courtesy of fravia's page of reverse engineering

Well, Joa continues his fundamental paper on crunching, this is part V
enjoy!

10 July 98 Joa ~ crunchi1.htm Little essay about the various methods and viewpoints of crunching papers ~ fra_0126

10 June 98 Joa ~ crunchi2.htm Little essay about the various methods and viewpoints of crunching II papers ~ fra_0129

17 June 98 Joa ~ crunchi3.htm Little essay about the various methods and viewpoints of crunching III papers ~ fra_012E

17 June 98 Joa ~ crunchi4.htm Little essay about the various methods and viewpoints of crunching IV papers ~ fra_012F

10 July 98 Joa ~ crunchi5.htm Little essay about the various methods and viewpoints of crunching V papers ~ fra_0133

Little essay about the various methods and viewpoints of crunching.

Part V: Interlude and the Mystery of Lempel-Ziv Part I

---Joa's little essay on performing the art of compressing data - little big interlude---

(Pre-Chapter V)

And YET Garbage... ;((

In chapter IV ;) i told you some ways of compressing runs of bytes with certain

techniques. But the last one, the No Garbage, technique has a little problem.

(thanks go to rudeboy for clearly pointing that out! Your EMail has brought me

some new ideas. Thanks again.)

Consider the following bytes:

xyz1112

As the coder would start upon a run of at least three bytes and would subtract one

we would get the following sequence:

xyz11{0x00}2.

The decoder would interpret the file in the following way:

actual last byte crunch

x false

y x false

z y false

1 z false

1 1 true

0x00 1 true

copy '1' one time

continue with reading

false

2 1

(EOF)

done

and now consider the following byte-sequence:

xyz1122

The coder would code this verbatim:

xyz1122

The decoder would interpret this in the following way:

actual last byte crunch

x false

y x false

z y false

1 z false

1 1 true

{0x32} 1 true

[CRASH] - our decoder writes bytes incorrectly!!!

Hey what's going on? Last time i told you this - now i tell you that.

Well, to be honest, i didn't implement this last one (trusting the

basic sample i received) and so didn't test it out. For this i officially

apologize :(.

Now the least i can do is to tell you what you can do, as there are a

lot of capable +crackers out there, trying their own implementations and

they are just asking: How do i code this and that in an INTELLIGENT

(= bits-saving) way?

This is a very good question. What can we (i) do in our actual situation?

Well, there are some ways would be:

- adding an entry list with all those 'dangerous' addresses. With this

we would only have to enhance our coder with a security check whether

the third byte would be the same as the second one or not. If not (our

dangerous case) we would add this address to the 'dangerous list' and

the decoder could look up, whether the actual decoding address would

be dangerous or not. To save space we would have to write a little

managment (for example: was the last address one byte in the past, or

one word or doubleword?) but we want to keep it simple. Anyway, on the

byte level we would add a big chunk of garbage to the file.

- coding the real values and not subtracting one releases the zero,

thus enabling us to code the dangerous sequence in a way like this:

xyz1122 -> xyz11{0x00}22{0x00}

As you can clearly see, we are adding garbage to the file. And as you can

imagine, two-byte-runs are so common, our cruncher would become useless.

One way out of this misery would be to lower the quality of the cruncher

and start up by 4 bytes instead of 3. Still we would add garbage!

- to be honest, on the bytelevel i have no idea how to implmenent an

easy, garbageless cruncher (yet), but when we leave the bytelevel

and enter the bitlevel we have a universe of possibilities ready for us

(still with garbage but much less garbage than expected).

So let's start with the first solution on the bitlevel:

(a bitwasting version - optimizing comes later)

%'?' means that a char is added (8 bit binary)

Ok, here we go:

crunchable file:

xyz1112

the first three bytes cannot be crunched, so:

%'x'%'y'%'z'

the next two bytes, too, are coded normally:

%'1'%'1'

this is what we normally would do:

we count the following '1's, subtract one, AND with 0xff for 8bit-coding.

After that we set the crunch flag to false to code the

next byte(s) normally. If we have more than 256 bytes in a run, we loose

two byte every block of 256s. But except for bitmaps RLE will seldom meet

runs of more than 256.

Counter gives us 1 so the counter is coded:

%0000 0000

Now the Encoder would recognize that the next charakter is NOT a '1' and we have to solve this

problem. One way of doing this would be to count the number of equal chars following and

if the counter was zero add a signal bit and code the run. But if we code a signal bit, we have

to code it in normal files, too. So, if the run was no run, we would add a %0, if we could run a

crunch we send a %1. So for now we add a %0:

After that we code the next two bytes normally:

%'2'%'2'

and as the last run isn't a crunch, we add a %0:

So, the whole file would look like this (SPACEs inserted for clarity):

%'x'%'y'%'z' %'1'%'1'%0 %'2'%'2'%0

So for the cases where we couldn't crunch we would only add one bit. But hey, we forgot to

adapt this new format to the crunchable data. Let's check out the new format on a crunchable run:

xyz1112 becomes

%'x'%'y'%'z' %'1'%'1' %1 %00000001 (+1 as we DO have a crunch - so makes a counter of 1) %'2'

Ooops. What happened? Now we enlarged our crunchable file by one bit. Damn. We want to be sure

that a three byte run doesn't create garbage, not even one bit. As a good solution we would

reduce the maximum run length from 256 (255 +1) down to 128 (127 +1) which can be encoded in

7 bits. Done that we look again on our file:

%'x'%'y'%'z' %'1'%'1' %1 %0000000 (+1 as we DO have a crunch - so makes a counter of 1) %'2'

Good. We crunched the file. The filelength hasn't changed, but we didn't produce garbage. And

when we enter runs greater than 3 we have win situation. We can only hope that we have more

wins than (garbabe-bits / 8).

But, ahem...

Yes, Watson?

I would like to implement another way...

Yes?

What about this dangerous address-list, you mentioned?

Well, yes, we could implement one. All right. The secret to this method

is that the intervalls rely on a straight direction. The intervalls are

always positive. And when the file has a lot of dangerous addresses, the

distances are relatively short. Therefore the distances can be expressed

in only a few bits and not a word or long.

The first 'dangerous' address is encoded as long in the crunched file.

But 'how?' do you ask? Well, it's clear that we would have to add some kind

of switch to the dangerous-address list, isn't it?

How would a crunchable file and our dangerous file look like?

First, we would encode dangerous runs as garbage:

xyz11abcd334455 would be encoded verbatim.

But we would start a 'dangerous' list:

The encoder recognizes the dangerous run (by checking, if the third byte of the

possible run is the same as the second or first) and initializes/updates the list.

The decoder, on the other side reads one entry (if available) AHEAD and knows the

next dangerous address from decoding it. But back to the encoder.

When the first run is to be done, we should code it as a long:

The "11" is found on address 0x00000003 (zero-based of course) and should be coded

as long. Then we go along, code "abcd" and enter "33". As this is a dangerous run,

we have to code it (the difference that is), but we want to code it with as

few bits as possible. And here the great sparks of creativity are fanned.

We could possibly do:

Code two signal bits for four different modes:

%00 for long

%01 for three bytes

%10 for word

%11 for byte

and let those headerbits follow the specified number of bits (32, 24, 16, 8). Yes, this means,

we have to implement a bitreading routine for our decruncher. But hey, those are

very useful for a lot of purposes. Don't be lazy. Once you've written a pair of

bitswriting/bitsreading-routines, you'll be amazed about the new possibilities of

addressing things.

Another way would be to do a Huffman-Version of these two bits:

%0 for byte (should be the most happening intervall)

%10 for word

%110 for three bytes

%111 for long

followed by the appropiate number of bits.

If you are crazy enough you could run a counter along and

calculate adaptively an always optimized Huffman-tree for these two bits ;)

Next possibility, please:

if you are sure that the distances will be VERY short - you could do a variable coding:

divide the distance by 3. Save the remainder. In a loop running from 1 to the counter add

%11 into your dangerous-list. Then add the remainder in binary, but with two bits. Examples:

Intervall added bits:

0 %00

1 %01

2 %10

3 %11 00

4 %11 01

5 %11 10

6 %11 11 00

7 %11 11 01

8 %11 11 10

9 %11 11 11 00

10 %11 11 11 01

...

To complicate things, i thought: what, if i want to create a flexible and variable code, giving

me good ranges without exploding numbers of bits when i reach higher numbers? I searched my

library and came up with an idea i'll explain now.

But first the useful, but expensive unary code:

The unary code has as condition that the number to be encoded is greater 0.

Imagine you want to code a number with bits. Imagine you don't have a single idea, what the

binary system is. You could came up with the idea of writing %1 as often as your number

indicates. After that you would send a %0 as delimiter. Examples:

value bits (all binary):

1 0

2 10

3 110

4 1110

5 11110

6 111110

7 1111110

8 11111110

9 111111110

10 1111111110

...

For normal cases this coding method is not useful, but for some cases it is the foundation.

And for values between 1 and 3 nothing is better.

Now Imagine, you would use the number of %1 you read as SHL-argument. You would get a power of 2.

But what about the lower bits? When i code %1110 i read three %1 (plus %0 as delimiter) and know

that i have a basic value of 2^3 = 8. If i code %11110 i get 2^4 = 16. What about the rest?

Well, it just has to be inserted, that's all. The remainder is just added to the binary.

This method is called y - code (it's an greek y-char). You tell the decoder what he has still to read

and you also know the power of 2 that these other bits are to be added.

Let's create a y code for the number 9:

First we have to find the powers of 2 our number lies in:

The number 9 is between 8 and 16, so we use 8 as base. 8 is 2^3 so we use the unary code to code

3: %1110. Then we subtract 8 from 9 giving us a rest of 1. As our power of 2 is three the rest

of the code MUST be expressable in 3 bits. And it is. We code the remaining 1 in three bits:

%001. So the whole code for 9 would be: %1110 001. Here are the numbers 0 to 10 (decimal):
Number Code (in binary)

1 0

2 10 0

3 10 1

4 110 00

5 110 01

6 110 10

7 110 11

8 1110 000

9 1110 001

10 1110 010

And now we could combine the above mentioned divide-by-three method with the last part of the y-code,

that is, exchange the first, the unary part with the divide-by-three-method.

Let's code the number 9 again:

9 is 2^3 + 1. So our power of two is 3. To code 3 we do:

3/3 = 1 remainder 0. So 1 x %11 and remainder %00 -> %11 00.

And after that we would encode the rest in three bits: %001.

So the whole encoding would look like:

%1100 %001.

Now let's encode 129 with both methods:

129 = 2^7 + 1 = %11111110 0000001 (y code) (8 + 7 = 15 bits)

129 = 2^7 + 1. 7 = %11 11 01 -> %111101 %0000001 (6 + 7 = 13 bits)

Of course you are free to combine all mentioned methods together. It may be a good idea to pre-create

a dummy-entry, counting the number of bits needed for writing the entry. By looping thru all your

available methods you could switch to the best method for the actual intervall. The only premise is

that the decoder uses the same routines as the encoder.

I hope that helped. May be i will refer to these methods in later chapters, so study them and take

your time. For more information on coding bits - go to your local library and lend:

"Managing Gigabytes" from Ian H. Witten, Alistair Moffat, Timothy C. Bell. But be warned: This it

not an easy book to read! Quite the contrary: I would be happy if i'd understand half of the

book with it's thousands of formulas ;)

But now let's pass to chapter 5

---Joa's little essay on performing the art of compressing data - little big interlude END---

By Joa Koester (JoKo2000@HotMail.Com)

This essay is free to be copied and read and spread as long as

you are decent enough to leave my name in it.

If you have corrections, comments, better examples than the ones used

in this essay, etc. - drop me a line.

OK, let's dive into the world of crunchers and munchers...

Lempel - Ziv

A Milestone in crunching history

Pease porridge hot, pease porridge cold,

Pease porridge in the pot,

Nine days old.

Some like it hot, some like it cold,

Some like it in the pot,

Nine days old.

(...now he has gone totally nuts ;)

*Ahem*

No, i'm not nuts. This is just a textbase suitable for crunching. Just look at it. Aren't there a lot of

bytesequences identical? Shouldn't there be an elegant way of crunching this? Yes, of course there is.

The secret lies in the observation, that bytes (symbols) that appeared right now had ALREADY appeared

in the recent past. Consider the second line as our actual line. The bytesequence "Pease porridge " is the same

as in line one. In the sixth line the bytesequence "Nine days old.{0x0d, 0x0a}" is identical to the third.

But if we already HAVE the bytes that we need, we don't need to write them anymore. Just for the sixth

line, we could just write a reference to the file, like:

Pease porridge hot, pease porridge cold,

Pease porridge in the pot,

Nine days old.

Some like it hot, some like it cold,

Some like it in the pot,

[ ->Line 3, 16 bytes]

If we could express this [ ->Line 3, 16 bytes] in fewer bytes than 16 we

would have crunched a good portion of our file.

In the first line, we could put a reference to the bytes of "ease porridge"

as the initial 'p' is not identical to the 'P' of the first "Pease". But

with a reference we would write something like:

Pease porridge hot, p[->Line 1, Byte 1, 14 bytes]cold.

If we write this sequence in less than 14 bytes we crunch.

Some thought like that must have been spinning thru the heads of Jacob Ziv and Abraham Lempel when 1977

and 1978 they came up with totally new ways of compressing data. The '77 version is exactly what i'm

explaining here. The output of your crunch is something with a reference and a counter. But how do

you come up with it?

Well, the original LZ77 alg uses something called a 'window' and the source is sliding thru the window,

scanning for repeatings. Well, this window is - in the end - nothing but a loop into the past of your

data you are crunching. You have a current point. This point points to your actual data to be crunched.

What you do is to look for occurences of the bytes you are looking at right now in your past. Somehow

these occurences are in the near past (a good guess: about 8 kbyte) and the more you look into the past the more

unprobable a crunch gets. Let's have an example:

abcdxyz000abcd123

YOU recognize immediately the second appearance of "abcd", but how

does the algorithm?

Well, let's imagine your point was already on the last '0' and now

we are entering the 'a' of "abcd".

abcdxyz000abcd123

We must have a past pointer ready. As a past pointer it starts one

byte 'behind' our actual pointer:

abcdxyz000abcd123

Now we compare - and fail. So we move our past pointer down by one

back into our past:

abcdxyz000abcd123

Now we compare - and fail. So we move our past pointer down by one

back into our past:

abcdxyz000abcd123

... This is what Lempel-Ziv meant with their window: A pointer that

scans the past.

When we finally reach the 'a', our compare flags:

abcdxyz000abcd123

Jippieh! Hit! And now? Well, we make a copy of our pointers and install runpointers.

From then on we run back into the future, until we reach the end of the data or the

compare fails - whichever comes first.

abcdxyz000abcd123

flags until...

abcdxyz000abcd123

Well, the compare fails after four bytes. That means, we have a possible crunch of four bytes

ahead. That is information number one. Information number two is the distance between our

two pointers. A simple subtraction gives us this distance. Now all we have to do is to encode

a format with the distance and the number of crunched bits and we will have our own

implementation of LZ77. I think the original format was 12 bits fix for distance and 4 bits fix

for the number of bytes crunched. I don't think i'm going to surprise you if i tell you that

in a normal file 16 equal sequence-bytes are very seldom. Most occuring byteruns are 2, 3, 4, 5+.

In that order. And you don't need 12 bits fix. Use your imagination. There a lot of ways of

creating such a distance format. One good beginning would to connect the runlength and the

distance. It is most reasonable to allow a bigger distance for a 5+ run and to truncate the

distance for the more occuring 2-runs, thus giving you less bits to write for the most occuring

crunches. As you are crunching 2 bytes you will only have 16 bits space (2 bytes = 2 * 8 = 16).

As you want to gain something here too, i suggest a distance of 9 bits maximum.

When you manage to stay under 15 bits for the 2 crunch, you will have a good format.

A format i used (with a scan of 2048 byte), was:

2crunch (16 bits original): %0%000000000 (%0 for 2crunch, 9bits distance)

3crunch (24 bits original): %10%0000000000 (%10 for 3crunch, 10bits distance)

4crunch (32 bits original): %110%00000000000 (%110 for 4crunch, 11bits distance)

5+crunch (40+ bits original): %111%(variable)(%111 for 5crunch plus sequencing bitd

for coding distance and number of bytes)

You are of course free to use whatever comes into your mind. And do yourself a favor

and DO IT! It is good fun and you learn a lot.

But back to our scanning algorithm. We have a few problems to examine:

What happens if i come up with a sequence like: abcdefg123abcd###abcdef ???

What about the start and the ending of our data (beginning and ending of scanning)?

What about speed?

What about garbage?

all right, all right.

We will crunch the above mentioned bytes together. Then your questions will be answered.

Important points:

We install a crunch-counter, telling us, how many bytes we have crunched.

If the counter remains at 1 we will have not crunched anything and the

current byte is to be written as garbage.

We also install a Crunch-Distance for comparisons.

Let's begin.

Obviously we start at the first byte:

abcdefg123abcd###abcdef

Now, as we don't have a window yet, we have to write this as garbage. And as we now recognize,

that we don't know how many bytes garbage we will have, we have two options: write the garbage

away binary reversed and build the decruncher to read your file from behind back to the front

to write the garbage into some temporary memory/file/whatever and when you reach your crunch

you know how many bytes garbage you had, code this number and append the garbagebytes from your tmp.

The first solution would also mean that the scan-alg would have to scan the actual future (which

would be the decrunchers past), but there's no real difference between an incremental scan or

decremental scan.

Solution ONE would look like: (when we reach the second 'abcd')

321gfedcba (not completely binary reversed for clarity)

then we have the count of our garbage (0x0a) and i code it for example using

the 'divide-by-three' method: 10 / 3 = 3 rem 1 -- %11 %11 %11 %01

this would make -- binary reversed -- :

%10 %11 %11 %11

plus a %0 for garbage --

and if we add this:

(321gfedcba (not completely binary reversed for clarity) ) %10 %11 %11 %11 %0

As in this variation the decoder would read the bits from behind it

would get the codes in correct order:

%0 for garbage

%11 %11 %11 %01 counter of garbage

abcdefg123 and then the garbage bytes re-reversed to original state

The other way would be to save the byte somewhere.

So when we reach the crunch at 'abcd'

we would have:

[tmp]abcdefg123

we would code

the %0 for garbage, the counter %11 %11 %11 %01

and the bytes.

In this version the decruncher would read the file from the start

and not from behind. Both versions have their advantages and

disadvantages and it's just a matter of taste not of difficulty.

For this example i assume a [tmp]-solution, so we write the 'a' to our [tmp]-area.

After that we increment our pointer and start anew.

The Crunch-Counter is set back to 1.

abcdefg123abcd###abcdef

Now we can have a look into the past.

We install our PastPointer one byte behind the actual pointer and

run a compare.

abcdefg123abcd###abcdef

Whew. 'b' and 'a' don't match. So we'll continue our scan either until we reach the start of the file

or we reach the end of our scan-reach. As we have reached the start of the file we look at our

Crunch-Counter: still 1. So this byte is also garbage. Away with it ;)

Reset your Crunch-Counter (redundant in this case, i know, but when you code the alg you'll see that

an If-Then construct is more timewasting than the move-operation) and increment your actual pointer by

the Crunch-Counter (1):

abcdefg123abcd###abcdef

Install the Scan-Pointer:

abcdefg123abcd###abcdef

And start scanning.

As the Byte at distance -1 is not equal to the actual byte we'll decrement

our pointer by one and do this until we:

- reach an equal byte,

- reach the start of the file

- reach the end of our scan-reach.

Our Scan-Pointer is at the 'a' and the start of the file is reached.

As we look at our Crunch-Counter, we still have a 1. So away with it.

This goes on until we reach the second 'a' at position {0x0a} (zero-based).

We'll continue the situation one byte BEFORE the crunch:

abcdefg123abcd###abcdef

After this last comparison we write the '3' as garbage. Our [tmp] look like: [tmp]abcdefg123, we

have a garbagecounter of 0x0a and a Crunch-Counter of 1. Now we go ahead and increment our

crunch-pointer by the Crunch-Counter (1).

abcdefg123abcd###abcdef

The scan will fail until the very first byte of the file:

abcdefg123abcd###abcdef

Now, as written some paragraphs above, we install copies of our

pointers and let the copies run until either we reach the end of

the file or the cmp fails.

abcdefg123abcd###abcdef is ok.

abcdefg123abcd###abcdef fails.

We compute the runlength and compare it with our Crunch-Counter (currently 1). As 4 is greater than 1 we

have a crunch and continue happily. We also set the Crunch-Counter to our new value (4) and adjust the

Crunch-Distance to 0x0a.

So we have 0x0e (the pos of our crunch-point-copy) - 0x0a (the pos of our crunch-point) = 4 as runlength and

0x0e - 0x04 = 0x0a as distance.

We want to encode this. But first we have to get rid of the garbage. As i assumed we had the bytes in some

kind of [tmp] and now, before we encode the crunch, we encode the garbage:

%0 for garbage

%11111101 the counter

abcdefg123 the bytes themselves

Now, as we have a telling bit for garbage and crunch

(0 for garbage, 1 for crunch), we have to encode the

telling bit for the crunch, right?

Think for a minute...

.....

Back?

Did you get it?

Yes, in this case you don't need a telling bit for crunch.

The explanation goes as follows:

These are the cases we have (theorethically):

garbage, garbage

garbage, crunch

crunch, garbage

crunch, crunch

Can we have a crunch after a crunch? Yes.

Can we have crunch followed by garbage? of course

Can we have garbage followed by crunch? Yep.

Can we have garbage after garbage? In this system we implemented - NO!!!

That means, that, after coding garbage we don't need to ouput a

telling-bit for crunch. This saves us a lot of bits, believe me.

So after the garbage we code the crunch-sequence:

(%1) omitted due to using brain ;)

%110 for 4crunch

%00000001010 for distance

We increment our original crunch-pointer by the Crunch-Counter (4),

reset the Crunch-Counter back to 1 and continue our normal scan.

abcdefg123abcd###abcdef

The first '#' will be emitted as garbage. Our Crunch-Counter is reset to 1.

But the next one is quite interesting:

abcdefg123abcd###abcdef

Just one byte behind we find a crunch. And now? Well, we continue as before.

We install copies of our actual pointer and let them run.

abcdefg123abcd###abcdef is ok

abcdefg123abcd###abcdef fails.

As we compute the run length (2), we compare it with our Crunch-Counter (1)

we see, that we are greater. So we have a crunch.

We compute the difference (1) and set the Crunch-Counter to our new run-length (2).

We also set the Crunch-Distance to the right difference (in this case 1)

THEN WE CONTINUE OUR SCAN!!!

But as we don't have a second '#' in the file we come up with the values we just

computed.

As we just had a garbage out, we don't emit the telling bit for crunch and

send:

%0 for 2crunch

%0000000001 for distance.

After that we increment the Crunch-Pointer by the Crunch-Counter (2), reset the

Crunch-Counter to 1 and continue.

abcdefg123abcd###abcdef

The scan will fail until the first 'a' on position 0x0a:

abcdefg123abcd###abcdef

We react as we are now used to:

Install pointer-copies and let them run.

abcdefg123abcd###abcdef is ok

abcdefg123abcd###abcdef fails.

So, we compute the runlength (4) and compare it with our actual Crunch-Counter (1).

As it is greater (= better) we save it into our Crunch-Counter. We also save the

distance in the Crunch-Distance.

After that, we continue.

abcdefg123abcd###abcdef fails.

We will have lots of fails until the second 'a':

abcdefg123abcd###abcdef fails.

Now, we have a crunch again. You already know whats happening, so let's watch the

movie :)

abcdefg123abcd###abcdef is ok.

unfortunately, after this step we cannot continue, as our file is at end. So we stop our loop

and compute our crunch-len: 6. We compare it with our Crunch-Counter (4) and find it greater (=better).

So we actualize our values and set Crunch-Counter to 6 and the Crunch-Distance to 0x11.

Then we continue our loop.

Hm, the crunch-pointer is at EOF, so we look, what we have:

Crunch-Counter > 1, in fact even 6, so we have a great crunch here.

As the last action was a crunch, we send our telling bit for crunch

and after that we encode the Crunch-Counter and the distance

%111

%(your code here)

And then we are finished. Flush all streams, close all files, delete all mem and exit.

This way of scanning for the best (=longest) match is called 'greedy evaluation', btw.

The decoder is much easier to program:

//assuming that the original length of the file is known and

//we have a output, which is incremented after each byte written.

//we also must have a pointer to our actual address to be written,

//or else we could not have references to our past.

while (Actual_Address

The Scan-Method i showed you is of course pretty slow. Every time you scan thru a 8 kbyte area

you read the bytes x-thousand times. A lot of tricks were invented to ease this problem.

One trick is to save the following byte of the actual byte. When you than scan into your past

and you get to the same byte you than can immediately scan, if the second byte is also equal.

If it is, you will at least have a 2crunch. Example:

abcd12345a6789abcd

Scanning thru your memory with this trick would lead to a

Crunch-Second-Guess-Bytes with the value 'b' in this case.

Now after some scanning we reach the following situation:

abcd12345a6789abcd

We reached an 'a', so we normally enter a compare loop - but not now. Before this we compare our saved

Guess-Byte ('b') with the second byte after the scan-byte ('6'). As the compare fails, we continue

our scan without having to enter a timeconsuming loop.

The evolution to this trick is to check not the second byte but the [Crunch-Counter]-byte.

As in the normal loop it will be 1 we have exact our second byte. But if we already had a

crunch, we save the last byte of the crunch into this Guess-Byte. When we reach another

byte signalling a possible crunch, we check ahead the Scan-Pointer[Guess-Byte]-byte and

see if it's worth it.

When you think it over, you realize that we can then exterminate the Guess-Byte again and

just compare to the [Crunch-Counter]-offset. Example:

abcdefg..abcX..abcd..abcdefg

Now, when we reach the following situation:

abcdefg..abcX..abcd..abcdefg

We start to scan into our past. The first promising compare comes up:

abcdefg..abcX..abcd..abcdefg

We now compare the ^[Crunch-Counter]-byte with the *[Crunch-Counter]-byte and as the

Crunch-Counter is 1 we compare 'b' with 'b', so we continue.

Our loops stops with a run of 4. We now set our Crunch-Counter to 4 and continue

our scan. Then the next 'a' appears:

abcdefg..abcX..abcd..abcdefg

We now again compare the ^[Crunch-Counter]-byte with the *[Crunch-Counter]-byte (should

really be saved into a register) and see, we compare a 'X' with a 'd'. As the compare

fails we just ignore this byte and continue our scan into our past. Soon we reach the

last 'a':

abcdefg..abcX..abcd..abcdefg

When we now compare the [Crunch-Counter]-bytes we have a positive flag and can begin

to crunch.

Another method of speeding up the main-scanning alg is to implement a jump-table.

The table would look like this (excerpt for the values 'a' to 'd'):

[a] [b] [c] [d]

0 4 4 4

for the following source:

abcd.bcd...

The DISTANCE between the first 'b' and the second 'b' is stated in this table.

Now our scan algorithm would just have to look at the actual byte, look it up

in the table and if the value is > 0 sent the scan directly there. If the

value IS 0, we have a garbage byte. Sounds pretty fast, isn't it? Yes it is.

But the building of such a table is a little bit difficult. I explain ONE way

of creating such a table. For the sake of clearness i will explain for BYTES

but it's not so difficult to enhance this mechanism for WORDS.

Ok, what do we need? Watson?

Here, Sir. Well, i think we need something the size of our scan-area, namely the

distance-table. And then i would think for constructing a 256-entry-table would

be useful.

Very good, Watson. That's exactly what i wanted to hear. There will be just

a little change, but don't sweat it.

Yes, we have a table for the scanner and

for constructing we have a temporary table for the 256 possible Byte-possibilities.

Now, what do we do?

Assume we have the following source:

abcd..bbc

and we want to create our jump-table.

At first we would initialize all tables with zeros. Then, in a loop we read a byte

and from the 256-table we read the last address. We subtract this from the actual address

and if the adresspointer was 0x00000000 before we write this difference into our jump-table.

Explained on the example, this would be something like:

012345678 (Address)

abcd..bbc (Source)

We read 'a'. We look up 'a' and come up with 0x00000000 as we just initialized the table.

Our actual adress is 0x00000000, so the difference is also 0x00000000. As our scanreach

is just under 8 KByte, we can save the difference as short (16 bit). So our tables

would look like:

char 256-Bytetable Adresspointer Jumptable

a 0x00000000 0x00000000 0x0000

b 0x00000000 0x0000

c 0x00000000 0x0000

d 0x00000000 0x0000

. 0x00000000 0x0000 ('.' just for the clarity)

b 0x0000

c 0x0000

We compute the next char: 'b'.

Adresspointer is now 0x00000001. We write down the difference to 0x00000000 into the table,

but as the entry was zero before, we don't write it into our jump adress. This is to

prevent a jump to an address where the actual char should be, but won't. Imagine we

would write a jump-table-entry with the calculated offset. We would then indicate

that the next 'b' in reach would be 0x0001 bytes in our past. But when you look into

Address 0x00000001-0x00000001 = 0x00000000 you see an 'a' there and not a 'b'. Therefore

we only write into the jumptable when we already have an offset. This only happens

until the char is reached the first time.

The tables would look like this now:

char 256-Bytetable Adresspointer Jumptable

a 0x00000000 0x00000001 0x0000

b 0x00000001 0x0000

c 0x00000000 0x0000

d 0x00000000 0x0000

. 0x00000000 0x0000 ('.' just for the clarity)

b 0x0000

c 0x0000

Now with 'c', 'd' and the noninteresting '.' (just imagined as

random bytes) we have the same situations. After processing the last '.'

we have the following table:

char 256-Bytetable Adresspointer Jumptable

a 0x00000000 0x00000005 0x0000

b 0x00000001 0x0000

c 0x00000002 0x0000

d 0x00000003 0x0000

. 0x00000004 0x0000 ('.' just for the clarity)

. 0x00000005 0x0000 ('.' just for the clarity)

b 0x0000

c 0x0000

And now we come to the next char: 'b'. We look it up in out table and we find a

non-zero entry. We get 0x00000001 and we have an actual Adresspointer of 0x00000006.

We subtract this and get a difference of 0x0005.

We write this into our jump table at the entry [Adresspointer] of our Jumptable - 0x00000006 -,

we write the Addresspointer into our 256-Byte-Table

and we get the following states:

char 256-Bytetable Adresspointer Jumptable

a 0x00000000 0x00000006 0x0000

b 0x00000006 0x0000

c 0x00000002 0x0000

d 0x00000003 0x0000

. 0x00000004 0x0000 ('.' just for the clarity)

. 0x00000005 0x0000 ('.' just for the clarity)

b 0x0005

b 0x0000

c 0x0000

As we continue with the next byte, we get another 'b'. We look it up in our 256-byte-table

and receive a 0x00000006. As our actual Addresspointer is 0x00000007 we get a difference

of 0x0001. And as there is a non-zero entry in the 256 byte-table we can write the

difference into the jumptable at the 7th position of our Jumptable:

char 256-Bytetable Adresspointer Jumptable

a 0x00000000 0x00000007 0x0000

b 0x00000007 0x0000

c 0x00000002 0x0000

d 0x00000003 0x0000

. 0x00000004 0x0000 ('.' just for the clarity)

. 0x00000005 0x0000 ('.' just for the clarity)

b 0x0005

b 0x0001

c 0x0000

Now the next char is a 'c'. And as we can see we have a non-zero entry in our 256-table.

We take our actual Addresspointer - 0x00000008 - and

subtract the value of the entry - 0x00000002 - and

finally come up with a jump of: 0x0006.

We write the entries down and have our final jump-table ready for use:

char 256-Bytetable Adresspointer Jumptable

a 0x00000000 0x00000007 0x0000

b 0x00000007 0x0000

c 0x00000002 0x0000

d 0x00000003 0x0000

. 0x00000004 0x0000 ('.' just for the clarity)

. 0x00000005 0x0000 ('.' just for the clarity)

b 0x0005

b 0x0001

c 0x0006

Now, how do we search with this kind of table? Let's do it together. You will be amazed:

We initialize our Crunch-Counter with 1 and our Crunch-Distance with 0. Then we get our

first entry FROM THE JUMP_TABLE!!!. We fetch a 0x0000 and immediately write out garbage.

Now that's fast!!! We increment our Jump_Table-Offset by the number of the Crunch-Counter

(in that case 0x0001) and continue.

The bytes 'b', 'c', 'd', '.', '.' are also written out as garbage. And now we enter

our first non-zero entry. We get a 0x0005. We install copies of our actual pointers,

subtract 0x0005 from the copies, subtract 0x0005 from the Jump_Table-Offset-Copy

and start the second compare-loop. Our Jump_table_copy would point to the 1st offset

in the jump_table, our address-pointer-copy would point to the 1st byte of the area we

are crunching.

Unfortunately the compare fails immediately after the first byte.

So we look after the entry at the now-actual Jump_Table: 0x0000. Garbage. We return,

write out one byte garbage, return to our normal pointers, increment the Jump_Table pointer

by the number of Crunch-Counter (1 in that case) and continue.

We reach a further non-zero entry. We install copies of our pointers, subtract the fetched

values from them (0x0001) and let a compare-loop run.

Our copies would look at address 0x00000006 and 0x00000007.

Unfortunately we fail after the first byte.

Now we fetch the Jump_Table-offset at the now-actual byte and we get a 0x0005.

We jump further 0x0005 bytes into the past and start a compare loop.

Our copies would look at address 0x00000001 and 0x00000007.

Now we fail after two bytes. Our Crunch-Counter should now be two.

We save the distance to the real actual address as well (0x0006).

After the outer-loop finished we have a two byte-crunch ready.

Now as you can see this kind of comparing is a zillion times faster than the one explained

before. But it most important that you understand how the basic mechanism was implemented

to understand the following improvements.

There is just one thing to be explained now:

We have a Jump_Table. We scan thru our file using this Jump_Table. How can i keep this table

as small as my scanreach is?

Well, the answer is: swapping!

When you scan thru the file and you create a table

you want to use the whole reach of the table, right?

Imagine you would use a table with a reach of 8 bytes. You would have a reach of 8 bytes

until you come to position 7. When you then go address 8 you have to recreate your

table. Now, there is nothing wrong with this. But imagine that on position 8, when

scanning thru the bytes you should have a reference to bytes on position 6. But you

haven't, because you cut all references to the past and create a new 8-byte wide

area. This would work, but you would loose some crunches. And there is an easy way

of staying in the flow of references: You double your scanreach in the Jump_Table!

With this trick you have still all references without any problems.

And now you can do your swapping easily: When you reach the final end of the

Jump_Table-Area you copy the upper half into the lower half of the Jump_Table-Mem and create

the upper half anew:

(Source viewed in 8 byte blocks)

0 1 2 3

0123456712345670123456701234567.....

(jumptable)

0 1 1 2 2 3

0123456701234567 becomes 0123456701234567 becomes 0123456701234567 becomes...

You only have to set your Jump-Table pointer into the lower half of the table again.

With the next increment it will enter the upper half again and will have a full

reach ready.

Phew! That was a long essay. But i hope i could bring you something nearer.

Next time i'll explain LZ78 and LZW, the basic algorithm of RAR!

Till then,

Joa

P.S.

(delran: Your sorting idea is welcomed and i will see, if i can come back to

this idea when i'll explain Burrows-Wheeler-Transformation)

homepage

links

anonymity

+ORC

students' essays

academy database

tools

counter measures

cocktails

antismut

bots wars

search_forms

mail_fravia

Is reverse engineering legal?

10 July 98	Joa	~	crunchi1.htm	Little essay about the various methods and viewpoints of crunching	papers	~	fra_0126
10 June 98	Joa	~	crunchi2.htm	Little essay about the various methods and viewpoints of crunching II	papers	~	fra_0129
17 June 98	Joa	~	crunchi3.htm	Little essay about the various methods and viewpoints of crunching III	papers	~	fra_012E
17 June 98	Joa	~	crunchi4.htm	Little essay about the various methods and viewpoints of crunching IV	papers	~	fra_012F
10 July 98	Joa	~	crunchi5.htm	Little essay about the various methods and viewpoints of crunching V	papers	~	fra_0133