[mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

Tue Dec 14 10:42:45 GMT 2021

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, excluding padding, of all the strings
starting at 1,11,16,20,25

>From what you wrote previously: 
> "Baca Pri Podbrdu"
> When I change the code to return offset 11 instead of 1 the string
> "Bavsica" is displayed
The BA sequence should be in the leading part of 0010011110.

Assuming you get a few more chars consistently and can draw up part of
a tree consistent with huffman decoding, then Mdr16 must represent this
and, as latin1 chars are not obvious, they can't be byte aligned but
rather placed, in-line, in the bit-stream that represents the tree. So,
need to look at different ways a tree with just info in leaves can be
represented and try and match it to what we see

Ticker

On Tue, 2021-12-14 at 09:29 +0000, Gerd Petermann wrote:
> 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 take them for granted:
> 0111 -> '\0' (quite obvious since we know that the uncompressed MDR15
> starts with a 0x00 and the compressed one starts with 0x70)
> 111 -> 'A'
> 1101 -> 'R'
> 1100 -> 'K'
> 01000 -> 'T'
> 00001010 -> '0'
> 00000100 -> '6'
> 
> I can continue to identify more codes. A result could be a hard coded
> Huffman tree in MdrDisplay,
> which should then be able to decode all strings in Mdr15 for the given
> mdr file.
> Once that works I would try to understand how the data in MDR16 encodes
> the tree.
> Maybe you have another idea?
> 
> Gerd