Science and Technology news... :: View topic

mathieu · Guest

On Oct 25, 6:58 am, sobriquet <dohduh...@yahoo.com> wrote:
[quote]On 24 okt, 09:42, mathieu <mathieu.malate...@gmail.com> wrote:

On Oct 23, 7:14 pm, sobriquet <dohduh...@yahoo.com> wrote:

Hello.
On an art cdrom, the graphics are jpgs that are bundled somehow. Does
anyone know how to unbundle them or extract the individual jpg files
from the package?

An example data file is here:

http://www.ibbu.nl/~nsprakel/combY

Simply renaming it to combY.jpg and opening it with irfanview will
display the first image in the package.

I am on linux and non-of the usual tool did work for me :

Kind regards and thanks in advance for any suggestions, Niek

Here is what I used:

$ wgethttp://www.ibbu.nl/~nsprakel/combY
$ file combY
combY: data

$ dd skip=108 bs=1 if=combY of=test.jpg
$ $ file test.jpg
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark
\015ÿÛ"

$ jpeginfo test.jpg
toto.jpg 781 x 1090 24bit JFIF N 852248

The jpeg marker is at 0x6c AFAIK

2cts

I think there are supposed to be two jpg images in the combY file, but
I>m not sure if they actually use
[/quote]
byte 4 is actually the number of files: 0x02 and 0x0A match. You>ll
need a package of more that 255 image to check how they encoded then
(need more than one byte).

Phil Carmody · Guest

Mark Adler <madler@alumni.caltech.edu> writes:
[quote]On 2008-10-26 13:12:02 -0700, Phil Carmody
thefatphil_demunged@yahoo.co.uk> said:
(Well, you might worry,
you>re falling into the behaviour patterns of google-groups-using
usenet newbs, rather than someone who actually knows what he>s doing.)

Sigh. Well, you can now count me among the newbs. I never had google
groups take so long. (And in fact those three posts and your replies
*still* haven>t shown up there.)
[/quote]
Ha - you>re no newb, Mark! If you>re not part of the furniture in c.c
then I don>t know who is!

I think it>s the time of year. Googlegroups did exactly the same
thing last year too. The largest tally I remember was 7 resends of
the same post from one guy I know - so you were well short of showing
hard-core newbiness!

[quote]I just downloaded a real newgroup reader which I am using as we speak,
and I>ll start using that instead of google groups.
[/quote]
It seems to work. Welcome to Usenet as it should be!

Phil
--
Richard Heathfield - please do not waste your time mailing unsolicited
Christian ramblings in response to my signatures.

As with the Christian religion, the worst advertisement for Socialism is its
adherents. -- Eric Arthur Blair (1903-1950), The Road to Wigan Pier (1937)

Nimo · Guest

jules Gilbert wrote:
[quote]On Oct 24, 3:07ï¿½am, Nimo <azeez...@gmail.com> wrote:
Ok thanks for your good hint,any how I put myself this weekend
my target as to come up with a sloution to this 50 or 60 years of saga
of compression world.

"At the end data compression is not at all Rocket Engineering".
I>m going to start a new thread all the ideas I>ve in my mind to
discuss.

=========

(Hello, Nimo! Welcome.)

I>ve been working on compression issues for a little less than 15
years. And only now, after working on this topic only part-time,
(well, most of the time,) probably the equivalent of about five years,
have I accomplished what I set out to do, and to do it efficiently.

Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
that had already been compressed,) and piped it through the compressor/
decompressor I intend to use when I come down to Texas to take Mark>s
hard earned money.

My program isn>t really very good at all -- it only does about 3,000
to 1, and in a single pass! And worse, most files are made so small
that they don>t present a sufficiently significant chunk for my
program to perform a second physical pass.

The facts with one omission are accurate as stated in the prior
paragraph.

And what>s the omission? I have a very complex getBIT/putBIT
arrangement, not the usual bit-I/O stuff but something very
different; Well, the data comes in okay, but leaves not-so-hot. Over
the course (this is measured,) of 1450 bytes, about 25 are faulty,
those bytes contain single bit-errors.

I know, with savings like this (92k to 32 bytes,) I could simply do it
three or even five times and vote the bits -- and it may come that.

I>m spending this week looking at the problem.

I realize that few people believe me; For now, that>s alright. Some
things take time and when my investors say "okay", well, we have
plans.

But soon. How soon? Soon. A month? Yes, probably about a month.

And what will happen then? Well, for one thing a lot of you folks
will look so incredibly foolish -- though I>ll stick up for you. I>ll
say that we live in different worlds, the rules are different in my
world.

Do we share the same physical space? Yes. The same physics? Yes.
The same math? Yes. Then what>s different? It works better if you
work this out yourself...

--jg
[/quote]

yeah can you give more details,it will helpful for me
Thanks.

Industrial One · Guest

On Oct 27, 12:14 am, jules Gilbert <jules.sto...@gmail.com> wrote:
[quote]On Oct 24, 3:07 am, Nimo <azeez...@gmail.com> wrote:

Ok thanks for your good hint,any how I put myself this weekend
my target as to come up with a sloution to this 50 or 60 years of saga
of compression world.

"At the end data compression is not at all Rocket Engineering".
I>m going to start a new thread all the ideas I>ve in my mind to
discuss.

==========

(Hello, Nimo! Welcome.)

I>ve been working on compression issues for a little less than 15
years. And only now, after working on this topic only part-time,
(well, most of the time,) probably the equivalent of about five years,
have I accomplished what I set out to do, and to do it efficiently.

Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
that had already been compressed,) and piped it through the compressor/
decompressor I intend to use when I come down to Texas to take Mark>s
hard earned money.

My program isn>t really very good at all -- it only does about 3,000
to 1, and in a single pass! And worse, most files are made so small
that they don>t present a sufficiently significant chunk for my
program to perform a second physical pass.

The facts with one omission are accurate as stated in the prior
paragraph.

And what>s the omission? I have a very complex getBIT/putBIT
arrangement, not the usual bit-I/O stuff but something very
different; Well, the data comes in okay, but leaves not-so-hot. Over
the course (this is measured,) of 1450 bytes, about 25 are faulty,
those bytes contain single bit-errors.

I know, with savings like this (92k to 32 bytes,) I could simply do it
three or even five times and vote the bits -- and it may come that.

I>m spending this week looking at the problem.

I realize that few people believe me; For now, that>s alright. Some
things take time and when my investors say "okay", well, we have
plans.

But soon. How soon? Soon. A month? Yes, probably about a month.

And what will happen then? Well, for one thing a lot of you folks
will look so incredibly foolish -- though I>ll stick up for you. I>ll
say that we live in different worlds, the rules are different in my
world.

Do we share the same physical space? Yes. The same physics? Yes.
The same math? Yes. Then what>s different? It works better if you
work this out yourself...

--jg
[/quote]
Nimo, don>t listen to this psychopath, he>s full of shit.

sobriquet · Guest

On 27 okt, 10:54, mathieu <mathieu.malate...@gmail.com> wrote:
[quote]On Oct 25, 6:58 am, sobriquet <dohduh...@yahoo.com> wrote:

On 24 okt, 09:42, mathieu <mathieu.malate...@gmail.com> wrote:

On Oct 23, 7:14 pm, sobriquet <dohduh...@yahoo.com> wrote:

Hello.
On an art cdrom, the graphics are jpgs that are bundled somehow. Does
anyone know how to unbundle them or extract the individual jpg files
from the package?

An example data file is here:

http://www.ibbu.nl/~nsprakel/combY

Simply renaming it to combY.jpg and opening it with irfanview will
display the first image in the package.

I am on linux and non-of the usual tool did work for me :

Kind regards and thanks in advance for any suggestions, Niek

Here is what I used:

$ wgethttp://www.ibbu.nl/~nsprakel/combY
$ file combY
combY: data

$ dd skip=108 bs=1 if=combY of=test.jpg
$ $ file test.jpg
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark
\015ÿÛ"

$ jpeginfo test.jpg
toto.jpg 781 x 1090 24bit JFIF N 852248

The jpeg marker is at 0x6c AFAIK

2cts

I think there are supposed to be two jpg images in the combY file, but
I>m not sure if they actually use
a marker. Perhaps they have the filesizes stored as constants in the
program so they don>t need
a separator code.

I have another example of a package that probably consists of more
jpgs here:

http://www.ibbu.nl/~nsprakel/combK

$ strings combY | grep JFIF | wc
2 2 10

$ strings combK | grep JFIF | wc
10 10 50

Use an hex editor and look for JFIF (pretty easy). You>ll see there is
a small header before each jpeg. So I would guess layout is:

main header (12 bytes):
01 00 00 0A 00 02 62 96 03 0F 04 15

for each jpeg:
108 - 12 = 96 bytes header per jpeg
then the first jpeg marker: ffd8

inspect the main header and you might find 2 or 10 encoded for the
number of files. and maybe you have the jpeg length encoded in the
'header per jpeg'.

good luck
[/quote]
Thx a lot for your help. I think with a hex editor and a little
programming in prolog, I should be able
to obtain the individual jpgs.

Btw, the complete collection of artworks can be downloaded here:

http://thepiratebay.org/torrent/4473238/National_Gallery_Complete_Illustrated_Catalogue_CDROM

Nimo · Guest

On Oct 28, 12:30 pm, Industrial One <industrial_...@hotmail.com>
wrote:
[quote]On Oct 27, 12:14 am, jules Gilbert <jules.sto...@gmail.com> wrote:

On Oct 24, 3:07 am, Nimo <azeez...@gmail.com> wrote:

Ok thanks for your good hint,any how I put myself this weekend
my target as to come up with a sloution to this 50 or 60 years of saga
of compression world.

"At the end data compression is not at all Rocket Engineering".
I>m going to start a new thread all the ideas I>ve in my mind to
discuss.

=========
(Hello, Nimo! Welcome.)

I>ve been working on compression issues for a little less than 15
years. And only now, after working on this topic only part-time,
(well, most of the time,) probably the equivalent of about five years,
have I accomplished what I set out to do, and to do it efficiently.

Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
that had already been compressed,) and piped it through the compressor/
decompressor I intend to use when I come down to Texas to take Mark>s
hard earned money.

My program isn>t really very good at all -- it only does about 3,000
to 1, and in a single pass! And worse, most files are made so small
that they don>t present a sufficiently significant chunk for my
program to perform a second physical pass.

The facts with one omission are accurate as stated in the prior
paragraph.

And what>s the omission? I have a very complex getBIT/putBIT
arrangement, not the usual bit-I/O stuff but something very
different; Well, the data comes in okay, but leaves not-so-hot. Over
the course (this is measured,) of 1450 bytes, about 25 are faulty,
those bytes contain single bit-errors.

I know, with savings like this (92k to 32 bytes,) I could simply do it
three or even five times and vote the bits -- and it may come that.

I>m spending this week looking at the problem.

I realize that few people believe me; For now, that>s alright. Some
things take time and when my investors say "okay", well, we have
plans.

But soon. How soon? Soon. A month? Yes, probably about a month.

And what will happen then? Well, for one thing a lot of you folks
will look so incredibly foolish -- though I>ll stick up for you. I>ll
say that we live in different worlds, the rules are different in my
world.

Do we share the same physical space? Yes. The same physics? Yes.
The same math? Yes. Then what>s different? It works better if you
work this out yourself...

--jg

Nimo, don>t listen to this psychopath, he>s full of shit.
[/quote]
@ industrial one any problem with this guy?
Thanks:)

Leo B. · Guest

On Oct 25, 12:17 pm, Mark Adler <mad...@alumni.caltech.edu> wrote:

[quote]All you really need is gzwrite(). From there, any sort of printf
function you>d like is just a few lines of code.

True, but nevertheless gzprintf is included.

In retrospect, I wish we hadn>t included it.
[/quote]
That (along with a rationale) would have made more sense.

Thank you,
Leo

Industrial One · Guest

On 29 Okt., 21:52, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]From the same argument also follows that you cannot compress any file
to 77 bits, we>re making only a bit fun of you here - sorry.

As a survival kit for this group, make sure you understand the "counting
argument", one of the very easy, and very basic foundations of
compression, also known as pigeon hole principle. I don>t want to spoil
your fun learning it, so I won>t post it here, but it>s really a matter
of counting correctly to see that it is impossible to compress *every*
possible file, you always must make most of them larger while only
making some of them smaller.

The art is picking the sub-set of the files that get smaller under
compression such that it contains *interesting* files. Not to avoid any
expansion, which is impossible.

So long,
Thomas
[/quote]
Richie, you forget that you backed off during that discussion with
Jacko, so you got no place pretending to be dissing anyone here.

The counting argument for the most part is valid, but only pertaining
to space. What about time? If a bit is in a different state next
millisecond, then the amount of existing physical constants is
irrelevant. At least, that>s how I understand the abstract of Jacko>s
thereom. I>m way too dumb to grasp his math and follow discussion.

Thomas Richter · Guest

Nimo wrote:

[quote]Nimo, don>t listen to this psychopath, he>s full of shit.

@ industrial one any problem with this guy?
[/quote]
Since you seem to new here, a couple of facts (and I mean facts and not
"conjectures"):

Jules is around here for more then ten years, claiming every time he>s
showing up having invented the ultimate compression program, and failed
every single time to provide any evidence for its existence, usually
with rather goofy arguments. Most of his inventions break elementary
rules of logic, such as that there is no invertible N to M mapping for N
[quote]M, so only very little training will allow you to prove him wrong. I
throw $100 into the pot for betting he>s unable to give a demonstration[/quote]
of his invention this time yet again. Demonstration again by the very
same rules people posted here over again:
a) Jules makes binaries for his compressor available,
b) I (or someone else) downloads that executable,
c) I (or someone) creates a test-corpus of files,
d) Jules compresses the files
e) Jules makes the files available for download,
f) I (or someone else) expands the files with the executable from the
step b) above,
g) if all expanded files compare equal to the original, and all
compressed files are smaller than the input files, Jules wins, otherwise
I (or someone else) wins.

From the same argument also follows that you cannot compress any file
to 77 bits, we>re making only a bit fun of you here - sorry.

As a survival kit for this group, make sure you understand the "counting
argument", one of the very easy, and very basic foundations of
compression, also known as pigeon hole principle. I don>t want to spoil
your fun learning it, so I won>t post it here, but it>s really a matter
of counting correctly to see that it is impossible to compress *every*
possible file, you always must make most of them larger while only
making some of them smaller.

The art is picking the sub-set of the files that get smaller under
compression such that it contains *interesting* files. Not to avoid any
expansion, which is impossible.

So long,
Thomas

Thomas Richter · Guest

Industrial One schrieb:
[quote]On 29 Okt., 21:52, Thomas Richter <t...@math.tu-berlin.de> wrote:
From the same argument also follows that you cannot compress any file
to 77 bits, we>re making only a bit fun of you here - sorry.

As a survival kit for this group, make sure you understand the "counting
argument", one of the very easy, and very basic foundations of
compression, also known as pigeon hole principle. I don>t want to spoil
your fun learning it, so I won>t post it here, but it>s really a matter
of counting correctly to see that it is impossible to compress *every*
possible file, you always must make most of them larger while only
making some of them smaller.

The art is picking the sub-set of the files that get smaller under
compression such that it contains *interesting* files. Not to avoid any
expansion, which is impossible.

So long,
Thomas

Richie, you forget that you backed off during that discussion with
Jacko, so you got no place pretending to be dissing anyone here.

The counting argument for the most part is valid, but only pertaining
to space. What about time? If a bit is in a different state next
millisecond, then the amount of existing physical constants is
irrelevant. At least, that>s how I understand the abstract of Jacko>s
thereom. I>m way too dumb to grasp his math and follow discussion.
[/quote]
Mathematics is not about physical existence; it is a logical argument,
not a physical one. Whether the stream exists in space, or time, or not
at all doesn>t matter. If I want to be able to reconstruct a given
sequence, let them exist in time or in space, or not at all, I need to
make sure that no two input sequences map to the same output. Thus, the
counting argument is not a limitation of physics. It is a limitation
that is implied by what is meant by compression (namely, to be able to
uniquely recover the source). You cannot have one without the other.

So long,
Thmas

Jim Leonard · Guest

On Oct 29, 9:39 pm, Industrial One <industrial_...@hotmail.com> wrote:
[quote]I>m way too dumb to grasp his math and follow discussion.
[/quote]
While I>m going to sidestep the obvious jokes I could make in the
above, I will say that you are not "too dumb to grasp his math" -- his
math is flawed like all of the other infinite compression nutjobs.

Jacko>s method is actually a variation on the "magic function" theory
(this is the same as Jules, actually), where people think that they
are able to analyze random data, find a pattern or patterns, and come
up with a function (ie. a random number generator) that produces
either the same or nearly the same output as the source.

Most people who try to write "magic function" compressors find that
the output is nowhere near close to the original, and then assume that
they can still use their idea and store the differences in the output
to reconstruct the original. After implementing this, they find that
(function + list of differences) > (size of original file) and give
up. Well... except for Jules and Jacko.

Industrial One · Guest

On Oct 30, 7:35 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]Industrial One schrieb:

On 29 Okt., 21:52, Thomas Richter <t...@math.tu-berlin.de> wrote:
From the same argument also follows that you cannot compress any file
to 77 bits, we>re making only a bit fun of you here - sorry.

As a survival kit for this group, make sure you understand the "counting
argument", one of the very easy, and very basic foundations of
compression, also known as pigeon hole principle. I don>t want to spoil
your fun learning it, so I won>t post it here, but it>s really a matter
of counting correctly to see that it is impossible to compress *every*
possible file, you always must make most of them larger while only
making some of them smaller.

The art is picking the sub-set of the files that get smaller under
compression such that it contains *interesting* files. Not to avoid any
expansion, which is impossible.

So long,
Thomas

Richie, you forget that you backed off during that discussion with
Jacko, so you got no place pretending to be dissing anyone here.

The counting argument for the most part is valid, but only pertaining
to space. What about time? If a bit is in a different state next
millisecond, then the amount of existing physical constants is
irrelevant. At least, that>s how I understand the abstract of Jacko>s
thereom. I>m way too dumb to grasp his math and follow discussion.

Mathematics is not about physical existence; it is a logical argument,
not a physical one. Whether the stream exists in space, or time, or not
at all doesn>t matter. If I want to be able to reconstruct a given
sequence, let them exist in time or in space, or not at all, I need to
make sure that no two input sequences map to the same output. Thus, the
counting argument is not a limitation of physics. It is a limitation
that is implied by what is meant by compression (namely, to be able to
uniquely recover the source). You cannot have one without the other.

So long,
Thmas
[/quote]
Exactly. I>m saying you>re only applying the counting argument to the
first case and ignoring the other.

On Oct 30, 4:00 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]On Oct 29, 9:39 pm, Industrial One <industrial_...@hotmail.com> wrote:

I>m way too dumb to grasp his math and follow discussion.

While I>m going to sidestep the obvious jokes I could make in the
above, I will say that you are not "too dumb to grasp his math" -- his
math is flawed like all of the other infinite compression nutjobs.

Jacko>s method is actually a variation on the "magic function" theory
(this is the same as Jules, actually), where people think that they
are able to analyze random data, find a pattern or patterns, and come
up with a function (ie. a random number generator) that produces
either the same or nearly the same output as the source.

Most people who try to write "magic function" compressors find that
the output is nowhere near close to the original, and then assume that
they can still use their idea and store the differences in the output
to reconstruct the original. After implementing this, they find that
(function + list of differences) > (size of original file) and give
up. Well... except for Jules and Jacko.
[/quote]
That>s not what Jacko>s theory consists of. Hell, that ain>t even how
the magic function theory works. It>s not that I can>t grasp math, I
just go apeshit when trying to concentrate too long, (I fucked up on
many algebra exams 'cuz I didn>t pay attention to the -/+ signs) but
if I took some time to chillax, sit down and have Jacko on an IM
keeping me on-track, I might get somewhere.

Definitely not today. Now 'scuse me while I snack on my huge stash of
Halloween candy 'till I get fuckin sick.

Nimo · Guest

On Nov 1, 8:15 pm, "Jyoti Sharma" <jyoti.mic...@gmail.com> wrote:
[quote]On Sat, 01 Nov 2008 19:19:34 +0530, Nimo <azeez...@gmail.com> wrote:
So for so this is not full theory,I got stuck in the middle
and posting here my conclusion ,to continue with the help of you
people.
-------------------------------------------------------------------------
Eg:-1001000100011111011110111

1 0 0 1 0 0 0 1 0 0 0 1 1 14
1 2 3 4 5 6 7 8 9 10 11 12 13

Cont....

1 1 1 0 1 1 1 1 0 1 1 1
15 16 17 18 19 20 21 22 23 24 25 26

Now you got the length of your file 26-1=25units.

you would get a unique graph on Cartesian co-ordinate
geometry[Euclid>s]

A gentle reminder-- earlier you signed with:
Rejector of Euclidean Geometry,
Admirer of Rene Descartes.

So, you must have written the ``coordinate geometry(Euclid>s)" above by mistake.

use any of these rules to find out area

(a)Simpsom>s 1/3 rule
(b)Simpson>s 3/8 rule
(c)Trapezoidal rule.
(d)Booles rule.

From my implementation of such algorithms I found different variations of Gauss Quadrature algorithm the most efficient(speedy And accurate).

Now in your hand you have area and length of your file,

Area=l*b.

therefore the 'parts' of the 'breadth' is our given string.

So, you mean you will store only A and l and recover the points during decompression? I understood this only-- and if you actually mean this I guess a simple attempt to achieve this will tell you the problems that lies therein.

regards,
Jyoti
[/quote]
I know man,wait a while,would see rest of the people>s comments, and
will further discuss about coding.

thanks.
I>m interested in presenting the paper jointly
(so if any people interested let me know. )
I>m as complex as a pointer and a virtual function.

Guest · Posted: Sat Nov 01, 2008 5:07 pm Post subject: Re: Geometric Compression

On 1 nov, 11:49, Nimo <azeez...@gmail.com> wrote:
[quote]So for so this is not full theory,I got stuck in the middle
and posting here my conclusion ,to continue with the help of you
people.
-------------------------------------------------------------------------
Eg:-1001000100011111011110111

1 0 0 1 0 0 0 1 0 0 0 1 1 14
1 2 3 4 5 6 7 8 9 10 11 12 13

Cont....

1 1 1 0 1 1 1 1 0 1 1 1
15 16 17 18 19 20 21 22 23 24 25 26

Now you got the length of your file 26-1=25units.

you would get a unique graph on Cartesian co-ordinate
geometry[Euclid>s]

use any of these rules to find out area

(a)Simpsom>s 1/3 rule
(b)Simpson>s 3/8 rule
(c)Trapezoidal rule.
(d)Booles rule.

Now in your hand you have area and length of your file,

Area=l*b.

therefore the 'parts' of the 'breadth' is our given string.

Thanks.
trying to submit paper herehttp://www.csa.iisc.ernet.in/
[/quote]
I think it>s not possible to recover a file with only its lenght and
the number of 1s in it.

Fibonacci Code · Guest

On Nov 2, 1:07 am, ggfll5...@gmail.com wrote:
[quote]On 1 nov, 11:49, Nimo <azeez...@gmail.com> wrote:

So for so this is not full theory,I got stuck in the middle
and posting here my conclusion ,to continue with the help of you
people.
-------------------------------------------------------------------------
Eg:-1001000100011111011110111

1 0 0 1 0 0 0 1 0 0 0 1 1 14
1 2 3 4 5 6 7 8 9 10 11 12 13

Cont....

1 1 1 0 1 1 1 1 0 1 1 1
15 16 17 18 19 20 21 22 23 24 25 26

Now you got the length of your file 26-1=25units.

you would get a unique graph on Cartesian co-ordinate
geometry[Euclid>s]

use any of these rules to find out area

(a)Simpsom>s 1/3 rule
(b)Simpson>s 3/8 rule
(c)Trapezoidal rule.
(d)Booles rule.

Now in your hand you have area and length of your file,

Area=l*b.

therefore the 'parts' of the 'breadth' is our given string.

Thanks.
trying to submit paper herehttp://www.csa.iisc.ernet.in/

I think it>s not possible to recover a file with only its lenght and
the number of 1s in it.
[/quote]
Hi Nimo,

last time I do play with something like this, I cannot
make it work, may be just share it if
you can come up with something.

as we know a so call packed random file has almost equal number of
byte type. eg. if there is 100 Character 45,
it will be more or less number of character 20 etc, to be simpler, 50%
0 and 50% 1

so if I know there is almost same amount of the 256 character, I can
really do a combinatoric extraction from it.
For example (using 00,01,10,11)

If there is a random string. 00 01 00 10 10 10 11 11 10 10 00 11 00 11
01 01 01 01 00 11
1 2 1 3 3 3 4
4 3 3 1 4 1 4 2 2 2 2 1 4

as you know Combinatorics 4x3x2x1 = 24,
We can extract the string like this.

00 01 00 10 10 10 11 11 10 10
00 11 00 11 01 01 01 01 00 11
1 2 1 3 3 3 4
4 3 3 1 4 1 4 2 2 2 2 1 4

Extra Info derived (Eg)
First code 1 2 3 4
Second Code 1 3
4 2 (3
must after the first code 3 so as 4)
Third Code
3 1 4
2 (within 3 and 1, there is no 4 and 2
anymore)
Fourth Code
3 1 2 4 (this 2
must after the 3th code 2),
Fifth
Code
3 4 2 1 (this 2 must
after the 4th code 2)

For the 5 codes combinations, you need 24^5 which is around 23 bit to
store it. as the original string is 40 bit,
there is still left 17 bit to store the length. The length combination
is quite complicated, but it is not without
certain pattern within the 23 bit information. as the combination of
the 24 type of code rotation tells the
order information as well eg, first code of every combination state
the first redundant code type.
By utilize the derived information, we might had some hope.... (joke)

Just my two cents.

Fibonacci.aka
Ray Of Happiness


www.GetXFactor.com Leading Technology, Science, Agriculture News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Science and Technology news... Forum Index -> Compression Forum	Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next
Page 6 of 9