Precomp 0.4

[nanoflooder]

Gzip what is gzip do u have it download link...

That was a joke mate I meant "yes, you can use any archiver you like". GZip is an old low-performing archiver.

[SolVanDyck]

what i meant that i have first i have to put my files in .zip format which software to use then i recompress it then i use freearc instead of 7z that's all im saying but i need a favor for freearc what is the commad for maximum compression...

[nanoflooder]

Feel free to use freearc Or any other archiver. Make sure only it's better than zip, otherwise the whole point of recompression is getting lost.

[SolVanDyck]

how to use zlib because its only working with this format nothing
else how to use zlib please help...

[Bulat Ziganshin]

sorry, "alpha testers"

[SolVanDyck]

what?

[SolVanDyck]

will somebody just please tell me how ta make zip file from zlib just teach how to use it that is all and i will appreciate the help thanks in advance

[nanoflooder]

What do you mean?
zlib is a library to compress files using the deflate algorythm. There is an archiver that uses the zlib compression, it's called gzip. It's widely used in Linux/BSD, you could probably see the .tar.gz archives somewhere.
zip also uses the deflate algorythm, but zip and gzip are very different types of archives.
precomp can recompress both zip and gzip. As well as many other things.

[SolVanDyck]

where i can download gzip

[SolVanDyck]

just one question how to use gzip in others lie 7zip there is a windows u can
add files to archibe how do u do that with this one.

[m^2]

where i can download gzip

yahoo.com
msn.com
ask.com
google.com
...

[nanoflooder]

gzip is a compressor, it's not an archiver itself. Thus you can only compress one "thing" using it (file, for example). If you want to do that via 7-Zip you have to make a tarball (.tar) first and then select that .tar file and compress it using gzip.

[SolVanDyck]

Thank you nanoflooder it worked perfectly now the question can i use zlib other than Gzip works more efficient.

[nanoflooder]

Uhm. GZip is a compressor that uses the zlib compression. Think of it as a zlib wrapper. Many applications use zlib not as gzip, but as a library to compress something inside their own files. Like, in an abstract program, instead of standard routine
1) read data from file
2) do something
3) write data to file
They do
1) read data from file
2) decompress it with zlib
3) do something with decompressed data
4) compress it with zlib
5) write data to file
So they can reduce the size of their files. That's exactly what ABBYY has done with their applications. As well as many other well-known manufacturers whose programs work with big amounts of data.

[SolVanDyck]

from your advise what to use to compress the Zlib u know when u said i have
a file.zip what to use for the zip i know about precomp got it working just want to know whats the one u use?

[nanoflooder]

I don't really get what you're saying here.

If you want to compress files using the "power" of zlib then use GZip.

[SolVanDyck]

is there a way to use Gzip other than Drag and drop on the gzip.exe application

[nanoflooder]

Yes, for example using 7-Zip's implementation. Right click a file, select 7-Zip -> Add to archive -> Archive type "GZip"

[SolVanDyck]

but if i want to add folder it ony give tar 7z...is there another way

[nanoflooder]

As I was saying, GZip is a compressor, thus it can only compress one file per time. If you want to compress, say, a folder, you need first to make a .tar out of it and then compress it to folder.tar.gz.

[SolVanDyck]

Finally got it working thanks allot man promise this is my final post

[nanoflooder]

lol no problems mate

[Skymmer]

I've recently been involved into making backups of some of my games with gorgeous pair of PreComp + FreeARC and seems found some issue with zLIB detection in PreComp.
I was doing backup of Call of Duty: Modern Warfare game and there are a lot of files with *.ff extension (maps). Precomp did a great job in slow mode on all of files except one giving the message: None of the given compression and memory levels could be used and so on. I've uploaded the file here
Anyway, thanks for PreComp! It realy rockz

[schnaader]

I've recently been involved into making backups of some of my games with gorgeous pair of PreComp + FreeARC and seems found some issue with zLIB detection in PreComp.
I was doing backup of Call of Duty: Modern Warfare game and there are a lot of files with *.ff extension (maps). Precomp did a great job in slow mode on all of files except one giving the message: None of the given compression and memory levels could be used and so on. I've uploaded the file here

Seems that there is some error in the data. zLib routines return Z_DATA_ERROR, which means that the input data is corrupted (perhaps the checksum at the end of the stream is wrong, or something similar). Using my own zLib routines, I am able to decompress 178 blocks, about 3 MB of the input data give about 4 MB of output data. After this, the compression mode changes from huffman to uncompressed and stops after 3 more blocks, so more than 30 MB of the file remain (which seems to be wrong as I think the file is compressed as one).

However, the output data seems to be correct, there's some text data (texture IDs or something like this) at the beginning, followed by some container-like structure (.wav filenames and content). Using CCM, I can compress this output data from 4 MB to 2,2 MB, so it's about 30% better than the original compression. Didn't bother to try PAQ on it, but if it really contains WAV audio data, this should get better ratios.

I'll do some additional experiments regarding the zLib checksum, perhaps it's only the checksum that is wrong and I can somehow ignore this. Even if this is not the case, perhaps I can get zLib to return the decompressed part anyway and try to recompress it.

[Bulat Ziganshin]

is this a proper place for bug reports?

http://dreamlair.net/download/Error.rar contains 3 files and my user said that their combination breaks precomp. for me, even usmc_force_lenses_sp_col.iwi alone makes 0.4 crashdump

[schnaader]

is this a proper place for bug reports?

Either post here or send it by e-mail, but I think I'll create a Bugzilla account or something similar in the beta phase.

http://dreamlair.net/download/Error.rar contains 3 files and my user said that their combination breaks precomp. for me, even usmc_force_lenses_sp_col.iwi alone makes 0.4 crashdump

Hmm... I tried all the permutations, only those where the nml file is followed by the small lod file crashed, all others worked. What's weird is that combining only those both files without the third file doesn't crash for me.
I could also not reproduce a crash when only processing one file or without slow mode.

Using -t-j helps, so this seems to be another of those weird packJPG bugs that somehow corrupt memory and make Precomp crash later on. I'll talk about this with Matthias Stirner and if there is no new packJPG version available that's more stable, I'll most probably disable JPG recompression by default in the next version.

[Skymmer]

http://dreamlair.net/download/Error.rar contains 3 files and my user said that their combination breaks precomp. for me, even usmc_force_lenses_sp_col.iwi alone makes 0.4 crashdump

Surely, the world is a small place. Another user reports issue with PreComp based on data from Call of Duty: Modern Warfare game. These 3 iwi files are from iw_03.iwd data file.
iwd stands for Infinity Ward Data. Infinity Ward is the game developer studio name. Such files are actually ZIP files renamed to iwd extension.
iwi stands for Infinity Ward Image and I suppose used as textures format.
Well, from some point of view bug report is a bug report. From another one, such iwi files are not compressed. Its clearly visible in HEX and they are compressible. So PreComp-ing them is just waste of time. Furthemore since that user was able to find out this bug then I assume that he unpacked iwd containers. Yes, engine architecture allows the usage of unpacked materials but it's no good cause its a waste of space. First of all because data is not ZIPPed anymore. Second, we must take into account the fact that there are a lot of small files which anyway will take at least one cluster on HDD. From the other point of view "unpacked scheme" allows to use some tricks which can lead to improved compression but its not the theme of discussion for this topic
So If that user want to achieve good compression on CoD:MW and avoid the PreComp crash on given files then I can suggest to convert iwd files to non-compressed (store method) variants.

Using -t-j helps, so this seems to be another of those weird packJPG bugs that somehow corrupt memory and make Precomp crash later on. I'll talk about this with Matthias Stirner and if there is no new packJPG version available that's more stable, I'll most probably disable JPG recompression by default in the next version.

I had some similar issues with packJPG but anfortunately have no actual examples for it. I can only suggest to make PreComp to use (well, not sure if its a right term) "delay import" for packjpg_dll.dll so it will be loaded only when JPEG processing is used.

[Black_Fox]

Delay importing wouldn't help, as you would still use the flawed library.

[Bulat Ziganshin]

one more report: http://dreamlair.net/download/Error2.rar

[Bulat Ziganshin]

I could also not reproduce a crash when only processing one file or without slow mode.

for me it stops on one file in normal mode. but buggy programs may crash in different ways depending on environament