Results 21 to 40 of 64
10-05-2013, 10:08 AM #21
To be completely honest, I'm saying this to illustrate what this would mean. You'd turn upside down a few big areas in computing. Or you made a mistake somewhere and it's not lossless. Which is where my money is, I'm sorry to say.
10-05-2013, 10:11 AM #22
You are correct Boris.
The compression was so simple, that I thought de-compression would be a breeeze, while it was, the de-compression revealed a fatal flaw, so lots of data was missing in the compressed version.
I really thought I was onto something :(
11-05-2013, 12:45 AM #23
11-05-2013, 09:11 AM #24
11-05-2013, 10:07 AM #25
lossless compression is a big business. FLAC is a fantastic example of this.
as for compression software I suggest iSkysoft Ultimate Convertor. works great for non professional compression.
11-05-2013, 10:14 AM #26
11-05-2013, 11:24 AM #27
A person with such a discovery would be in line for a Nobel Prize. And since a lot of really smart people have been trying to do what he claimed and failed, it seems reasonable to assume that it does not work until proven otherwise.
11-05-2013, 03:25 PM #28
16-05-2013, 11:35 PM #29
Practical lossless compression works by being tailored to compress the most common patterns in the stuff you typically feed the compression program. Zip, rar, Lagarith, FLAC and all the rest pay for this by ending up with files larger than the source for some types of data. They're still useful is because we only care about compressing specific types of data like conversations, music and film so the algorithms are optimized for that and the fact that they end up producing larger files when fed types of random noise isn't really a problem in practice.
So, if at any point in life someone believes themselves to have found a general lossless compression method: nope, they haven't. Nor will anyone else do so at any point ever. Sorry.
17-05-2013, 12:14 AM #30
17-05-2013, 08:33 AM #31
24-05-2013, 08:42 AM #32
- Join Date
- May 2013
You can't compress them anymore - mp3 is a heavily compressed file and it won't compress anymore. Same with wmv, aac, avi, m4p, mpeg, etc.
All a zip or rar utility will do is bundle them into one package, but you can't make the package any smaller.
24-05-2013, 10:19 AM #33
did everyone miss the post that the original poster made, that his code had a flaw?
24-05-2013, 12:39 PM #34
- Join Date
- May 2013
24-05-2013, 08:18 PM #35
The "natural" binary coding of those 4 symbols would be
Symbol Code a 0 b 10 c 110 d 111
The variable length coding makes the assumption that 'a' is more common than 'c' and 'd' together but for an uncommon message like "dc" the proposed variable length encoding is "111110" and larger than the natural encoding "1110". It's still a very useful approach since in a lot of real-world applications you can safely assume that certain symbols are far more common than others and tailor the coding accordingly. Such an algorithm will unavoidably fail to compress in cases where that assumption doesn't hold.
Symbol Code a 00 b 01 c 10 d 11
There is literally no such thing as a universal compression algorithm and it is literally impossible to make one. You cannot compress 1000 possible input messages to 500 possible output messages (i.e. a single bit reduction in message size) and expect to always reconstruct the original message from output -- at least one output will have more than one input that could cause it.
Last edited by Xerophyte; 24-05-2013 at 08:20 PM.
25-05-2013, 12:22 AM #36
- Join Date
- May 2013
I see your point now, and I must confess that I did misunderstand what you said. Specifically the part where it is impossible for an algorithm to encode ANY file to a smaller size. Thinking a little bit more on this, it is easy to imagine at least one case where this would be impossible; a data set that has no correlation at all between the bits - complete noise.
Although if the data is large enough, I would be surprised if an entropy-based encoding would not yield some results.
My meaning of general was thus rather general-purpose than every case.
Your second point still have me a bit confused, I am pretty confident that lossless encoding won't produce ambiguous results. Are you talking about a lossy compression, that always removes some data? In that case I didn't know that they had the property of not being able to guarantee unambiguous results, although it makes sense if you think about it.
25-05-2013, 01:21 AM #37
Lossless encodings, like the one from the wiki above, won't produce ambiguous results but they pay by producing an output that is larger than the input for certain inputs. E.g. inputting "dc" in the example. This is not a problem in practice -- assuming that whoever made the encoding knew what they were doing -- since the inputs that are enlarged by your lossless encoding are unlikely to the point of impossibility while the inputs that are significantly compressed are very common, but if you count them then there will be at least as many inputs that are enlarged by the lossless algorithm as there are inputs that are compressed.
I'm not saying that it's impossible to encode any file to a smaller size, obviously we can losslessly compress a lot of things. What is impossible is finding an algorithm that losslessly encodes all files to a smaller size. For every file you make smaller, there must be another file you make larger.
Also, yes, if you allow loss then you can guarantee that all inputs are compressed, but that's no fun... :)
E: Ah. I realize I may have misunderstood you initially. Variable length coding is certainly a lossless encoding technique but there are plenty of those. Gray code, bit parity transfer techniques, etc. What it is not is a general (lossless) compression technique -- those don't exist and cannot be constructed.
Last edited by Xerophyte; 25-05-2013 at 01:31 AM.
25-05-2013, 01:56 AM #38
The solution for the problem of "compressed" files being bigger than the input is having the format support the inclusion of the original uncompressed file.
For example, the compressed file has 1 bit that indicates if the file is compressed or not.
25-05-2013, 02:23 AM #39
But, yes, this is in effect what a lot of the general lossless compression programs do: the archive is divided into chunks, each chunk in the archive has a header, the header specifies the type of compression for the chunk (among other things) and one of the possible compression types is none. You can see Wikipedia on the Zip format for an example.
I'm not saying that lossless compression programs are somehow bad, just that it's a mathematical certainty that for every file such an algorithm or program will compress there must exist a corresponding file that it will instead enlarge. These do not have to be the same magnitude. I've seen a surprising number of people on various programming forums working on a method that they're sure will compress anything by 30%, or 80%, or whatever, just as soon as they fix some small niggling bugs with the decompression -- point is this is simply not possible to do. Lossless compression is hard and never universal.
25-05-2013, 02:34 AM #40
Yeah, universal compression isn't easy, but for each file type there are some really advance algorithms, even for lossless.
Using headers is a simple enough workaround for general purpose. It could be taken to the next level and split by file, and then compress the files depending on the data type. The problem is that most files people try to compress are already compressed. MP3, videos, binary files.
As for general purpose use 7zip because 7z uses LZMA(MOAR compression), the programs aren't shareware crap, and it supports zip anyway.