tane Posted October 14, 2020 Share Posted October 14, 2020 On 10/11/2020 at 1:23 PM, CharlieChaplin said: Superpacker 6.8 is out now - maybe the bug is fixed there ?!? An answer from the developer of Exomizer: Quote This is caused by a limitation in exomizer. The memory area of the compressed data can't completely overlap the memory area that you decompress into. If the areas were allowed to overlap then the decompressed data would overwrite the not yet decompressed data and cause the decompression code to crash. For the decompression to be guaranteed to work the areas need to be arranged so that the write pointer never overtakes the read pointer. If we are decompressing backwards in memory then, for most compressed data, it means that the read area needs to end two bytes before the write area due to the way the literal/sequence encoding works. The documentation talks about this a bit in the section about the mem subcommand -l option in the exo20info.txt file in the exomizer dist. I hope that you find this answer helpful. It should be possible to handle this by saving/restoring before/after or perhaps reordering the decompressed segments so that data at lower memory addresses are decompressed after higher areas. 20 hours ago, Wilheim said: Do I have to remove something to make the v6.8 work properly? The configuration is saved in: C:\Users\User\Application Data\SuperPacker\sp.ini Also clean this: C:\Users\User\Application Data\SuperPacker The Super Packer doesn't auto-clean the cache and heavily reduces the hard drive space. exo20info.txt 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.