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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkg...@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
111 -> 'A' 0111 -> '\0' 1010 -> 'N' 1011 -> 'O' 1100 -> 'I' 1101 -> 'R' 00101 -> 'C' 00110 -> 'S' 01000 -> 'T' 01001 -> 'M' 01010 -> 'V' 0000111 -> '1' 0001001 -> '.' 00001010 -> '0' 00000100 -> '6' 00000111 -> '7' 00001000 -> '8' 00001011 -> '4' 00001010 -> '7' 00001001 -> '9' 00000011 -> '5' UL
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
