3 ms·
Now they just need to port something like oneKpaq to 16 bit or maybe something from the extremely tiny decompressor thread [1], just to test compression level t
by molticrystal 3y ago
Now they just need to port something like oneKpaq to 16 bit or maybe something from the extremely tiny decompressor thread [1], just to test compression level to get an idea kpaq on its quickest setting(taking minutes instead of what could be days on its highest) reduced SectorC to 82.81% of its size, of course adding the 128 bit stub knocked it to 677 bytes. It would be interesting to try it on the slowest takes day to bruteforce setting, but I'm not going to attempt that.
Some of the compressors in that forum thread since they are 32 bytes and such, might find it easier to get net gains.
[0] https://github.com/temisu/oneKpaq https://github.com/temisu/oneKpaq
[1] https://encode.su/threads/3387-(Extremely)-tiny-decompressors https://encode.su/threads/3387-(Extremely)-tiny-decompressor...
- userbinator 3y agoLZ decompressors are tiny, as your second link discusses, but it is unlikely that they'll find much redundancy that could easily be removed from the uncompressed program itself, thus removing the need to use them.
- benj111 3y agoI once tried making a 1kb binary to see what I could fit in, once you've got to the point of considering compression there isn't much ordered data left to compress. I worked it out to be a ~10 byte saving.