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