ZPAQ Compression issue when lrizip-next block size > zpaq block size
pete4abw opened this issue · comments
lrzip which uses ZPAQ 5 SDK can send large blocks to zpaq compressor and all decompresses fine. lrzip-next uses ZPAQ 7.15 SDK. This SDK introduced the StringBuffer class which accepts only block size chunks to compress. While it can be done iterativley, sending large blocks in block size chunks to the StringBuffer , for an unknown reason, something goes wrong. The decompressor can decompress the data fine, but there is corruption and the lrzip-next checksum fails. Any help in diagnosing this is appreciated. Thank you.
PS: Compression is much better when larger blocks are sent to zpaq. Right now, block sizes are limited to the zpaq block sizes, which for lower levels are smaller.
Item is resolved for testing in zpaq_bs_fix branch. See discussion.
Item is resolved for testing in zpaq_bs_fix branch. See discussion.
Changes promoted to whats-next branch.
Item is resolved for testing in zpaq_bs_fix branch. See discussion.
Changes promoted to whats-next branch.
Changes promoted to lzma-22.01 branch along with bzip3 updates.