Christian Schneider

For ASCII85Decode, there's [code in paq8pxd](https://github.com/kaitz/paq8pxd/blob/40ccf069fed65d277dba7e96325f7d006464ca20/paq8pxd.cpp#L10275) that can be used as a reference. It might be possible to modify/extend some of the Base64 routines in Precomp for it.

Very interesting, seems to be a gzip and preflate related bug. Precomp 0.4.6 (the last version not using preflate) showed the correct compressed and decompressed size (17,660,983 -> 37,623,808), but...

Both points are valid. There should be: - A checksum of the original file to check if recompression was successful - (At least in -cn mode) A checksum of the...

The crash can be reproduced, I've managed to isolate the MP3 stream that causes it. So this most likely is a packmp3 issue, I will investigate this further. [invalid_mp3.zip](https://github.com/schnaader/precomp-cpp/files/6604145/invalid_mp3.zip)

There already was the possibility to build a DLL that is broken at the moment. This has to be fixed and the class inside the DLL has to be adjusted...

In the acacia file, the Base64 parts have the following format: ``` ... ... ... ... ... ``` Between the mentioned inner XML tags, there is data encoded using Base64....

Useful tool to analyse SWF files for this: [Adobe SWF Investigator](http://labs.adobe.com/downloads/swfinvestigator.html)

This is similar to the old zlib behaviour (e.g. #21 ), recompression isn't identical. A more advanced bZip2 recompression algorithm (similar to what preflate does with zlib) would be needed...

Discarding insufficient partial matches like described above now. New output of `-v`: ``` (0.00%) Possible bZip2-Stream found at position 0, compression level = 9 Compressed size: 1390169 Can be decompressed...

The issue will stay open as a known issue, I changed the title to make it more clear what the issue is about.