A man claims to store multiple movies on 64kb

[fccHandler]

Originally posted by Joe Fenton
The prof writes 2 + 2 on the board, then in the next step writes 4
:confused: 2 + 2 = 4?

Nonsense. 2 is a prime number, and 4 is a perfect square. Besides, quantum theory would never allow that.

[virus]

Originally posted by fccHandler
Egad, I'm still wrestling with these numbers, trying to derive a simple equation. That shows you what a pathetic geek I am. ;)
...and also what a pathetic algorithm you're using ;)

That number is evenly divisible by 359, which gives 489,060,500,101. But is that a prime?
Hints are not allowed...! :D
But anyway, here's mine: if you multiply a number that takes M bits with one that takes N bits, your result requires up to M+N bits... now try to find prime factors of a number that takes M+N=48 bits... ;)

@virus, you're an evil dude. :sly:
Not only I'm evil, but I can also shrink that sequence down to 39 bits using a trivial algorithm that uses just a few clock cycles per byte :devil:


:)

virus

[fccHandler]

Originally posted by virus
I can also shrink that sequence down to 39 bits using a trivial algorithm that uses just a few clock cycles per byte :devil:
I don't doubt it. But you won't get a movie to fit in 64K using that algorithm either. ;)

[MrTVideo]

Thats the first I heard of that, most interesting. Just to throw a another slant. There are other types of computers, Analog for instance and lets not forget what we have on our shoulders. I believe we store in pattens and even I have more cells than any computer made, shame I cannot recall digitally. So when I went over this thread I get the feeling that this box of his was indeed an alternative memory device "Programed to store and play movies". Which we do in dreams. Don't make sense but movies just the same and in colour. I said I would like to throw a slant

[callmeace]

Originally posted by virus
A few quotes from callmeace:

So, maths is advanced, maths is powerful, maths is needed to build this "algorithm", yet it doesn't need to apply. Looks a bit strange to me...

;) The maths that needn't apply is that which has been used by many of you to 'prove' the impossibility of my compression claims. Selectively quoting me so as to misrepresent the context in which those quotes were originally posted is rather naughty virus but no hard feelings ;)

I have been working on a post which will help most of you understand.

To give stephanV some answers in the meanwhile:
with my way you wouldn't have to store all the information at each stage you only tell it what to do with the result. Example: lets say you have the input. We know it is going to be seen as blocks of numbers which must be a multiple of ten with or without +1. Lets say we break the blocks down to what adds up to each number. You don't have to store this number becaused it's only used while the formula is running. Each step generates the content to be processed by the next step (either way through the formula). In other words, the point none of you seem to understand - you don't have to store the contents of the input file in my way, I'm not using normal methods there is not any 'magic' compression. I have said this before.
When you have your end character string the original file can be built back up in stages through the formula - each result being processed in the next step.

I await more ridicule, but either way I will get an explanatory post finished which tries to give an overall concept view of how it might work.

[duartix]

Hey! I can't compress "top models" to less than 10 bytes. :(
Oh s**t! I forgot "top models" are already fully zipped! :o
Wouldn't mind unziping one, though! :cool: :D

[MrTVideo]

callmeace your theory makes sense in as far as the 64k(if I get your drift) holds the formular and the assembly code to dissasemble and then reassemble for input and output. But is'ent that just a "codec" anyway, where the actual information is kept in in another location.?

[gldblade]

I think your basic idea is that given a set of data, you can represent it with a smaller set of data that can be used to reconstruct the original data. Then you hope to perform multiple passes, each time needing less and less data to represent previous passes, in the end reaching an extremely small file size.

Based upon this synopsis, you will require an algorithm that satisfies two requirements: it can indefinitely reduce filesize, it is completely reversible.

I believe that you stated it was up to math to find such an algorithm. However, I will state that it is ignorance that suggests that such an algorithm exists in the first place. My rudimentary understanding of information theory suggests that such a process cannot possibly exist, and if you believe otherwise, please prove it by locating such an algorithm. Then proceed to contact the many information theory scientists across the globe to tell them that their decades of research is wrong.

*EDIT*
Just to clarify, you can come up with an algorithm that can indefinitely reduce filesize (approximately at least, you can't get down below 1 bit). You can come up with an algorithm that is reversible. But you can't come up with an algorithm that can do both.

The reason is that reducing filesize intrinsically loses information. You can have lossless compression up to a certain (mathematically proven) limit using various tricks, afterwards lossy compression is required to further decrease filesize. Since information is lost in the process, you cannot fully reconstruct previous data. With each pass, more and more information would be lost, meaning less and less of the original data.

For example, let's take an algorithm where you merely divide by 10 and round.

123456
12346
1235
124
12
1

Information is clearly lost with each iteration such that one would have less and less hope of reconstructing the original data the more iterations you run.

You may claim that there is an algorithm out there somewhere that will somehow meet both requirements of indefinite filesize reduction and full reversibility. Once again, I would state that this is due to a lack of understanding on the limits of mathematics.

An alternative approach to having a single algorithm is to have multiple formulas that will each individually reduce the size of the data, which is probably one of the ideas that you were trying to get across.

For example,

120, formula: divide by 5
24, formula: divide by 4
6, formula: divide by 3
2, formula: divide by 2
1

In which case, if you knew every single formula in the chain, you could theoretically reduce the orignal data to a very small filesize. However, even this approach has some major issues. First, will these formulas be predetermined, or will they be generated on the fly?

If the formulas are predetermined, then the process can only represent a *very* limited subset of data. For example, the chain above cannot represent a starting value of 121. Therefore, to be practical, the formulas would need to be generated on the fly.

However, how then do you tell the decoder what to do with the end data? You would need to store the formula chain somehow, probably alongside the processed data that you will use to reconstruct the original data. But then have you really reduced the filesize? Doesn't the storage of the formula chain count towards the filesize? If you take this into account, I think you will realize that this imposes a significant limit on your compression efficiency, and may even exact a severe penalty in some cases. Using the example above, storage of the number 120 requires only 8 bits. Storage of the number 1, along with the formula chain, would require many more than that.

I must applaud anyone who read through all of this. I can't believe I actually wrote this much considering its 4:25 in the morning. I must apologize for lack of coherency anywhere :P

[MrTVideo]

No if its possible at all then it would be necessary to start backwards 64000 bytes each byte how many bits ( lets give ourselves a chance say 32) so we have 64000 x 32 bits of information to work with
so how could that array of bits be used to store one movie say a 4.7 gig mpeg2 already heavily compressed. Here is where, if it can be believed that it was done at all. obviously not by compression algorithms but what?. Consider a movie of 4.7 gig 4,700,000,000 explained in 64000x32 = 2,048,000
which would be a compression ratio of 4,700,000,000/2,048,000
229,492:1 I think again that if it was done at all you would have to ask how much information could be stored. Even if some form of look up table was used that would have to be stored external.

I think turning water into wine would be easier. wait a bit I brew my own beer. I use water add flavour add sugar and after a bit drink it.
Nothing is impossible

[gldblade]

@MrTVideo

Sorry, I was talking to callmeace :P I don't think what he is proposing is possible

[Soulhunter]

Dunno what you all complain about..:confused:

Ive tested this compression method, and it works excellent !!!

Just watch this screenshot (http://img93.exs.cx/my.php?loc=img93&image=341.jpg) from a Matrix Reloaded -> 3x floppy-disk encode... :D


Bye

[stephanV]

Originally posted by callmeace
In other words, the point none of you seem to understand - you don't have to store the contents of the input file in my way, I'm not using normal methods there is not any 'magic' compression. I have said this before. When you have your end character string the original file can be built back up in stages through the formula - each result being processed in the next step.


Yes, but in my example you havent reached any compression at all. You have actually inflated the file by a factor of 3... so what would the next step do?

[MrTVideo]

Ah! this is where we have to forget about digital. in a previous post I said that we think in pattens and mentioned other types of computers hoping for a response. Ok well I will propose another massive storage device. You have to start moving into electronics and analog.
Suppose that 64K is made not with gates as in digital computers, holding a two state code, but capacitors that can be individualy programed to a set voltage(Patten) assume each bit(capacitor) can hold 10 volts(Back to digital notation) and we use a mathmatical notation to base 10 then the limitation of the code is the number of places of decimal the voltage can be written and read to. In theory if the actual size of the storage device is not critical then I cannot see a problem other than speed of info transfer.
There are other options but the theory's starts to get bit thick.

Digital storage is finite not that you cannot create more storage area just exactly how much you can put in a given space.

1. Would involve being able to iradiate and un-iradiate (if thats the term)a passive substance and measure the level. I do not know much about nuclear theory but believe it possible.

2. Using a photo electric cell and store a light value converted to a voltage. IE: An optical computer.

Impossible has never been a term I can be comfortable with, especially, as in my 62 years, having seen the impossible occur many times.

[Manao]

MrTVideo : "Suppose that 64K is made not with gates" ---> then, you're not speaking of 64Kbits anymore :)

[fccHandler]

"Gates"? You mean Bill? :D

[MrTVideo]

Of course not, we are now in the realm of analog computing and remember a figure of 64k was originaly stated. A Rat has more memory cells than a cray computer maybe he used a rat. (Only Joking) I am just throwing alternative theory's around. I read a fiction story which had a truth about it. A group of scientists were told another govenment had solved the anti_gravity problem. Because the story was supported by that countries leader they believed it was true The outcome a device crude but working was made. Now that was fiction. When I was a boy I submited a essay to my science teacher on what was the most significant event I would witness. I wrote an account of how a man would make the journey, land on and return from the moon. That was in 1958 I gave a date of 20 years later. I was penalised to write 500 times a mans body could not stand the escape velocity of what? I think 22,000 miles/hr. Just goes to show what is thought impossible today is reality tomorrow. All of you can attest to that, we now have a global world not a flat one. Sorry about going on so much. I will not even attempt to tell you where I think Einstien went wrong only to quote that fantastic sentance "I think therefore I am"

[Doobie]

Originally posted by MrTVideo I was penalised to write 500 times a mans body could not stand the escape velocity of what? I think 22,000 miles/hr. Just goes to show what is thought impossible today is reality tomorrow.

Escape velocity has nothing to do with sending men to the moon. We use rockets, not cannons.

[MrTVideo]

I agree but remember back then they only had v1's and Verna Von Braun
to go on, It was the speed that scientists of the day could'ent get a handle on and remember it was much later that the "G" suits were perfected to stop a persons blood from being pushed to one side of their body. Canon or rocket a person still has to reach that speed (before the fuel/Kinetic energy runs out) in order to escape the earths gravity ergo "escape velocity". There was a lot of work done on rocket sleds and yes some were like cannons. but this is getting off track.

[r6d2]

Originally posted by Doobie
Escape velocity has nothing to do with sending men to the moon. We use rockets, not cannons. We use rockets because we cannot use cannons. If we did, men on board would end up like an omelette. :)

AFAIK, we use rockets to achieve escape velocity (http://en.wikipedia.org/wiki/Escape_velocity) gradually. In fact, we take advantage of the fact that escape velocity decreases significantly with distance to the Earth center of gravity.

If at any point during flight the rocket stops propelling, and speed is lower than escape velocity at that point, it falls down. You know what they say: the higher they fly, the harder they fall. ;)

Maybe that's one possible way of compressing a movie into 64-KB. :D:D:D

[MrTVideo]

Whats that got to do with compression :D I am still waiting to hear from some out there who have a real wide personal paradyne. I scored a response but not in the right direction

[r6d2]

Originally posted by MrTVideo
Whats that got to do with compression :D Well, the falling rocket would end up very compressed. Just like the astronauts on the cannon. :D:D:D

[MrTVideo]

WoW I looked at that article on ESCAPE VELOCITY at 9000 km you still need a 7km/sec kick in the pants. You can see why I had to write those lines (7km/sec. 420km/hr) I read an article on just how a rocket can get in space. All to do with how fast they can dispose of their fuel (A super garbage disposal device). This really stuffs the original thread. I apologuise but could not resist the banter, Good will to all.
Terry ;)


Spelling correction I hate it when I do that

[Monkeychops]

If I remember my Astrophysics lectures correctly an escape velocity of 11Km/s (not sure if this is correct but dont want to work it out) is necessary if and only if the rocket etc is not propelled in any way after launch.

Effectively rockets can get into space because they expend the amount of energy necessary to increase their potential energy such that they escape Earth's gravity field (not totally but good enough.)

By a similar token, if you had a long enough ladder you could climb it to the Moon by expending the energy to raise your potential energy.

[Foofaraw]

Wow the arrogance in this thread :) "I can't imagine any way to do this, so it will never be possible" - Tsk tsk.

Well it was always thus, most people saying something was impossible and then suddenly someone has a brilliant idea and something new becomes possible.

I'd like to think there are great compression ideas yet to be discovered, and unless 3D storage becomes so cheap that nobody cares about size I'm sure we'll find them eventually (unless we nuke the planet)

And hey, the people who make Stuffit just made a new compression algorithm that will losslessly compress JPEG files by an average of 30% (as opposed to zip's 0%-1%)

What do you know :D
http://compression.ca/act/act-jpeg.html

[Joe Fenton]

Originally posted by Foofaraw
Wow the arrogance in this thread :) "I can't imagine any way to do this, so it will never be possible" - Tsk tsk.

And hey, the people who make Stuffit just made a new compression algorithm that will losslessly compress JPEG files by an average of 30% (as opposed to zip's 0%-1%)

It's not arrogance, it's intelligence. He didn't claim his movie compression saved 30%, he claimed it saved 10,000%. If you can't see the difference, you would certainly mistake intelligence for arrogance. :rolleyes: