Quote:Original post by Fred304 I can compress ANY file to the original size minus one byte. Simply cut out the last byte and encode it into the filename :)
Wouldn't work. No operating system allows all 256 values of a byte as valid characters for filenames.
That's why I wrote encode instead of append. I could use two characters to represent one byte.
Quote:Original post by Fred304 I can compress ANY file to the original size minus one byte. Simply cut out the last byte and encode it into the filename :)
There's a 256-byte demo (whose name I don't remember) that uses this trick to decode a 320x200 image from the filenames of thousands of 0-sized files.
Quote:Original post by Fred304 I can compress ANY file to the original size minus one byte. Simply cut out the last byte and encode it into the filename :)
There's a 256-byte demo (whose name I don't remember) that uses this trick to decode a 320x200 image from the filenames of thousands of 0-sized files.
Isn't this cheating though? I mean, the filenames have to be stored on the disk someplace...
and like all you people had already guessed, I overlooked certain constraints that will bring my claim down to almost zero: all that is left is just another compression algorithm. Turns out I overlooked some possibilities, and once again I am bound to the possibility of storing a max of 2^N different patterns in N bits. The algorithm can still compress a lot of files to a reasonable extend, but in no way as much as I was claiming in the original post (which, I still like to say, wasn't really compression, but since it's also proven to be fiction there's no use for THAT discussion :))
