Infinite compression does not exist, sorry. What you've described in terms of marking blocks as non-compressible is already done by some compression techniques (including ZFS filesystem compression). At some point, the compression gains in aggregate are overtaken by the compressor's metadata (including info on non-compressible blocks).

Actually, I should correct that a little bit. Infinite compression IS possible, but only as long as you don't ever care to decompress your file. In fact, by doing so, you could just compress any arbitrary data stream down to 1 bit in length. Assume, for example, that you have a file 3 bits long and your algorithm reduces it to 2 bits:

8 input possibilities:

000 001 010 011 100 101 110 111

4 output possibilities:

00 01 10 11

How does the decompressor know which set of inputs it should use when looking at the outputs?

The same applies as you keep adding more length. Infinite lossless compression is as impossible today as it always was.

I think the trick to infinitely compressing data lies within an iterative self-similarity algorithm using the imaginary number i. If in each iteration data can be made into a somewhat smaller size and the decompression method is infused with that output as a mesh between what is compressed and the key to decompression, the problem would be resolved. Some might ask, what comes first, the chicken or the egg. After all, how can you have the data output which also contains the decompression method if you haven't even compressed the data yet to determine the method used to compress it. That is where the wonderful world of self-similar fractal geometry comes into the fold. Methods for creating infinite data sets with self-similar fractional dimensions from a very small iterative equation are already being utilized and have been for decades now. The smaller features are an exact copy, and many times a slightly skewed version, of the larger features which contain those smaller features. There should be a way to generate a mathematical code that would do the same thing with 1's and 0's where the data itself would provide the encoding method and the total output data, smaller than the original, would contain both the original data without loss as well as the unique decompression method needed for that particular compressed data set. Each set of data would be uniquely compressed in a way that is different from every other data set and based on the data itself providing the unique encoding for itself. It may require assistance of quantum computing though so it can analyze every possible encryption combination simultaneously with real-time feedback to the original data set as well as the output data. This process would then be iterated as many times as is needed to reduce the data to the size desired balanced with the computing time required to do so. The number of times iterated would then become the only meta-data that is required to be attached to the final compressed data/decompression method. It would undoubtedly be several decades before we would be able to perform this kind of thing. It would also require another Benoit Mandelbrot type genius of compression, or quantum compression, algorithms as well. Anything can be done with data since it is infinitely malleable. The problem with traditional compression techniques is just that, they are traditional.

While it may seem absurd, I have already found 2 rules to use during decompression using truth tables to regenerate temporary data used during compression for non-quantum computing. I need at least 1 more, possibly 2 to complete the process used for encoding. Looking at larger strings now but running through and testing every possible combination to develop rules is becoming exponentially time consuming. I have 2 even rules and now am looking for an odd one to fill in the gaps for the data retrieval. If an odd numbered rule exists, the it will be possible to convert the excel sheet I have into coding to use for iterative compression and decompression.

Here's a sample of what the self-similarity pattern I'm using is:

101100011001101010

11010010101011111

0111011111110000

100110000001000

10101000001100

1111100001010

000010001111

00011001000

etc...

The absolute value difference of parallel bits is used to generate strings of decreasing sizes of temporary data. A fixed number of levels down (needs to remain static for reference on the way back up) is chosen as the output of the first iteration along with known bits of temporary data at fixed locations. Both the output plus the temporary data must stay at least 1 bit smaller than the original data for which I'm only up to 12 bits at the moment but just doubled that size to look for odd-numbered truth table rules to fill in the gaps. An example of 4 digits apart would be:

01011

1110

001

01

1

Given any 2 of the 3 points on the triangle, the 3rd is ALWAYS the absolute value difference of the other 2 points for any 4-bit input combination, no matter what values of zeroes and ones are in between. The output compressed value is used to generate further levels down as reference points for retrieving the temporary data used in compression during the decompression cycle to fill in the gaps on the way back up the hierarchy. The original coding rule is a 1-digit rule. There is a 2-digit rule and a 4-digit rule and the above is an example of the 4-digit one. Now I'm looking into odd-numbered rules

Those values are supposed to be stacked but the formatting on this forum isn't working.

All is working :-) Just need to learn things. Same as with compression.

Well, where is one good button above post area that is called "Format Help"

If you click the link that he suggested, it really is very helpful.

Neokoo that does work but it is more like a rainbow table. That would be good to transfer large amounts of data to and from locations but only if those locations have local access to the libraries which means you have to have a lot of storage locally to store the libraries to reassemble what is being transmitted. I'm trying to get around the local storage problem while still being able to transmit a large amount of data in a small package. With that in mind though, data storage and transmit speeds seem to be accelerating faster than processing speeds currently and the method I stated above requires large amounts of processing power so the library method you described might even be better than infinite lossless compression algorithms at some point in the near future. Infinite lossless compression would be best for very long distance data packets, like satellite telemetry. You gather your data, compress it down, then send the very small amount you now have multiple times to ensure the receiving end, light minutes to light days away, has multiple chances of receiving it all correctly.