GZIPDecompressorInputStream from BinaryBuilder

General JUCE discussion
1

Hi,

I thought its obvious but I probably miss something here:

to uncompress from my BinaryBuilder created binary data I do the following:

juce::MemoryInputStream input(resource::test,resource::testSize,false);

juce::GZIPDecompressorInputStream decomp(input);

and then try to read it with

size=decomp.read(data,max_size);

but it always returns 0. When stepping into this its due GZIPDecompressorInputStream::helper->data (in helper->doNextBlock) are zero. What am I doing wrong here?

 

Thanks,

raketa

2

You didn't say where your data came from, but it clearly isn't the correct format.

3

Thanks, Jules,

for the fast response!

Its a gzip-ped xml file.

MacOSX:

gzip -ck9 test.xml >test

Cheers,

raketa

4

Ok, but I've no idea exactly what format that tool emits, or whether it's compatible with the zlib code that the juce class uses internally. Maybe it adds extra header bytes or something.. it certainly sounds like the format's not compatible.

5

Thanks again,

then I guess the question is: What would be the right tool to compress the data?

cat test.xml | python -c 'import sys,zlib; sys.stdout.write(zlib.compress(sys.stdin.read()))' > test

does it, but what a hassle! 

Doesn't seem there is any (pre-installed) command line tool capable of creating a plain zlib compressed file. Maybe a good option for the binary builder to create compressed binary data?

6

removed

7

it seems like GZIP is the wrong name for this class as it doesnt support GZIP format

for decoding it doesnt use automatic header recognition (juce uses windowsBits of 15)

windowBits can also be greater than 15 for optional gzip decoding. Add 32 to windowBits to enable zlib and gzip decoding with automatic header detection, or add 16 to decode only the gzip format (the zlib format will return a Z_DATA_ERROR). If a gzip stream is being decoded, strm->adler is a crc32 instead of an adler32.

 

 so maybe line 103 of juce_GZIPDecompressorInputStream.cpp should be

        streamIsValid = (inflateInit2 (&stream, dontWrap ? -MAX_WBITS : MAX_WBITS+32) == Z_OK);

to allow it to automatically recognize zlib vs gzip data 

dontWrap assumes no header data (one would think that an option would be usefull to allow choice of zlib/gzip  compresion/decompression)

8

Ah, that's interesting - I didn't know it supported that option (and actually, when I first added zlib support to juce many years ago, it probably didn't!)

That "dontWrap" thing always annoyed me - it's something I copied from zlib and never found a good piece of documentation explaining what it did or why it had that name.

So I guess that if it now supports auto-detection, I could safely remove the option altogether and just always pass 32..