Hi Ticker,
yes, the tree is still incomplete.
I use the existing tree and whenever it fails to decode a string I try find out
the
missing character looking at the original map with the search.
I think you have no chance to do that without the full index file.
I need a pause now and maybe
Hi Gerd
Do you fill in all the empty leaves with noticeable characters and
report them so you can spot patterns that haven't been defined and
their usage.
There seem to be some chars missing still (qwxy23). I don't know if the
shields/thin/fat separators make it into Mdr15
Ticker
On Tue,
Hi Ticker,
yes, I'm close to done with the display tool being able to decode the string
from Adria Topo.
The 'F' is causing trouble, so probably something in my tree is still wrong or
incomplete:
Here's my actual code to dill the Huffman tree:
add("111", 'A');
Hi Gerd
Just got back to looking for some more. In addition I have:
000(space)
B 001001
D 00111
I 11001
P 001000
U 000111
V 01010
but you've probably got much further anyway
Thinking of various algos to represent the tree and considering what
they would make of the example Mdr16 data I
Hi Ticker,
the bits in MDR15 are processed from left to right. Strings in (uncompressed)
MDR15 are null terminated.
So, if the MDR15 contains e.g. 07FFB8 and the offset is 1 the decode has to read
111 111 111 0111 xxx
-> AAA\0
The xxx bits are ignored by the decoder, since the 0111 sequence is
Hi Gerd
I was wondering if something like this could be done.
Do you mean bits are read right/low to left/high, effectively reversing
as it reads or is this the way the BitReader/Writer class works?
Assuming bits in natural order, 0111 does look like the string
terminator as it occurs at end,
Hi Ticker,
I looked at those offsets into MDR 15 which start a short string, means, next
offset is only 2 bytes further.
It seems the bits in MDR15 are read from left to right, always starting at a
given offset, so the BitReader class isn't useful.
I think I've identified a few codes, but don't
