Quote from Lanthanide

Quote from rockz

Take farty's example: mp3 is 1.47 MB. png is 1.42 without decent compression.

Where does Farty say how big either of the files are?

In my only post. ;o

Actually, I guess not. Maybe it was in the shoutbox ... I was talking about it a bit somewhere at least. /Edit

Quote from Lanthanide

Also this simply doesn't make sense from a theoretical standpoint, unless the MP3 compression simply wasn't as "compressed" as possible. I think you'd see a similar drop in size if you put it into a .zip or .rar.

Compression isn't the major issue here ... Other than being able to actually upload the image, the files would the same size as you'd download anyway. And if you really want to get fancy you could just chunk the files into small pieces with any archiving tool.. though that would be a pain to retrieve (re-assembly could be automated).

Quote

Actually, I guess not. Maybe it was in the shoutbox ... I was talking about it a bit somewhere at least. /Edit

Don't know about that other guy, but you mentioned the sizes to me over MSN.

Quote

Also this simply doesn't make sense from a theoretical standpoint, unless the MP3 compression simply wasn't as "compressed" as possible. I think you'd see a similar drop in size if you put it into a .zip or .rar.

Well, the most ""compressed" as possible" algorithm would yield a one byte file (and be pretty useless, but that's irrelevant).
No compression is perfect; any file can be compressed further by introducing a new algorithm.

Quote from EzDay281

Well, the most ""compressed" as possible" algorithm would yield a one byte file (and be pretty useless, but that's irrelevant).
No compression is perfect; any file can be compressed further by introducing a new algorithm.

Please go do some information theory or something, because you don't know what you're talking about.

As usual wikipedia is a useful starting point: http://en.wikipedia.org/wiki/Information_entropy and http://en.wikipedia.org/wiki/Lossless_data_compression#Limitations

Quote from Lanthanide

Please go do some information theory or something, because you don't know what you're talking about.

Actually, he's right. An algorithm told to interpret a single bit as "01001111101010010000010101111100101010001111111111110100100..." would achieve "compression" by reducing the size of said corresponding file to one bit (as on any device with said algorithm, the one-bit file would be "uncompressable". It just happens to be useless because the size of the decompressor would be larger than the original file.

Hey, look what Reddit found

Quote from Lanthanide

Quote from EzDay281

Well, the most ""compressed" as possible" algorithm would yield a one byte file (and be pretty useless, but that's irrelevant).
No compression is perfect; any file can be compressed further by introducing a new algorithm.

Please go do some information theory or something, because you don't know what you're talking about.

I made a specific claim. You should explain specifically in what way it is irrelevant or false.
I'm quite confident the latter is not the case.

Quote from HCM™Aristocrat

Quote from Lanthanide

Please go do some information theory or something, because you don't know what you're talking about.

Actually, he's right. An algorithm told to interpret a single bit as "01001111101010010000010101111100101010001111111111110100100..." would achieve "compression" by reducing the size of said corresponding file to one bit (as on any device with said algorithm, the one-bit file would be "uncompressable". It just happens to be useless because the size of the decompressor would be larger than the original file.

Why would we be making a decompressor for a single file? It'd be simpler to just make a program that spits out the desired file with no input. A decompressor larger than a single instance of its output isn't necessarily useless if given multiple, different inputs. (Granted, only two possible ones for a single-bit compression)
On the other hand, a single-bit compression's corresponding decompression would be, like stated, two possible values. Lossiness there is the problem.

Quote from EzDay281

I made a specific claim. You should explain specifically in what way it is irrelevant or false.
I'm quite confident the latter is not the case.

I provided you with wikipedia links, did you read them?

You will discover that a "lossless compression algorithm", which is what we are discussing, must be able to reproduce the original document, otherwise it is not a "lossless compression algorithm". Therefore reducing a file to a single bit (or byte) is not a lossless compression algorithm.

Furthermore if you read the wikipedia pages, you will see that they say that for any compression algorithm, there are some inputs for which the resulting output will always be larger than the input; it is IMPOSSIBLE to make an algorithm that makes 100% of all inputs smaller. So your claim that you can take any file and give it to another algorithm that will always make it smaller is also wrong. If you read the page of shannon's theory, which is about the entropy of information, you would know that there is a mathematical limit to compression which cannot be breached: when a file is already at this limit, using another algorithm on it will NOT make it smaller.

Consider the actual implications of what you're suggesting: we could find some string of algorithms that we could use to make any file 1/10th of it's original size (or even smaller). And yet this doesn't happen in reality, because it is in fact impossible.

A universal lossless compressor is impossible.

You must create a specialized algorithm that only reduces files you need. the nature of the algorithm means that other unideal inputs must be increased in size.

Stop talking about compression. This has nothing to do with what the topic is about...

Quote from Lanthanide

Furthermore if you read the wikipedia pages, you will see that they say that for any compression algorithm, there are some inputs for which the resulting output will always be larger than the input; it is IMPOSSIBLE to make an algorithm that makes 100% of all inputs smaller.

He never claimed otherwise to any of this. ;o

Quote

Consider the actual implications of what you're suggesting: we could find some string of algorithms that we could use to make any file 1/10th of it's original size (or even smaller). And yet this doesn't happen in reality, because it is in fact impossible.

He never suggested that either.

Quote from O)FaRTy1billion

Quote from Lanthanide

Furthermore if you read the wikipedia pages, you will see that they say that for any compression algorithm, there are some inputs for which the resulting output will always be larger than the input; it is IMPOSSIBLE to make an algorithm that makes 100% of all inputs smaller.

He never claimed otherwise to any of this. ;o

Quote

Consider the actual implications of what you're suggesting: we could find some string of algorithms that we could use to make any file 1/10th of it's original size (or even smaller). And yet this doesn't happen in reality, because it is in fact impossible.

He never suggested that either.

He said this: "No compression is perfect; any file can be compressed further by introducing a new algorithm." which has the implications of both the above statements.

For a given file (not any/every file) you can find better algorithms more suited for that file (or type of file), so that particular file will get compressed more that compared to other algorithms. Never was it suggest that "a single better algorithm for every file ever" could exist.

EDIT:
By the way I edited the hell out of this trying to make myself more clear. xD "Any" seemed pretty ambiguous here, so I was replacing with "every".

That's not necessarily true, because we are taking an *already compressed* file and trying to make it smaller. It is not the case that it is possible to find an algorithm for a given file that makes that given file smaller, see the wikipedia page:

Quote

Mark Nelson, frustrated over many cranks trying to claim having invented a magic compression algorithm appearing in comp.compression, has constructed a 415,241 byte binary file ([1]) of highly entropic content, and issued a public challenge of $100 to anyone to write a program that, together with its input, would be smaller than his provided binary data yet be able to reconstitute ("decompress") it without error.[7]

Quote

I provided you with wikipedia links, did you read them?

https://www.google.com/
This website I just linked you to explains why you are wrong.
Somewhere.
Find it yourself.

Quote

You will discover that a "lossless compression algorithm", which is what we are discussing

...
mp3.
Lossless.
The hell are you talking about?

Quote

So your claim that you can take any file and give it to another algorithm that will always make it smaller is also wrong.

I never said that.
I referred to "a new algorithm" - not "a single algorithm", not "one of the algorithms we've already applied to a file", but "any one of the uncountable millions of millions of possible algorithms that can be defined on a modern computer in a few mega- or gigabytes."

Quote

Consider the actual implications of what you're suggesting: we could find some string of algorithms that we could use to make any file 1/10th of it's original size (or even smaller).

That's because to be useful in any way, we need to keep track of what algorithms we used so that we know how to decompress it.
And yes, in the vast majority of the set of all possible data strings, this data plus the compressed data will be as large or larger than the input.
Fortunately for me, that's not what we're talking about. We're talking about the result of an mp3 compression of what I assume is mostly naturally-recorded sound (though I suppose farty could have used white noise, techno music, a videogame recording or something as the source), which is an extremely limited subset of all possible data strings of that given size. So no, the output is not random noise; it is a predictable, pattern-rich string.
Unless you want to try to tell me that mp3 is a practically perfect compression (i.e. the output is effectively random noise for all practically useful decompression algorithms except mp3).

edit:
Ninja'd. Actually, ninja'd^5 or so.

Quote

Mark Nelson, frustrated over many cranks trying to claim having invented a magic compression algorithm appearing in comp.compression, has constructed a 415,241 byte binary file ([1]) of highly entropic content, and issued a public challenge of $100 to anyone to write a program that, together with its input, would be smaller than his provided binary data yet be able to reconstitute ("decompress") it without error.[7]

It took us 358 years to solve Fermat's last theorem.
"It's hard" and "it's mathematically impossible" are very different things.

OK Megashares search function is back up, false alarm! *phew*

This pretty much sums up the piracy thing.

http://www.escapistmagazine.com/videos/view/jimquisition/5268-Piracy-Episode-One-Copyright

Looks like Hotfile might be going down next: http://www.bbc.co.uk/news/technology-17300225