On Compressing And Indexing Repetitive Sequences: Fill & Download for Free

No. Zip format definitely does not reduce quality.There are two types of compression - lossless compression and lossy compression. And, the Zip format is of lossless type.In layman terms, a Zipping operation creates an index of long binary and character sequences in the files and assigns special symbol sequences to them. Thereby it reduces the literal repetition in characters and bytes and replaces them with shorter symbols. Simultaneously, it makes a careful note of where and which sequence has to be replaced while “unzipping” the file back to the original.Examples of lossy compression are - JPEG, PNG, MPEG, MP3, and such audio or video formats. They work on the principle that humans cannot perceive subtle changes in shades and colours or transitions between frames in a video. So, they sacrifice information which is considered as “unimportant” because most people won't notice the difference.Caveat:However, a zip file can increase the chances of loss of data:This is because a few bits of errors in a zip file can prevent the entire Zipped folder from being unzipped.What would have normally caused only a single small file to get corrupted, can now corrupt the whole bundle of files which is there in the zip file.This is why many Zip programs give the option to ‘Verify’ the zip to make sure that that zip doesn’t have some bit errors. Because people often Zip a folder for backup and then delete the original folder.If you send a zip file to someone, again there are chances of Zip getting corrupted during transmission. The receiver should unzip the file/verify using checksum before the sender deletes the original verified zip file.

Yes, there's this theorem which backs up your intuition - that whatever compression method you use, there have to be many almost incompressible strings - that is to say - that the "compressed" versions are nearly as large as or larger than the data they compress. And indeed if you use random data - then most strings will be incompressible in this sense.It's quite a simple proof also.Suppose for instance that you want to compress random data of 100 bits. Then count all the possible uncompressed versions of the data you could have, it's 2^100.Now count all the possible compressed versions, must be the same number, 2^100 of them assuming that you can reconstruct the data unambiguously from its uncompressed version.So - now suppose that you want to compress it by a factor of 2, to 50 bits. That means you have only 2^50 compressed versions available and nearly all the data can't be compressed that far.Even compressing it so it is shorter by just 2 bits cuts it down to a quarter of the available descriptions - so we see that only a quarter of the possible files can be compressed by as much as 2 bits.And that's a general mathematical truth about all possible methods of data compression.See Kolmogorov complexitySo our compression methods only work because of the repetitive or predictable nature of the data we typically compress.E.g. if typical files were filled with truly random data then zip compression or any other compression method would not work at all on most files. But because the files that we want to compress are not random, then compression is possible.Might be that PI compression for some reason works well for some types of file we are interested in. But it could also go the other way and the meta data be longer than the file compressed.In case of PI - then you need to have some way to specify the position in the decimal expansion of PI - and that then will take up more or less bytes depending how far you go to find the string - so we can deduce - that most of the hexadecimal sequences will be so far along the expansion of pi that the number that expresses their position takes up at least as much storage as the sequence itself.It is a neat idea. He is using a result about PI - that though in most cases it is really hard to find digits of PI - in special case where you express it in hexadecimal - there's a clever formula that lets you calculate the nth digit of PI without first calculating any of the earlier digits. So in hexadecimal - but not to any other base - we know digits of PI very far along its decimal expansion.For details see Bailey–Borwein–Plouffe formulaSo - though compressing data is hard - need to spend ages going through the PI sequence to find the sequence you need - uncompressing it would be far faster, when you know where to look then you can generate the hexadecimal sequence from then onwards.But - it's not going to work as a method of compression for most sequences. It would depend on whether there is any result of PI that would favour any particular interesting sequences we are likely to want to compress.I've found a page you can use to find the index for a short (say 6 digit) sequence in the first 200 million digits of pi. It's in decimal, not hexadecimal, still gives an idea.Sometimes the position is a larger number, sometimes is a smaller number; The Pi-Search Page

The compression remove redundancy from the source, so you essentially gather all the repeated words (phrases or byte sequences), into a dictionary then just list the indexes to each word. Now you have a file with no repetitions so there is nothing to compress.In practice I have found that the second level zip is a bit smaller because the first zip has the directory listing in plain text and if this can compress to save more than a zip header plus the new directory (only one file: first.zip) then you save a few bytes. Each subsequent zip adds a new header plus a new directory (second.zip) so increases by that much each time.For decompression there is a nice trick. You can have a special zip file that appears to contain a single x.zip which when extracted also contains x.zip. This is done by realising unzip is a kind of interpreter and the compressed file is a kind of bytecode so it can be manipulated to do this effect.