comp.compression Google Group

Re: Bijective 2 State Arithmatic coding question

2008-07-24T00:38:16Z

Actually if you look at the includes you will find a routine
w() this is core routine that changes bits to bytes bijectively on
output.
w(0) is where you are writting a '0' bit and w(1) is where your
writting
a one '1' bit. w(-1) it when your done you could call it end of
string.
But there is an excpct if the string is all ones. then the -1 at end

Re: compression type

2008-07-23T17:37:17Z

We're done here. I think your next course of action is to stop
ranting and program an LZ77 compressor so that you gain actual
experience writing a compressor. Here's a few links to help you get
started:
[link]

Re: genuine random compressability

2008-07-23T17:24:06Z

What is a "data block"? Data is not free. If you constrain your idea
of a "data block" to a single byte then you can see there is no space
savings.
Already you are disproving your own argument. You are saying that it
should be simple to represent:
"ajkl12"
in a different form with:
"(data but not aj k, and 12: aj:k:12: data)TOKENS"

Fast and Efficient Ring Compressor

2008-07-23T13:44:56Z

[link]

Re: Bijective 2 State Arithmatic coding question

2008-07-23T13:17:21Z

Hi Biject,
Thanks for your info, I am aware now, the program
actually work in bytes.
my problem is that I need to use it in a variable length bit string
consist of eg '010001011 11110000 101'
which is not a direct byte block and the output is not a byte block
either.
Is there possible of such kind of 2 state arithmatic compresser ? Any

Last Call for Papers (extended): World Congress on Engineering and Computer Science WCECS 2008

2008-07-23T09:39:26Z

Last CFP (extended): World Congress on Engineering and Computer
Science WCECS 2008
WCECS 2008: San Francisco, USA, 22-24 October, 2008
[link]
Important Dates:
Draft Paper Submission Deadline (extended): 30 July, 2008
Camera-Ready Papers Due & Registration Deadline (extended): 16 August,

PCR re-stamping this unknown ...

2008-07-23T07:19:47Z

Hi,
I can not find detailed information on this feature "PCR re-stamping". In
certain applications it may be that the input stream from the transport
multiplexer is provided at a fixed rate and will not support the standard TS
interface handshake mechanism and consequently some form of rate adaption is

Re: compression type

2008-07-23T05:14:41Z

and i bet though that what's compressed is able to be compressed again
the same way.. i mean, there should be any reason why there isn't
patterns to find like this in how you say curved lines and sphere
areas...

Re: compression type

2008-07-23T05:12:40Z

and maybe the file format would be where at the beginning just say one
thing after the other the way each thing after another can only be
what starts in the center at rotates around what makes it so a curved
line maybe can also be draw to connect things to together? then the
rest of the file as just curved line tokens?

Re: compression type

2008-07-23T05:02:12Z

so it's like saying that in data of any size no matter what, there's a
benefit if it can be found to have a pattern that's bigger than the
token be reorganized more than one way right?
like, in all of the data to compress... just find in all of it
"uiJKllnq" and also "KlluiB" to store "ui J K ll n q b", and then

Re: compression type

2008-07-23T04:28:41Z

For the point of what I tried saying about random...
since it can be said that any random data is compressed if you have a
software program with the same entropy source seed the generation of
random data, isn't it the same to say that random carries no trend in
it's nature against compressability?
Like, duh... isn't the random generating software program just the

Re: genuine random compressability

2008-07-23T02:06:57Z

anybody know how to explain that tradeoff better than me?

Re: genuine random compressability

2008-07-23T02:03:54Z

i mean to say..
isn't it like saying that no matter what the size of data is, it's
that the way to just say it and not be smaller is
(sphere)TOKEN but then to say smaller is to only find _in any size it
can be_ only a few patterns that reorganize.
it's neat how the size of the curves and how you work the sphere area

Re: genuine random compressability

2008-07-23T01:53:14Z

Ok so given nothing different about the size I was thinking it would
be a file with just the same size about for what it is it say
(sphere)TOKEN and just if you have all the data into the sphere not
broken apart.
so that's the same size, so then it can be thought that everything to
do where size is smaller is to be where something like

Re: genuine random compressability

2008-07-22T19:31:08Z

You are completely neglecting the size of the data necessary to
describe these spheres and curves/lines. Saying "put all the file in
a sphere" implies that you are defining a sphere and indicating where
the file goes. That takes up space. It is not free. Try working it
out and you'll see that this arbitrary arrangement takes up more space