I don't know why but i have always had an idea on compression, as in archive compressing like rar/zip. I never understood how you couldn't compress one thing any better then another. I don't know how things are really done so this idea may be so out of the park that it can't be done probebly most likely due to cpu and proccessing time. but here is my idea.

stages of compression. stage one would be 25% shrink of file size so no matter what type of file it is it will shrink 25% but taking all the combinations of 2 binary numbers 11,10,00,01 now if it is a 11 compress that into 1 if 00 then 0 if 10 then A if 01 then B. then the program you have would have a table of decompression orders so stage 1 would just do it backwards. it would have multiple stages of compression but each one taking more time then the one before it but figure with this method entire servers of images and mp3s and whatever you want could be compressed into half the size. simple compression. but i don't know how much cpu/time that would take... anyone maybe have an article or something of why this wouldn't or can't work?

> I don't know why but i have always had an idea on compression, as in archive
> compressing like rar/zip. I never understood how you couldn't compress one thing
> any better then another. I don't know how things are really done so this idea
> may be so out of the park that it can't be done probebly most likely due to cpu
> and proccessing time. but here is my idea.
>
> stages of compression. stage one would be 25% shrink of file size so no matter
> what type of file it is it will shrink 25% but taking all the combinations of 2
> binary numbers 11,10,00,01 now if it is a 11 compress that into 1 if 00 then 0
> if 10 then A if 01 then B. then the program you have would have a table of
> decompression orders so stage 1 would just do it backwards. it would have
> multiple stages of compression but each one taking more time then the one before
> it but figure with this method entire servers of images and mp3s and whatever
> you want could be compressed into half the size. simple compression. but i don't
> know how much cpu/time that would take... anyone maybe have an article or
> something of why this wouldn't or can't work?
>

Using pen and paper, it's possible, and would compress 50%. Unfortunately, computers only like 2 possibilities per bit (usually referred to as 0 and 1), so your A or B are not invited :P

> > I don't know why but i have always had an idea on compression, as in archive
> > compressing like rar/zip. I never understood how you couldn't compress one
> thing
> > any better then another. I don't know how things are really done so this idea
> > may be so out of the park that it can't be done probebly most likely due to
> cpu
> > and proccessing time. but here is my idea.
> >
> > stages of compression. stage one would be 25% shrink of file size so no matter
> > what type of file it is it will shrink 25% but taking all the combinations of
> 2
> > binary numbers 11,10,00,01 now if it is a 11 compress that into 1 if 00 then 0
> > if 10 then A if 01 then B. then the program you have would have a table of
> > decompression orders so stage 1 would just do it backwards. it would have
> > multiple stages of compression but each one taking more time then the one
> before
> > it but figure with this method entire servers of images and mp3s and whatever
> > you want could be compressed into half the size. simple compression. but i
> don't
> > know how much cpu/time that would take... anyone maybe have an article or
> > something of why this wouldn't or can't work?
> >
>
> Using pen and paper, it's possible, and would compress 50%. Unfortunately,
> computers only like 2 possibilities per bit (usually referred to as 0 and 1), so
> your A or B are not invited :P
>
yeah i guess that is going binary to hex it just seems like there should be a way to compress something more.

> > > I don't know why but i have always had an idea on compression, as in archive
> > > compressing like rar/zip. I never understood how you couldn't compress one
> > thing
> > > any better then another. I don't know how things are really done so this
> idea
> > > may be so out of the park that it can't be done probebly most likely due to
> > cpu
> > > and proccessing time. but here is my idea.
> > >
> > > stages of compression. stage one would be 25% shrink of file size so no
> matter
> > > what type of file it is it will shrink 25% but taking all the combinations
> of
> > 2
> > > binary numbers 11,10,00,01 now if it is a 11 compress that into 1 if 00 then
> 0
> > > if 10 then A if 01 then B. then the program you have would have a table of
> > > decompression orders so stage 1 would just do it backwards. it would have
> > > multiple stages of compression but each one taking more time then the one
> > before
> > > it but figure with this method entire servers of images and mp3s and
> whatever
> > > you want could be compressed into half the size. simple compression. but i
> > don't
> > > know how much cpu/time that would take... anyone maybe have an article or
> > > something of why this wouldn't or can't work?
> > >
> >
> > Using pen and paper, it's possible, and would compress 50%. Unfortunately,
> > computers only like 2 possibilities per bit (usually referred to as 0 and 1),
> so
> > your A or B are not invited :P
> >
> yeah i guess that is going binary to hex it just seems like there should be a
> way to compress something more.
>

A Binary Hex conversion 1010 = A, 1011 = B, everything in the computer has to be reduced to binary form otherwise we probably would have really fantastic compression like in your example.

The reason why some things compress better than others is because of how often the data repeates itself. eg graphics files have a lot of the same data where as a binary *.exe file wont. Just say we wanted to compress AAAAABBBBB, in binary we could convert it to 1010:0101,1011:0101 which would read A:5,B:5 rather than writing A and B five times. If you were to try that with a string of data like ABCDEF you would make the file bigger A:1,B:1,C:1,etc not that this isn't how compression works I'm just giving you the basic concept here I hope it makes sense.



here is a link http://www.howstuffworks.com/file-compression.htm