Is this a valid LZO compressed byte string?

[Slaunger]

Hi list.

I am trying to write a parser in Python 2.5.4 for a proprietary data
file format, which consists of fixed length C-struct like data headers
and variable length LZO compressed data payloads (the compressed data
length is in the header and known). The decompress function in my
lzo.pyd module raises an

lzo.error: Header error - invalid compressed data

whenever I try to LZO decompress any of these bytestrings. I would
like to know if others are capable of LZO decompressing an example
bytestring from a data file or if the bytestrings are truly corrupted.

Here is an example an LZO compressed bytestring consisting of 707
bytes, which raises this error:

'''
\x02\x00\x00\x00\x00\x00 \x03\x00\x00\x04?\x00\x00?CB< \x03\xa8\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc3\x8d
\x00D
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc3T?
\tP? \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xee
\xfc? \t\xa4@
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b
\xa4\x00\x18\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00#X
\x7f
\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xb6r?
DA\x18\x00\x00\x00\x00\x00\x1b\x84\x80\x03<FMONF
\x00\x00\x00\x00\x00\x03\x90\x14 \x00\x00\x00\x00\x00\x9cx\x14\x01@HLH
\x00\x00\x00\x00\x00\x02\x00@\x06@Q\\cfd]Q? \x00\x00\x00\x00\x00\x9c
\x88+ \x00\x00\x00\x00\x00\x01\xdc\x16\x02AHLJC
\x00\x00\x00\x00\x00\x01\x84\x14\x06I[hoqoi\\J
\x00\x00\x00\x00\x00\x01\x94\x14 \x00\x00\x00\x00\x00\x9cp\x14
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xee\xff?
\x00>A \x00\x00\x00\x00\x00\x03`\xab\x06J]jqsqk^L
\x00\x00\x00\x00\x00\x9c\x88k \x00\x00\x00\x00\x00\x02\xdc\x16
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xee\xfc?
\x00\x00\x00\x00\x00\x02tT\x08\x00\x00\x00EXdlnleY
\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xd9\x08\x80
\x00\x00\x00\x00\x00\x05\x00@\x03LX_a_X
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x9e\xf8\xbf\x11\x00\x00
'''

The decompress function in my lzo.pyd module uses the

lzo1x_decompress_safe

lzo library function "under the hood". I have tracked down some other
C-code which is used to parse the same data for another application,
and in this code, the variant

lzo1x_decompress_asm

lzo library function is apparently used to decompress the same data
and in that application it is apparently succesful (on the other hand
this function has no internal error checking)

From the LZO FAQ:

http://www.oberhumer.com/opensource/lzo/lzofaq.php

It is stated that it is important to use the same LZO algorithm for
decompression as was used for compression. Since the C code uses the
LZO1X algorithm for decompression, I deduce the data must have been
compressed with the LZO1X algo as well (this is also the recommended
general-purpose algo), thus the lzo.pyd's internal use of the slightly
differently named "safe" lzo1x function should yield the same output,
as it is only the speed of the implementation which should be
different between lzo1x_decompress_safe and lzo1x_decompress_asm.

I have verified that I can compress data and decompress them again
using the compress and decompress function of my lzo.pyd module. I
have noted a difference though between the very first byte of
compressed bytestring generated this way and the ones I find in the
data file.

Bytestrings compressed with lzo.pyd always begin with either
'\xf0\x00\x00...' or '\xf1\x00\x00..' depending on whether I set the
compression level to 1 or 9.

Bytestrings in the data file always begin with '\x02\x00\x00...' as is
also apparent in the example above. I am wondering what that '\x02'
means? Does it really mean that another lzo algo has been used to
decompress the data, and this is then never detected by the "unsafe"
lzo1x_decompress_asm used in the C-code I have found because it does
not include error checking and thus, potentially makes some small
errors in its decompression, which has just never been realized?

I also observe that own compressed bytestrings and the ones in the
data file end with the same sequence of bytes
'...\x11\x00\x00', so I think I can rule out possible string
termination errors as the root cause of the problem.

I should mention that i have discussed my problem elsewhere also, but
i fell that I am now facing a problem which is beyond the scope of the
original groups I posted in (pytables-users and ctypes-users):

http://sourceforge.net/mailarchive/message.php?msg_name=AANLkTim6jGiCcbLEFbh4ybH1X5b0HXPXx7XAcuA0Jc28%40mail.gmail.com
http://sourceforge.net/mailarchive/message.php?msg_name=62eeb2c8e9f674ba5baf985c8c91ae89%40mail.wsinnovations.com

Kim

[Slaunger]

On 10 Sep., 08:40, Slaunger <slaun...@gmail.com> wrote:
> Hi list.
>
> I am trying to write a parser in Python 2.5.4 for a proprietary data
> file format, which consists of fixed length C-struct like data headers
> and variable length LZO compressed data payloads (the compressed data
> length is in the header and known). The decompress function in my
> lzo.pyd module raises an
>
> lzo.error: Header error - invalid compressed data
>
>  whenever I try to LZO decompress any of these bytestrings. I would
> like to know if others are capable of LZO decompressing an example
> bytestring from a data file or if the bytestrings are truly corrupted.
>
> Here is an example an LZO compressed bytestring consisting of 707
> bytes, which raises this error:
>
> '''
> \x02\x00\x00\x00\x00\x00 \x03\x00\x00\x04?\x00\x00?CB< \x03\xa8\x00
> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc3\x8d
> \x00D
> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc3T?
> \tP? \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xee
> \xfc? \t\xa4@

> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00­\x00\x00\x00\x00\x00\x0b
> \xa4\x00\x18\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x01\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00­\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x00\x00\x00\x00\x00\x00\x00\x00\x00#X
> \x7f
> \x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00­\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00­\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xb6r?

> http://sourceforge.net/mailarchive/message.php?msg_name=AANLkTim6jGiC...http://sourceforge.net/mailarchive/message.php?msg_name=62eeb2c8e9f67...
>
> Kim

Rereading my post, I realize that the example bytes string is not very
easy to work with in the way I have done. Here it is in hex string
format. Hopefully more digestable....

02 00 00 00 00 00 20 03 00 00 04 3F 00 00 3F 43 42 3C 20 03 A8 00 20
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 C3 8D 00 44 20 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 C3 54 3F 20 09 50
3F 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EE FC 3F 20 09 A4
40 20 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 0B A4 00 18 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 01 00 00
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 58 7F 10 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B6 72
3F 44 41 18 00 00 00 00 00
1B 84 80 03 3C 46 4D 4F 4E 46 20 00 00 00 00 00 03 90 14 20 00 00 00
00 00 9C 78 14 01 40 48 4C
48 20 00 00 00 00 00 02 00 40 06 40 51 5C 63 66 64 5D 51 3F 20 00 00
00 00 00 9C 88 2B 20 00 00
00 00 00 01 DC 16 02 41 48 4C 4A 43 20 00 00 00 00 00 01 84 14 06 49
5B 68 6F 71 6F 69 5C 4A 20
00 00 00 00 00 01 94 14 20 00 00 00 00 00 9C 70 14 20 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 EE FF 3F 00 3E 41 20 00 00 00 00 00 03 60 AB 06 4A 5D 6A 71 73 71
6B 5E 4C 20 00 00 00 00 00
9C 88 6B 20 00 00 00 00 00 02 DC 16 20 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 EE FC 3F 20
00 00 00 00 00 02 74 54 08 00 00 00 45 58 64 6C 6E 6C 65 59 10 00 00
00 00 00 00 00 00 00 00 D9
08 80 20 00 00 00 00 00 05 00 40 03 4C 58 5F 61 5F 58 20 00 00 00 00
00 00 00 00 00 00 9E F8 BF
11 00 00

Is this a valid lzo1x compressed array of bytes?

Kim

[Slaunger]

On 10 Sep., 11:17, Slaunger <slaun...@gmail.com> wrote:
> On 10 Sep., 08:40, Slaunger <slaun...@gmail.com> wrote:
>
>
>
>
>
> > Hi list.
>
> > I am trying to write a parser in Python 2.5.4 for a proprietary data
> > file format, which consists of fixed length C-struct like data headers
> > and variable length LZO compressed data payloads (the compressed data
> > length is in the header and known). The decompress function in my
> > lzo.pyd module raises an
>
> > lzo.error: Header error - invalid compressed data
>
> >  whenever I try to LZO decompress any of these bytestrings. I would
> > like to know if others are capable of LZO decompressing an example
> > bytestring from a data file or if the bytestrings are truly corrupted.
>
> > Here is an example an LZO compressed bytestring consisting of 707
> > bytes, which raises this error:
>
> > '''
> > \x02\x00\x00\x00\x00\x00 \x03\x00\x00\x04?\x00\x00?CB< \x03\xa8\x00
> > \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc3\x8d
> > \x00D
> > \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc3T?
> > \tP? \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xee
> > \xfc? \t\xa4@

> > \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­­0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00­\x00\x00\x00\x00\x00\x0b
> > \xa4\x00\x18\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­­0\x01\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00­\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x0­0\x00\x00\x00\x00\x00\x00\x00\x00\x00#X
> > \x7f
> > \x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­­0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00­\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x0­0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00\x­00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0­0\x00\­x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\­x00\x00­\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xb6r?

> >http://sourceforge.net/mailarchive/message.php?msg_name=AANLkTim6jGiC......

> Kim- Skjul tekst i anførselstegn -
>
> - Vis tekst i anførselstegn -

As additional information, I managed to track down the C code, which
compress the data. This C code is using the

lzo1x_1_compress

library function,

I,e, the 1X LZO algorithm at compression level 1 (which is optimized
for speed).

Does this algo normally spit out x02 as its first byte in a compressed
array of bytes?

The lzo1x_decompress... algos should all be able to autodetect the
compression level, thus it is unexpected (for me), that
lzo1x_decompress_safe reports a header error on data created with
lzo1x_1_compress??

[Slaunger]

Although I am just having a dialogue with myself here, I finally
figured out what the problem is:-) (I cannot solve my problem, but now
I at least know what it is)

The lzo python bindings does not return the exact same array of bytes
as the C-library functions. They add a header, where the first byte is
0xF= for LZO-1X compr lvl 1, and then an uint 32 representing the
number of bytes in the *uncompressed* byet array. Apparently, this
convenience information is used in the Python binding uncompress
function, to allocate the right sized buffer for the output prior to
calling the lzo library uncompress function. Really crap binding code
if you ask me as it measn that I have to know *in advance* how many
bytes a compressed array of bytes will unpack into *prior* to calling
lzo.uncompress. And if it is compressed data from another data source,
it is really not possible to know that final data size beforehand,
which is...crap.

[Mukesh Jat]

Just use lzo.decompress(data,False,out_len,alogrithm="XYZ")

[apurv khandelwal]

lzo.decompress(data,False,out_len,alogrithm="XYZ")

this does not work. Shows the error: decompress() takes no keyword arguments

Also, the function only takes 3 arguments. Running lzo.decompress(c, False, 512, "LZO1Z") gives the error: function takes at most 3 arguments (4 given)

[Keith Thompson]

In what language?

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */