Re: [libredwg] Comprlen

[Till Heuschmann]

Hi Dave,

have you seen that there is a separate branch in libredwg where the AC1021 
(2007) decoding takes place? The branch is named "r2007", you can access it 
with "git checkout r2007".

At the offset 0x80 you have to read 0x3d8 bytes. These bytes are RS encoded so 
that you must decode/rearrange them:

lets assume the given bytes:  ABCABCABCABC...
which must be rearranged to:  AAAA...BBBB...CCCC...

note there are 239 A, 239 B and 239 C

The resulting buffer you can interpret like you mentioned: 8bytes crc, 8bytes 
key, 8bytes compressed data crc, 8bytes compressed len

All this is implemented in the function read_file_header() in decode_r2007.c


To make it clear, the 239 bytes are the bytes with the real data. There are 16 
other bytes (the parity bytes) which make it possible to detect/correct errors 
(following the RS encoding). In this example (libredwg) they are ignored. 


Am 08.06.2012 um 23:08 schrieb Dave Coventry:

> I'm having a look at an AC1021 dwg file.
> 
> At Offset 0x80 I have the following data:
> 
> 
> 0x80 A2 B5 20 01 24 9A 03 11 ---CRC
> 0x88 1F 62 58 70 19 A0 7B 6F --- Unknown Key
> 0x90 10 EE 34 01 01 65 7F 00 --- Compressed data CRC
> 0x98 AA 6E 37 45 --- ComprLen
> 
> The 5.2 Specification says the following: "Note that if ComprLen is
> negative, then Data is not compressed (and data length is ComprLen)."
> 
> I'm assuming that Reed-Solomon is not at work here.
> 
> Does the offset 0x98 indicate the size of the data?
> 
> The AA in the last byte indicates that the leftmost bit is set, which
> means that it is negative.
> 
> Using two's complement:
> 
> 10101010011011100011011101000101 inverted:
> 01010101100100011100100010111010+1=01010101100100011100100010111011
> 
> which is 1,435,617,467, so the data length is 1.4 Mb.
> 
> Which it can't be because the total file size is only 107,168 bytes.
> 
> Where am I going wrong?
>