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

Tue Dec 14 10:54:18 GMT 2021

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 the null terminator.

Attached is my current knowledge about the table. Just a matter of time to find the rest...
Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 14. Dezember 2021 11:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is    some    kind    of      codebook.

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

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: huffman-table.txt
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20211214/fd279ca2/attachment.txt>