Conversation

Notices

1. Embed this notice
   翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 29-May-2026 02:39:32 JST 翠星石

   in reply to

   • Zergling_man
   @Zergling_man You're forgetting the pigeonhole principle - if the hash is shorter than the source, then there is on average source bytes/hash bytes, hash collisions.
   
   So for 32 bytes of data and 8 bytes of hash, that would be 32/8 - so on average 4 different 32 byte sequences that result in the same hash.
   
   Encoding any extra identifying information to allow detecting the right sequence will erase any compression gains.
   
   Adding an extra hash will only allow detecting that 1 to n of all the 32 byte blocks is incorrect.
   
   The only way you'll get reliable decompression that way is to exceed the length of the original file with a longer hash.
   
   If you want a consistent 75% compression ration, the only way to achieve that is lossy compression that throws away 75% of the data.
   • Embed this notice
     Zergling_man (zergling_man@sacred.harpy.faith)'s status on Friday, 29-May-2026 02:39:34 JST Zergling_man
     Ok dumb compression concept: Hash-breaking. Replace every 32 bytes with 8 bytes of hash, 'decompressing' is simply brute-forcing a match. Consistent 75% compression ratio but really slow decompression, and you'd need to be able to tell the decompressor to retry a failed attempt, maybe have it store the hash of each file so it can at least guess where it went wrong (other than "everywhere"), though that can easily tank the ratio.