To KOEPI, NIC, REGARDING COOL NEW CODEC

[TimeTraveller]

HELLO GUYS, I SENT KOEPI EMAIL BUT WITH NO RESPONSE I HAD TO HOPE YOU WOULD SEE THIS.......... I THINK I MAY HAVE THE ANSWER TO SUPER LOSSLESS DATA RE-COMPRESSION, MAYBE NOT, BUT IT WOULD BE AN INTERESTING CODEC, AND I WOULD THINK MY BITWISE CODEC IDEAS WOULD POSSIBLY BE INTERESTING TO YOU, IF IT IS A WORKING ALGORYTHM THAT I HAVE COME ACROSS, IT WOULD BE INTERESTING TO WORK WITH YOU CREATING A POSSIBLE NEW "XVID/2" CODEC, THAT KEEPS THE ORIGINAL QUALITY OF AUDIO/VIDEO OF THE XVID MOVIE, AND IS SUPER-DECOMPRESSED INTO A BUFFER FOR THE XVID MOVIE CODEC TO DECIPHER AND WRITE TO SCREEN... CUSTOMIZABLE COMPRESSION RATIOS....... WRITING THIS ALGORYTHM IN MACHINE CODE, OR INLINE ASSEMBLER WOULD BENEFIT THE MOVIE (AVI) FILE BEING POSSIBLY ATLEAST HALF THE SIZE (350 MEGABYTES) COMPARED TO A FULL LENGTH (700 MEGABYTES), AND DEPENDING ON THE CURRENT MACHINE SPEEDS (CURRENT CPU OUTPUT NOWADAYS), THE CUSTOMIZABLE RATIO OF THE RE-COMPRESSION CAN BE INCREASED TO, SAY, FOR EXAMPLE, 1/4 THE SIZE OF A FULL LENGTH XVID AVI FILE (175 MEGABYTES), WHICH, WHEN PEOPLE ENCODE USING THE LATEST XVID ENCODER, AND FLASK A DVDRIP, IT IS THEN RUN THROUGH A CONVERTER PROGRAM TO FORMAT THE AVI FILE , COMPRESSION OF THE MOVIE DATA AT RATIO (I.E. 1:4 IS 1/4TH ORIGINAL SIZE TARGET), AND COULD POSIBLY BE CALLED XVID/2, OR WHATEVER YOU PEOPLE WOULD WANT TO CALL A NEW CODEC FORMULA, THAT IN THE END, IF MY CALCULATIONS ARE CORRECT ABOUT MY DATA COMPRESION (WHICH IS SLOW ENCODING, FAST DECODING, LIKE MP3, WITH DECOMPRESSION OF LOSSLESS DATA, OR COMPLETE ORIGINAL DATA AFTER DECOMPRESSION), ON SAY A P4 3GHz COMPUTER PERHAPS THE SIZE OF THE AVI MOVIE BEING PLAYED ON IT, EVEN A FULL LENGTH FILM, WOULD BE FANTASTICALY SMALL COMPARED TO THE SCREEN AND AUDIO CONTENT.... ON A FAST MACHINE (WHICH THREE YEARS FROM NOW SHOULD BE SURELY SUFFICIENT, IM PRETTY SURE MY ATHLON 1.6GHz COULD PULL THIS ALL OFF ON ITS OWN), A RECOMPRESSION RATIO OF 1/8TH THE SIZE OF THE ORIGINAL BRINGS US DOWN TO 87 MEGABYTES COMPARED TO 700 MEGABYTES. THE PROBLEM WITH IT IS ALSO A SOLUTION TO MAKING THE MOVIE FILE EVEN SMALLER...... IF THERE IS A CRC-CHECKSUM ERROR IN THE COMPRESSED AVI FILE, THE CONSEQUENCE IS THAT A BIG CHUNK OF THE MOVIE WILL NOT PLAYBACK CORRECTLY, FOR EVEN ONE WRONG BYTE VALUE IN THE FILE WILL SET OFF A CHAIN REACTION OF UNWANTED AUDIO AND VIDEO.... SO THE POINT IS THAT EITHER THE CODEC FILTER DOES A CRC-CHECKSUM OF THE COMPRESSED AVI, BY THE CHECKSUM BEING SAVED IN FOUR BYTES SOMEWHERE AT THE BEGINNING OF THE AVI FILE IN THE HEADER, SO THAT IT IS DETECTED TO BE THE COMPLETE ORIGINAL FILE OR NOT, BEFORE PLAYBACK, OR, A NEW FILE EXTENSION THAT ALLOWS SOFTWARE TO COMPRESS THE 87 MEGABYTE AVI FILE EVEN SMALLER, WRITES HEADER INFORMATION CONTAINING THE CHECKSUM IN THE COMPRESSED (FOR EXAMPLE, A VID FILE EXTENSION COULD BE USED) FILE, AND MUST BE DECOMPRESSED AFTER DOWNLOAD........ THE CHECKSUM METHOD WOULD BE AS FOLLOWS:

THE RESULT CHECKSUM DATA WOULD BE FOUR BYTES DUE TO THE FOLLOWING FORMULA AT WORK:

VALUE OF BYTE 1 OF FILE TO BE COMPRESSED IS 125, CHECKSUM REGISTER BYTE 1 BECOMES BYTE VALUE 125.

VALUE OF BYTE 2 OF FILE IS 126, CHECKSUM REGISTER BYTE 2 BECOMES VALUE 126.

VALUE OF BYTE 3 IS 256, REGISTER BYTE 3 BECOMES VALUE 356.

VALUE OF BYTE 4 IS 128, REGISTER BYTE 4 BECOMES VALUE 128.

VALUE OF BYTE 5 IF 55, REGISTER BYTE 1 (NO MORE THAN FOUR BYTES CONTAING CHECKSUM DATA, SO IT RETURNS TO BYTE ONE) IS ALREADY 125, VALUE OF BYTE 5 IN FILE IS 55, SO IT IS 125+55=180, NOW BYTE VALUE OF CHECKSUM REGISTER ONE IS 180......

THEN IT TAKES BYTE 6 OF THE FILE AND ADDS THE VALUE OF BYTE 6 IN THE FILE WITH THE NEXT REGISTER, WHICH IS BYTE 2 OF THE CHECKSUM (A CURRENT VALUE OF 126) AND ADDS THEM TOGETHER, WHICH IS 126+VALUE OF BYTE 6 IN THE FILE....

IF THE A CHECKSUM REGISTER BECOMES LARGER THEN THE MAX AVAILABLE BYTE VALUE (255, MAX CHARACTER VALUE), THEN IT BECOMES VALUE OF CURRENT REGISTER BYTE VALUE MINUS 255... FOR EXAMPLE, IF REGISTER 3 SUDDENLY BECOMES A VALUE OF 305, THE FOLLOWING HAPPENS:

305-255=50, SO REGISTER 3 BECOMES FIFTY....

THIS I FIND WOULD BE A SURE-FIRE METHOD TO ENSURE SECURE ORIGINAL DATA.........

IF YOU WOULD LIKE TO CONTACT ME, MY EMAIL ADDRESS IS BELOW:

cwilson352@cogeco.ca

take care

TimeTRaveller

[Sigmatador]

:eek: ... :confused:

ps: your keyboard have capslock on :D

[Mango Madness]

caps lock dude, geez. Plus this has nothing to do with xvid. See the forum labeled "new a/v formats"?. Xvid is based on mpeg 4 standards of video compression and will probably continue to be so for quite some time.

[TimeTraveller]

One more thing to the fine developers of digital cinemagraphic wizardry, in 3D gaming, if you do not know this already, there is used what is known as a calculation chart, which dramatically speeds calculations of 3D to 2D math vector mathematical pixel plotting.


if a random calculation occurs, say, 1567 multiplied by 34 divided
by 3, the calulation chart would contain the result of 1567 x 34, so that the processor does not actually do the calculation, so also with the result of 1567 x 34 being divided by 3 (53278 div 3), now unless the whole numbers reach the thousands in the calulations of xvid video technology, this could extremely super-speed your codec....


1 2 3 4
-------------
1|1 2 3 4
|
2|2 4 6 8
|
3|3 6 9 12
|
4|4 8 12 16

times table precalculated data, getting the mathematical result faster then the processor can calculate it........

AND THIS IS A GREAT IDEA.......

LETS SEE, WHAT WOULD A XVID MOVIE LOOK LIKE THREE DIMENSIONALLY? YOU COULD CREATE A THREE DIMENSIONAL IMAGE BASED ON THE DEPTH OF THE COLOURS IN EACH FRAME..... BLACK WOULD BE FARTHER BACK THEN WHITE, LET ME TELL YOU THAT, UNLESS FOR SOME REASON AN OPTION TO EVEN INVERT IT...........

AS PROCESSING POWER WOULD BECOME MORE AND MORE AVAILABLE, AND WITHOUT A PROBLEM OF A BIGGER AVI FILE, THE DEPTH INFORMATION COULD BE ENCODED INTO THE MOVIE FILE ITSELF, PRODUCING A THREE DIMENSIONAL IMAGE THAT WOULD BE FANTASTIC TO LOOK AT......... WHICH WHEN THE MOVIE WOULD BE FIRST ENCODED, THE 3D DATA OF THE VIDEO WOULD BE PULLED OFF THE PALETTE OF THE ORIGINAL VIDEO.........

MR. NIC AND MR. KEOPI, I KNOW THIS WILL SOUND FAR FETCHED, BUT I THINK I ALSO HAVE THE ANSWER TO HALLOGRAPHICS (HALLOGRAMS), WHICH IN DEVELOPMENT WOULD COST A FAIR DOLLAR......... I DO NOT MEAN TO GIVE ALL YOU PEOPLE A VAIN IMPRESSION OF MYSELF....

NIC AND KEOPI, IF YOU CAN OBTAIN IT, GET A BOOK LOCATED IN NORTH AMERICA CALLED "FAST MATH", AND YOU WILL FIND MATH ALGORYTHMS THAT WILL BLOW YOU AWAY........ I CAN'T REMEMBER HOW THEY WORK, BUT ALL THAT CAN BE SAID IS, IF WRITING ANY MATHEMATICAL PROBLEM ON PAPER CAN BE SHORT FORMED OR DONE WITH THE FASTEST, MOST SIMPLE METHOD OF GETTING THE RESULT, ITS IN THAT BOOK!

TimeTRaveller

[TimeTraveller]

Originally posted by Mango Madness
caps lock dude, geez. Plus this has nothing to do with xvid. See the forum labeled "new a/v formats"?. Xvid is based on mpeg 4 standards of video compression and will probably continue to be so for quite some time.

I began to write another post as you wrote this one, and to demonstrate the intensity of the conversation I pressed , yet again, the caps lock key to do so....... I am sorry Mango Madness.....

[TimeTraveller]

Originally posted by Mango Madness
caps lock dude, geez. Plus this has nothing to do with xvid. See the forum labeled "new a/v formats"?. Xvid is based on mpeg 4 standards of video compression and will probably continue to be so for quite some time.

If you will allow me to answer what you spoke about this not being related to xvid, all i can say to respond is that the compression would be decompressed into a buffer which the xvid decoder filter would read and decode the xvid mpeg-4 video......... my compression has nothing to do with xvid itself accept that it compresses/decompresses the actual mpeg-4 avi data....... not only this, but perhaps the algorythm I was talking about, from what I see, perhaps could definately be used in mpeg-4 co-dec audio video itself.......


Here is another idea of the top of my head........

I have a "possible" answer to better screen quality....... the openGL method of "smoothing" pixelization could be used, not over the entire decoded xvid frame, but smoothed at the edges of each "block" (I can't remember what they are called in mpeg decoding of film) written to the screen to form the video of one frame of a movie.......

I noticed when I was watching an xvid encoded movie that the film quality is superb, but there are those little noticable fluxuations of a slightly differing, or unmatching colours between themselves giving the video a slightly fluxating screen quality at playback....

TimeTRaveller

[TimeTraveller]

Here is hopefully the final explanation to how to improve screen quality, and would be implemented into the codec........



i am going to use an example of a 256 colour vga palette of a playback of one frame of an mpeg-4 movie...


on the edges of each block is differing colours which when during playback is slightly noticable......


before i explain this, i would just like to say something, this is something i said to AMD when I was trying to help them with building microprocessors.... "If the information I am sending you is useful or not, is irrelevant, it is that if I do not tell someone it may never be done." This is just to say that I do not mean to be a nussence in this forum, but to hopefully be part of something that is interesting to me, for example, the xvid codec.........


anyways,

using, for eaxmple, a 256 colour palette, there are two decoded picture blocks, one beside the other, and at the four edges of each block (or four sides), the connecting pixels, and the colours of them, to form part of the picture, are slightly different in colour......... one one side is a vga palette pixel value of 255 (say an intense white), and on the other side is a pixel value of 249 (a not so intense white), which during playback looks fluxating on the screen........ 255-249=6, devided by two (to find a matching colour for each pixel on either side of the blocks)..... so, 6 div 2 is 3..... 255-3 (or 249+3) is 252........ now the pixel next to the block, say, on the left, is a value of 254, and the value of the pixel next to the block on the right, is a value of, for example, again, 254) our current pixel colour is 252 (a semi intense white), the surrounding colours of these two pixel areas are brighter, so why not increase 252 (mathematically) by a little more, the blend in each part of the frame, block by block, possibly, if at all, producing a screen quality at playback even more desirable?

This may also be how the openGL smoothing of pixelization works....

TimeTRaveller

[fuct]

Wow! This is insane.

[TheXung]

dear heavens man. You wrote so much and the caps lock actually keeps me from being able to read it. Now despite the fact I haven't read everything you wrote, let me point out a few things I've already noticed.

1. Fundamental theorems of lossless compression state that you cannot compress all random files to be smaller. Take an easy example, suppose the original file is 8 bits long and you wanted to compress 8 bit long files to be 4 bit long files. Well there are 2^8 = 256 different 8-bit long files and there are only 2^4 = 16 different 4-bit long files. Within all possible combinations of 4 bit files, you cannot put all combinations of 256-bit files.

Where lossless compression is able to compress files lies in the fact that most files that are useful to people have a certain amount of redundancy in them. Take an english text file, if you use less bits to represent the letter e and thus more bits to represent the lesser used characters like (z,x,v,q, etc) you will end up with an overall smaller file. However if you had a text file of the same length where a majority of the characters were z,x,v,q, etc using the same algorithm, you would make the file larger. The video that you see is already processed through a lossless redundancy compression algorithm. You cannot run it through lossless compression twice and get more compression


2. Nic and Koepi, while play important roles in XviD being where it is today, are not core developers. If you still feel that you should voice your ideas, I would suggest you actually get in touch with the place that xvid is actually developed. Although I would suggest you research what is already being done to video to get it to it's current state of compression before claiming new ideas that will revolutionize video compression.

[avih]

dear TimeTraveller.
you're quite motivated, arn't you? ;)

anyway, regarding your last 2 suggestions (the opengl stuff and the blocks stuff), they are already implemented:

1. opengl filtering: This is usually done by the hardware (display card) when stretching a small image to full screen, or other sizes that are larger than the original. most standard direct show players utilize this feature of the diaplay card. the algorithm used is usually billinear resizing. it can also be done with software (although with higher cpu consumption) as it's done with ffdshow or bsplayer (various resize methods, bicubic, billinear, etc).

2. the blocks stuff: indeed, your idea is called deblocking, and most postprocessors offer this features (i.e. nick's xvid dshow filter, ffdshow, divx, etc).

3. one more idea which you didn't think of is called deringing, surely, by the way you were enthusiasted over deblocking, deringing will blow your mind away ;), search the forums, search the web about postprocessing, i can assure you that you'll find quite interesting info.

cheers mate
avih

[gldblade]

Please give us more details on your fantastic idea to compress things down to 1/4 of their original size. Unless you give us something to ponder, we're all going to be very skeptical.

I have a "possible" answer to better screen quality....... the openGL method of "smoothing" pixelization could be used, not over the entire decoded xvid frame, but smoothed at the edges of each "block" (I can't remember what they are called in mpeg decoding of film) written to the screen to form the video of one frame of a movie....... Block-based smoothing has already been implemented. It's been implemented for a VERY long time now.

LETS SEE, WHAT WOULD A XVID MOVIE LOOK LIKE THREE DIMENSIONALLY? YOU COULD CREATE A THREE DIMENSIONAL IMAGE BASED ON THE DEPTH OF THE COLOURS IN EACH FRAME..... BLACK WOULD BE FARTHER BACK THEN WHITE, LET ME TELL YOU THAT, UNLESS FOR SOME REASON AN OPTION TO EVEN INVERT IT........... Ok, I have a black object six inches away from my face, and a white object a mile away. According to you, the white object is closer than the black. Now, unless my powers of perception are failing me, I think your plan has a very fatal flaw, because I am pretty sure that the black object is in actuality closer to my face than the white.

AS PROCESSING POWER WOULD BECOME MORE AND MORE AVAILABLE, AND WITHOUT A PROBLEM OF A BIGGER AVI FILE, THE DEPTH INFORMATION COULD BE ENCODED INTO THE MOVIE FILE ITSELF, PRODUCING A THREE DIMENSIONAL IMAGE THAT WOULD BE FANTASTIC TO LOOK AT......... WHICH WHEN THE MOVIE WOULD BE FIRST ENCODED, THE 3D DATA OF THE VIDEO WOULD BE PULLED OFF THE PALETTE OF THE ORIGINAL VIDEO......... This would be an enormous deviation from the Mpeg4 standard, which we are definitely staying in compliance with. Once again, your interpretation of depth is flawed, as I have demonstrated above.

MR. NIC AND MR. KEOPI, I KNOW THIS WILL SOUND FAR FETCHED, BUT I THINK I ALSO HAVE THE ANSWER TO HALLOGRAPHICS (HALLOGRAMS), WHICH IN DEVELOPMENT WOULD COST A FAIR DOLLAR......... I DO NOT MEAN TO GIVE ALL YOU PEOPLE A VAIN IMPRESSION OF MYSELF.... Your plan has quite a few flaws. First, your interpretation of depth is flawed, as I have demonstrated. Second, if you plan to convert from a movie to 3d objects, you'd be missing the sides that are facing away from the camera. Third, a lot more than depth is needed to store 3d objects. For example, you also need to store how the objects look in different lighting conditions. A metal sphere and a plastic sphere will reflect light differently. Shall I go on?

None of this is really necessary if the 3d objects are simply recorded, and you know the color of every single pixel in the 3d image. However, this limits the use of holography (this is the correct spelling, btw) because it prevents you from actually manipulating 3d objects.

using, for eaxmple, a 256 colour palette, there are two decoded picture blocks, one beside the other, and at the four edges of each block (or four sides), the connecting pixels, and the colours of them, to form part of the picture, are slightly different in colour......... one one side is a vga palette pixel value of 255 (say an intense white), and on the other side is a pixel value of 249 (a not so intense white), which during playback looks fluxating on the screen........ 255-249=6, devided by two (to find a matching colour for each pixel on either side of the blocks)..... so, 6 div 2 is 3..... 255-3 (or 249+3) is 252........ now the pixel next to the block, say, on the left, is a value of 254, and the value of the pixel next to the block on the right, is a value of, for example, again, 254) our current pixel colour is 252 (a semi intense white), the surrounding colours of these two pixel areas are brighter, so why not increase 252 (mathematically) by a little more, the blend in each part of the frame, block by block, possibly, if at all, producing a screen quality at playback even more desirable? Once again, block based smoothing has already been implemented. *Edit* Hmm...Maybe I'm misunderstanding, but it's probably been done already anyway, as stated in the post above.

[TimeTraveller]

Originally posted by TheXung
dear heavens man. You wrote so much and the caps lock actually keeps me from being able to read it. Now despite the fact I haven't read everything you wrote, let me point out a few things I've already noticed.

1. Fundamental theorems of lossless compression state that you cannot compress all random files to be smaller. Take an easy example, suppose the original file is 8 bits long and you wanted to compress 8 bit long files to be 4 bit long files. Well there are 2^8 = 256 different 8-bit long files and there are only 2^4 = 16 different 4-bit long files. Within all possible combinations of 4 bit files, you cannot put all combinations of 256-bit files.

Where lossless compression is able to compress files lies in the fact that most files that are useful to people have a certain amount of redundancy in them. Take an english text file, if you use less bits to represent the letter e and thus more bits to represent the lesser used characters like (z,x,v,q, etc) you will end up with an overall smaller file. However if you had a text file of the same length where a majority of the characters were z,x,v,q, etc using the same algorithm, you would make the file larger. The video that you see is already processed through a lossless redundancy compression algorithm. You cannot run it through lossless compression twice and get more compression


2. Nic and Koepi, while play important roles in XviD being where it is today, are not core developers. If you still feel that you should voice your ideas, I would suggest you actually get in touch with the place that xvid is actually developed. Although I would suggest you research what is already being done to video to get it to it's current state of compression before claiming new ideas that will revolutionize video compression.

i am well aware of the theories of other people stateing that it is only so compressable, and I truly sir don't mean to brag of myself, I also stated that my theory of super-lossless-data-compression or algorythm for it, might not even work at all, based on my recent findings, and havnt been able to write new software to test it, because I have not been feeling well enough......... but I have also set out to destroy that theory of which a man stated that it was impossible to recompress data down to a certain ratio..... and now i feel to explain how my algorythm works, and I STATE RIGHT NOW that this I am not saying that this is a sure fire method of recompression at all......... I have not even tested it, i have created my form of data compression, which recompressed a text file to 66% its original size.... but this algorythm is slightly different, and I am adding something to it i have not done before ever.

any byte value of a value of anything multiplied by four is automatically devisable by four, anything multiplied by eight is automatically devisiable by eight.

256 (top possible byte value + 1) divided by eight is 32...... lets see..... we will use a bit for a marker to mark if the following data is a compressed byte or not.

due to findings of better recompression, we will use bit value 0 to state that the next 5 bits (which has a possible 32 combinations) is the value of a compressed byte, if the marker bit is 1, it carries an uncompressed byte, which would be the following eight bits, which makes one byte.

a byte value of 256, which is made up of eight bits, can be devided by eight and become the value of 32, and can possible be recorded in 5 bits......

128 divided by 8 becomes 16, anything devisable by eight is a compressable byte value.

so 128 bitwise from what I can figure looks like this.
01111111 when 128 is subtracted by one. (remember we are adding one to each divisable byte)

so, lets see, whats the compressed 6 bit result look like
011111

if the value would be 129, that is not divisable by eight without a decimal fraction remainder, so it would become (bitwise result)

110000000

so, lets see, after a while perhaps the file would become no longer recompressable (It is also not a very FAST codec, its dependant upon the number of bytes devisable by eight)

so we need, not to use regeneratable random byte values, byte perhaps we can use and exclusive order function of a same order value to
XOR the byte values of each byte in the target block of data to be suddenly available for recompression (Let us hope), and we XOR each byte value by an incrementing count value, starting at, perhaps, 0 and making its way to the top, which is 255, in hopes we are capable of recompressing the data yet again once if finds an availability of a ratio of , perhaps legally mathematical, more bytes that are divisable by eight then othewise.

TimeTRaveller

[TimeTraveller]

I appologize if I seem like a mister know it all, I am actually a very nice person that isnt quite feeling that well recently, I havnt been able to work on my data compression via software engineering because of it....... And I wish to say this again, which i stated before, If I state an idea that is already done, or not, it is irrelevant, if I don't put my ideas down on paper, or somewhere else, like this place, perhaps it would never be known or done, or perhaps, like it states in the bible, its all been done before. :)


how would it be possible to recompress data over and over again using a huffman, or say, LZH or ZIP style compression? What needs to be done to the data? (This I worked on intensively while feeling quite ill)

to compress a file using ZIP, it becomes, for example, say, half the size of the original data.


the data compressed is to garbled to be recompressable, therefore stored...... this is what I found, and it seemed (unless it was a software bug making it look that way, I can't even remember if I wrote the software to try to retrieve the recompressed data losslessly) that all the bytes in the compressed ZIP file needed to find something in common......

01010111 is some byte value (dont feel like adding it)
10111010 is another one, say the next byte value in a zip file
11111111
11111101
11101111
00000000
00000000
00000000

now these bitwise bytes dont look to compressable to me, perhaps they are, but they actually look like byte values I saw in zip files.

what do we need to do to possibly recompress the zip file?

there is first of all, the first bit of the byte, and also the last bit of the byte, which could be (And I did so, and it recompressed every single time) which we could change.....

the first bit of a byte is a 128, when followed by seven bits.
the last bit of a byte is either 0 or 1.

we take each byte, record the first bit and the last , either at the end of the converted zip file, or in a new file itself, and we make every single byte in the zip file bitwise start with a bit 0 and end with a bit 0..... making every single byte under the value of 128, and also making every single byte value an even number, because the last bit in the byte is either zero (even) or one (odd)........

TimeTraveller

[TheXung]

You failed to read my explanation carefully enough, there is a very important yet shocking subtlety in my example. You're trying to compress any 8-bit file; any 8 bits represents a space of 256 different data streams. A smaller file, say a 6-bit file can only hold 64 different data streams.

If an algorithm can compress all 8-bit files to 6-bit files, how can you uncompress them all? I have 256 different 8-bit files, they range from 00000000 to 11111111; they're all different. I compress each one of them to 6-bits compressed file. There are only 64 different 6-bit files. I can try decompressing all files from 000000 to 111111, and each file could decompress to an 8-bit file. However there are only 64 different files from 00000 to 111111, so i've only decompressed 64 of my original 256 files. How do I retrieve the remaining 192 files? I have exhausted all possible 6-bit compressed files. Think about this, the 6-bit 001100 file cannot decompress to 4 different 8-bit files, and if it can, how do you choose which 8-bit file at any given time.

If you want a clearer explanation than what I can provide, look into something called the pigeon hole principle.

And just to prove it to yourself, actually write down all numbers from 00000000 to 11111111 and by hand compress them all. Then count how many total bits you've used after compression.

[TimeTraveller]

The recompression i invented that compressed a text file by 33%, is the following method, which could be used as compression method #2 if the other compression method i explained involving dividing a byte value by eight that is possibly divisable by eight and storing the result in five bits......


if the block of data is not compressable with the above mentioned and previously explained method, perhaps this method could be used..... and let me say this to you, the above mentioned method makes me want to write code to make it happen compared to what i am going to explain.........


i also used a bit marker for this method, 0 was seemingly a bitmarker that was more desirable to use then 1, when compressing bytes, or showing that the following eight bits are an uncompresed byte.

01010101 with this method becomes 0 (bit marker carrying the compressed byte data) + 0101.....

which is
00101

because of the re-occuring format of the eight bits of the byte....

01011010 would become

00110

if you can possibly figure out how i computed that........

10100101 becomes

01001

11111111 becomes
01111

00000000 becomes

00000

if the byte bitwise looks like this

11010110

then it becomes

111010110

the first bit is a marker stating the following eight bits are an uncompressed byte........

this method recompressed a text file to 66% of its original size.............. and as i found that it would no longer compress it, i also found that it would not even actually add to the resulting file, accept by about one byte........ even each time i tried to recompress it......... anybody impressed? I'm more impressed about what the other method would produce as far as semi-endlessly recompressable lossless data compression.............

[TimeTraveller]

Originally posted by TheXung
You failed to read my explanation carefully enough, there is a very important yet shocking subtlety in my example. You're trying to compress any 8-bit file; any 8 bits represents a space of 256 different data streams. A smaller file, say a 6-bit file can only hold 64 different data streams.

This is where TIMETRAVELLER begins to respond dear sir.....

It is impossible to compress 8 bits into seven...... bits are boolean logic, its either true or false....... Whatewver you were reading that I wrote perhaps you have not read it clear enough.....

00000000 is byte value zero, 11111111 is 255, 10000000 is 128,
01000000 is 127, 01010001 is 81

any byte value from 0-255 that is divisable by the # eight is capable of being recorded in 5 bits, and 1 bit is used to mark a compressed byte, if the marker states that it is an uncompressed byte, the following eight bits are the actual uncompressed byte itself, for example, above is 81, and that is not mathematically possible to divide 81 by the # 8 (81 div 8) and not have a decimal fraction with the result..........





If an algorithm can compress all 8-bit files to 6-bit files, how can you uncompress them all? I have 256 different 8-bit files, they range from 00000000 to 11111111; they're all different. I compress each one of them to 6-bits compressed file. There are only 64 different 6-bit files. I can try decompressing all files from 000000 to 111111, and each file could decompress to an 8-bit file. However there are only 64 different files from 00000 to 111111, so i've only decompressed 64 of my original 256 files. How do I retrieve the remaining 192 files? I have exhausted all possible 6-bit compressed files. Think about this, the 6-bit 001100 file cannot decompress to 4 different 8-bit files, and if it can, how do you choose which 8-bit file at any given time.

If you want a clearer explanation than what I can provide, look into something called the pigeon hole principle.

And just to prove it to yourself, actually write down all numbers from 00000000 to 11111111 and by hand compress them all. Then count how many total bits you've used after compression.

[gino25]

Wow :eek:

[R3g]

Quite amazing ! TimeTraveller ,tell me, which year did you came from ?

BTW, be careful, you systematically but "then" instead of "than" in your posts, which is very confusing for non-english readers.

[sh0dan]

Originally posted by TimeTraveller
but I have also set out to destroy that theory of which a man stated that it was impossible to recompress data down to a certain ratio.....

Oh my - sound like the weekly hoax at comp.compression.research that has been going on for almost ten years. I wont get

Please - go bother some compression researcher - this is definately not the place.

look at the comp.compression FAQ (http://www.faqs.org/faqs/compression-faq/)

Is there any point in continuing this thread?

[Teegedeck]

Right - please, TimeTraveller, take this discussion somewhere else. Most people on this forum, and this includes myself, wouldn't be able to tell whether you actually have one good idea among the many things you wrote (in a very unreadable manner, by the way).

Please take all your spontaneous posts and try to compose one, inherently logical and reader-friendly thesis from them and post this in preferably a developers' forum where ideas for new codecs are discussed. Maybe the Theora people can tell you immediately whether you've got something there or whether it's all dated or even a bunch of crap.

Greetings,

Tee

[Nic]

I feel exactly what sh0dan said.

No offense TimeTraveller, I can see your very enthused but this doesn't belong here. And there is no such thing.

If you get something more concrete, accurate and neatly represented, feel free to post in the New Formats forum (but only if you have real, true tested evidence!).

Compression sites and FAQs will help you understand what the TheXung was trying to convey

Thread closed.

-Nic

ps
When I first got into compression theories I read this FAQ many years ago now:
http://www.faqs.org/faqs/compression-faq/