# GZIPDecompressorInputStream from BinaryBuilder **URL:** \ **Category:** General JUCE discussion\ **Created:** [June 16, 2014, 11:16am UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000 "2014-06-16T11:16:16Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![raketa](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/raketa/32/1725_2.png) [@raketa](https://forum.juce.com/u/raketa)\ **Post date:** [June 16, 2014, 11:16am UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/1 "2014-06-16T11:16:16Z")
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 ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [June 16, 2014, 11:21am UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/2 "2014-06-16T11:21:23Z")
You didn't say where your data came from, but it clearly isn't the correct format. ---
**Author:** ![raketa](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/raketa/32/1725_2.png) [@raketa](https://forum.juce.com/u/raketa)\ **Post date:** [June 16, 2014, 11:30am UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/3 "2014-06-16T11:30:47Z")
Thanks, Jules, for the fast response! Its a gzip-ped xml file. MacOSX: ``` gzip -ck9 test.xml >test ``` Cheers, raketa ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [June 16, 2014, 11:39am UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/4 "2014-06-16T11:39:52Z")
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. ---
**Author:** ![raketa](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/raketa/32/1725_2.png) [@raketa](https://forum.juce.com/u/raketa)\ **Post date:** [June 16, 2014, 2:19pm UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/5 "2014-06-16T14:19:58Z")
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? ---
**Author:** ![raketa](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/raketa/32/1725_2.png) [@raketa](https://forum.juce.com/u/raketa)\ **Post date:** [June 16, 2014, 3:04pm UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/6 "2014-06-16T15:04:00Z")
removed ---
**Author:** ![phanlord](https://avatars.discourse-cdn.com/v4/letter/p/cab0a1/32.png) [@phanlord](https://forum.juce.com/u/phanlord)\ **Post date:** [June 19, 2014, 8:25pm UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/7 "2014-06-19T20:25:59Z")
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) ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [June 21, 2014, 10:53am UTC](https://forum.juce.com/t/gzipdecompressorinputstream-from-binarybuilder/13000/8 "2014-06-21T10:53:13Z")
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..