There is a minimum size required size for the file (cant be compressed beyond a few bytes - even if repeatedly applied) and the argument is only valid when we assume the files can be compressed to zero bytes.
no claim is made to the effect saying "Can be compressed indefinitely"
As I have told, the efficiency of it being able to compress over and over and over again may have chance for data corruption unless better checks and methods are added. (which will again increase the minimum required file size. but you can still compress it)
Just for simplicity: Let's assume that I have a file of 1073741825 bytes = 1GiB+1B. And I want to put it inside my exactly 1073741824 bytes = 1GiB pendrive. (Just assume that the OS filesystem doesn't waste any space.)
Are you sure that this algorithm will compress my 1073741825 bytes file to a 1073741824 bytes or less file?
I've come up with a better compression scheme than yours. My scheme is exactly the same as yours, but you replace the first three bytes with one byte instead of two. Doesn't matter what byte you replace them with, because - just like your scheme - you can't get the original data back by decompressing it anyway.
10 comments
[ 7.3 ms ] story [ 107 ms ] threadno claim is made to the effect saying "Can be compressed indefinitely"
As I have told, the efficiency of it being able to compress over and over and over again may have chance for data corruption unless better checks and methods are added. (which will again increase the minimum required file size. but you can still compress it)
Are you sure that this algorithm will compress my 1073741825 bytes file to a 1073741824 bytes or less file?
Now I am making few assumptions for a practical implementation of the technique.
PAT() = Units place of sum of all digits. (no claims made,just for an example)
Now I can replace the three bytes with the following values 033 and 036
I have also specially stated the challenges of retrieving this information as as of not there are no built in integrity checks.
There, saved you a click.