| Author |
Can I compress 45Bytes to 37Bytes?
|
|
| arniewang@yahoo.com.cn 2005-04-15, 3:55 pm |
| hi,
I am want to compress data frames 45Bytes/Per frame to 37Bytes. the
sample printed out data is
" 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D98EF3D
705B75208501"(46Bytes).
I have tried some source code provide by internet with LZ77
coding
LZ78 coding
LZW coding
RLE coding
but all of them gernerate a data frame bigger than 46Bytes. I am very
frustrated.
can anybody give me some advice. I am considering flow compress. i.e
compress in this side and decompress the other side just like online
movie. will it possible? as I know we can not distinct the two frames
after compressing.
thanks.
| |
| Phil Frisbie, Jr. 2005-04-15, 3:55 pm |
| arniewang@yahoo.com.cn wrote:
> hi,
> I am want to compress data frames 45Bytes/Per frame to 37Bytes. the
> sample printed out data is
> " 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D98EF3D
705B75208501"(46Bytes).
> I have tried some source code provide by internet with LZ77
> coding
> LZ78 coding
> LZW coding
> RLE coding
> but all of them gernerate a data frame bigger than 46Bytes. I am very
> frustrated.
What created this frame of data? If it is already compressed, then it is not
likely you will be able to compress it any further.
> can anybody give me some advice. I am considering flow compress. i.e
> compress in this side and decompress the other side just like online
> movie. will it possible? as I know we can not distinct the two frames
> after compressing.
>
>
> thanks.
--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
| |
| David A. Scott 2005-04-15, 8:55 pm |
| arniewang@yahoo.com.cn wrote in
news:1113578223.760970.163240@f14g2000cwb.googlegroups.com:
> hi,
> I am want to compress data frames 45Bytes/Per frame to 37Bytes. the
> sample printed out data is
> " 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF
> 3E3D98EF3D705B75208501"(46Bytes).
> I have tried some source code provide by internet with
> LZ77
> coding
> LZ78 coding
> LZW coding
> RLE coding
> but all of them gernerate a data frame bigger than 46Bytes. I am very
> frustrated.
>
> can anybody give me some advice. I am considering flow compress. i.e
> compress in this side and decompress the other side just like online
> movie. will it possible? as I know we can not distinct the two frames
> after compressing.
>
>
> thanks.
>
>
I am not sure exactly what your porblem is. Do you need exatly 37 bytes.
what if some are 40 and some 34. Secondly to compress just 46 bytes to
37 you need to know more about the data it may or may not be possible.
Also you claimed you used LZW did you try my version. If you used source
off the net many compressors made for long files and you may need to mod
them to shorten or remove wasted parts of the headers.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| arniewang@yahoo.com.cn 2005-04-16, 3:55 am |
| In fact I use bit to arrange data in it, there are about 37Bytes
contain the actuall data (maybe compressed). the other 9Bytes is
arranged by us bit by bit. so I think it is not easy to compress.
can I treat many frame sequencyly and send out one frame one time,
maybe this better than treat only one frame.
| |
| arniewang 2005-04-16, 3:55 am |
| Scott:
I have try some sample from you websites
ah3
arb3w
arb255
arbsha1
arbsha2
bibwt1
bwtdsc
bwtrle
fin2in
lzw1
lzw3s
vh
ah2
ah1
ah2a
ah2af
except some exes must use conditional files that I have not try , but
none can compress my binary data.
the sample way to compress is:
CHAR*
pchInput=" 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D98EF3D
705B75208501";
/* 92 chars mean 46 byte data */
BYTE lpBufSrc[PCUDATALEN];
BYTE lpBufDest[2*PCUDATALEN];
DWORD dwOrgLen=PCUDATALEN;
DWORD pdwEncLen=2*PCUDATALEN;
DWORD dwMaxLen=2*PCUDATALEN;
int i;
for (i=0;i<PCUDATALEN;i++)
{
sscanf(pchInput, "%2x", &lpBufSrc[i]);
pchInput+=2;
}
RunLengthEncode ( lpBufSrc,dwOrgLen,
lpBufDest,&pdwEncLen,dwMaxLen );
| |
| arniewang 2005-04-16, 3:55 am |
| sourc code to test my bin data:
CHAR*
pchInput=" 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D98EF3D
705B75208501";
BYTE lpBufSrc[PCUDATALEN];
BYTE lpBufDest[2*PCUDATALEN];
DWORD dwOrgLen=PCUDATALEN;
DWORD pdwEncLen=2*PCUDATALEN;
DWORD dwMaxLen=2*PCUDATALEN;
int i;
for (i=0;i<PCUDATALEN;i++)
{
sscanf(pchInput, "%2x", &lpBufSrc[i]);
pchInput+=2;
}
RunLengthEncode ( lpBufSrc,dwOrgLen,
lpBufDest,&pdwEncLen,dwMaxLen );
| |
| Jürgen Eidt 2005-04-16, 3:55 am |
| <arniewang@yahoo.com.cn> schrieb
> I am want to compress data frames 45Bytes/Per frame to 37Bytes. the
> sample printed out data is
> " 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D98EF3D
705B75208501"(46Bytes).
Must the compressed data a ASCII representation as well?
Your data can be easily compressed to a 8bit binary chunk because your data
range of the input data is fixed (A-Z 0-9). You have 36 symbols and if you
would use 6bits for them (trivial case) for your input symbols, you end up
with 34 Bytes by simply stuffing the bits. Using a compression scheme can
get you further down, but it really depends on your needs.
| |
| guenther vonKnakspott 2005-04-16, 8:55 am |
|
arniewang@yahoo.com.cn wrote:
> hi,
> I am want to compress data frames 45Bytes/Per frame to 37Bytes.
the
> sample printed out data is
>
" 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D98EF3D
705B75208501"(46Bytes).
> I have tried some source code provide by internet with
LZ77
> coding
> LZ78 coding
> LZW coding
> RLE coding
> but all of them gernerate a data frame bigger than 46Bytes. I am very
> frustrated.
>
> can anybody give me some advice. I am considering flow compress. i.e
> compress in this side and decompress the other side just like online
> movie. will it possible? as I know we can not distinct the two frames
> after compressing.
>
>
> thanks.
Wether it works or not is dependant on wether your frames contain 45 or
37 Bytes of actual information. Put another way, can your frames be one
of ANY possible combinations of 45 Bytes, or can you rule some
combinations out? In the former case compression is impossible. In the
second one, the rate of compression is a function of the amount of
combinations that can be ruled out.
Regards
| |
| arniewang 2005-04-16, 8:55 am |
| I convert the byte to string for print out. so every two char equal
mens a Hex value of byte . I think there exisit possible in the this
string.
| |
| arniewang 2005-04-16, 8:55 am |
| every two chars stand for one hex byte value.
at current stage any compress method I found in internet can not work
at all.
by the scott I do not know how to use fin2in to compress things.
| |
| arniewang 2005-04-16, 8:55 am |
| I think a bit level Arithmetic compresser would do this?
I want a pure bit level arithmetic encoder and not one that
does LZW, RLE, etc based on byte and than passes it to a bit level
arithmetic comprssor.
| |
| David A. Scott 2005-04-16, 3:55 pm |
| "arniewang" <arniewang@yahoo.com.cn> wrote in
news:1113643548.584771.18190@o13g2000cwo.googlegroups.com:
> every two chars stand for one hex byte value.
> at current stage any compress method I found in internet can not work
> at all.
>
> by the scott I do not know how to use fin2in to compress things.
>
I am not the best communicator. However fin2in is not want you want to
use. To even test the use of my code you would have to place the
47 bytes in a file by itself. When you have a 47 byte file the do
something like arb2x file.in file.out and see if the output file
is shorter.
Suspose it is shorter. Since your are not using files you have to
place this data back into some sort of structure. You may or may not
have to add some control information of chance the existing control
information of where you are currently using it. In otherwords how
does progrm know its 46 or 47 bytes. How will it reconize 30 or 37
bytes.
I decided since you show interest to check some of my bijective
file compressor on a file of you short data here is the results
using you on data
4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3E3D9
8EF3D705B75208501
Your test set of bytes in file in.tmp
0000 4B 63 40 1F 80 4F DF 86 CE E7 61 DA 46 F5 5C 91 *Kc@..O....a.F.\.*
0010 AC E4 45 D9 88 B4 DB F8 C9 F7 E2 7D 35 5D E4 85 *..E........}5]..*
0020 1E 0B BF 3E 3D 98 EF 3D 70 5B 75 20 85 01 . . *...>=..=p[u ..*
number of bytes is 46
results
arb255 iid type of bijective adaptive arithmetic 256 symbols.
arb255 in.tmp out.tmp
so your data not good for arb255
0000 AB 47 05 24 63 12 C1 DF 39 CD AB 88 6E 60 CA B6 *.G.$c...9...n`..*
0010 8E 72 46 2B FD 8D 49 16 73 EF 66 B4 A5 38 8D F9 *.rF+..I.s.f..8..*
0020 A8 07 CA 99 84 4A E4 8F E2 D9 96 14 A0 D2 A7 D8 *.....J..........*
0030 88 . . . . . . . . . . . . . . . *.*
number of bytes is 49
arb2x bijective adaptive arithemtic 2 symbols bit based
arb2x in.tmp out.tmp
so your data not good for arb2x
0000 E7 62 40 6B 38 70 1E 22 CA 8C BF C7 E2 C2 02 53 *.b@k8p.".......S*
0010 A9 44 8F 54 BC A2 E9 18 8B A7 78 AA E8 A4 4A 21 *.D.T......x...J!*
0020 50 C2 2C 1D 6C 74 31 94 63 AC 42 5B BA DD 70 . *P.,.lt1.c.B[..p*
number of bytes is 47
lzw3a this is a 2 root bijective LZW compressor
the optiom -c is for compression -d for decompression
lzw3a -c in.tmp out.tmp
So your data not good for lzw3a
0000 F5 10 52 78 14 82 8B 27 EB 83 4D 0A EB 39 D9 B6 *..Rx...'..M..9..*
0010 40 02 92 3E F4 81 1A 7E DE 32 81 D7 7B E8 DA B9 *@..>...~.2..{...*
0020 C2 1C 13 BC 0A 55 1E A1 DF 44 45 BB 0B 6B 1E AD *.....U...DE..k..*
0030 5D C0 . . . . . . . . . . . . . . *].*
number of bytes is 50
So without a custom model of your data built in. I think it is
safe to say none of my compressor would compress to the level
you want. In fact it looks like your test case results in
expansion.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| guenther vonKnakspott 2005-04-16, 3:55 pm |
|
arniewang wrote:
> I convert the byte to string for print out. so every two char equal
> mens a Hex value of byte . I think there exisit possible in the
this
> string.
Will you answer my question?
| |
| David A. Scott 2005-04-16, 8:55 pm |
| "David A. Scott" <daVvid_a_scott@email.com> wrote in
news:Xns963A42F5F9179H110W296LC45WIN3030
R@213.155.197.138:
> "arniewang" <arniewang@yahoo.com.cn> wrote in
> news:1113643548.584771.18190@o13g2000cwo.googlegroups.com:
>
>
> I am not the best communicator. However fin2in is not want you want
> to
> use. To even test the use of my code you would have to place the
> 47 bytes in a file by itself. When you have a 47 byte file the do
> something like arb2x file.in file.out and see if the output file
> is shorter.
> Suspose it is shorter. Since your are not using files you have to
> place this data back into some sort of structure. You may or may not
> have to add some control information of chance the existing control
> information of where you are currently using it. In otherwords how
> does progrm know its 46 or 47 bytes. How will it reconize 30 or 37
> bytes.
>
>
> I decided since you show interest to check some of my bijective
> file compressor on a file of you short data here is the results
> using you on data
>
> 4B63401F804FDF86CEE761DA46F55C91ACE445D9
88B4DBF8C9F7E27D355DE4851E0BBF3
> E3D9 8EF3D705B75208501
>
> Your test set of bytes in file in.tmp
> 0000 4B 63 40 1F 80 4F DF 86 CE E7 61 DA 46 F5 5C 91
> *Kc@..O....a.F.\.* 0010 AC E4 45 D9 88 B4 DB F8 C9 F7 E2 7D 35 5D E4
> 85 *..E........}5]..* 0020 1E 0B BF 3E 3D 98 EF 3D 70 5B 75 20 85 01
> . . *...>=..=p[u ..*
> number of bytes is 46
>
> results
>
> arb255 iid type of bijective adaptive arithmetic 256 symbols.
> arb255 in.tmp out.tmp
> so your data not good for arb255
> 0000 AB 47 05 24 63 12 C1 DF 39 CD AB 88 6E 60 CA B6
> *.G.$c...9...n`..* 0010 8E 72 46 2B FD 8D 49 16 73 EF 66 B4 A5 38 8D
> F9 *.rF+..I.s.f..8..* 0020 A8 07 CA 99 84 4A E4 8F E2 D9 96 14 A0 D2
> A7 D8 *.....J..........* 0030 88 . . . . . . . . . . . .
> . . . *.*
> number of bytes is 49
>
> arb2x bijective adaptive arithemtic 2 symbols bit based
> arb2x in.tmp out.tmp
> so your data not good for arb2x
> 0000 E7 62 40 6B 38 70 1E 22 CA 8C BF C7 E2 C2 02 53
> *.b@k8p.".......S* 0010 A9 44 8F 54 BC A2 E9 18 8B A7 78 AA E8 A4 4A
> 21 *.D.T......x...J!* 0020 50 C2 2C 1D 6C 74 31 94 63 AC 42 5B BA DD
> 70 . *P.,.lt1.c.B[..p*
> number of bytes is 47
>
> lzw3a this is a 2 root bijective LZW compressor
> the optiom -c is for compression -d for decompression
> lzw3a -c in.tmp out.tmp
> So your data not good for lzw3a
> 0000 F5 10 52 78 14 82 8B 27 EB 83 4D 0A EB 39 D9 B6
> *..Rx...'..M..9..* 0010 40 02 92 3E F4 81 1A 7E DE 32 81 D7 7B E8 DA
> B9 *@..>...~.2..{...* 0020 C2 1C 13 BC 0A 55 1E A1 DF 44 45 BB 0B 6B
> 1E AD *.....U...DE..k..* 0030 5D C0 . . . . . . . . . . .
> . . . *].*
> number of bytes is 50
>
>
> So without a custom model of your data built in. I think it is
> safe to say none of my compressor would compress to the level
> you want. In fact it looks like your test case results in
> expansion.
>
> David A. Scott
To get an idea on the limits of compression I took
a few of my compresses and used file of both all ones
and all zeros. Even a sligh deviation is going to
increase the length a lot. If you data is random you
can't really compress.
Just to see what happens in limit I tested a
few of my bijective file compressors with 46 bytes of zero
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . . *..............*
number of bytes is 46
this is output from arb2x
0000 9E 88 . . . . . . . . . . . . . . *..*
number of bytes is 2
this is output from lzw3s
0000 87 1F F0 D7 96 F0 65 97 DD A9 CA 40 . . . . *......e....@*
number of bytes is 12
This is output from h2com
0000 FF FF FF FF FF FF F8 . . . . . . . . . *.......*
number of bytes is 7
This is output from arb255
0000 E0 2C 30 99 A0 5B C0 . . . . . . . . . *.,0..[.*
number of bytes is 7
Then I tried it with all ones using file below
0000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF *................*
0010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF *................*
0020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF . . *..............*
number of bytes is 46
This is output from arb2x
0000 1E 98 . . . . . . . . . . . . . . *..*
number of bytes is 2
This if output from lzw3s
0000 60 BC 6F 9F ED 40 0B AF 7B D3 1E . . . . . *`.o..@..{..*
number of bytes is 11
This is output from h2com
0000 00 FF FF FF FF FF F8 . . . . . . . . . *.......*
number of bytes is 7
This is output from arb255
0000 1F 2C 30 99 A0 5B 40 . . . . . . . . . *.,0..[@*
number of bytes is 7
Note arb2x is only two states. The lenght of output
is a function the number of bits input and the ratio
of ones to zeros.
lzw3s starts out with with two states each one bit long
either a zero or a one. As each state is output it is
replaced in an obscure way with two different bit strings
each string being one bit longer that the one replaced.
The whole thing though is bijective.
h2com is 256 state adaptive bijective huffman file
compressor. In the examples the fist 8 bytes from
the first 8 bits in file. Then a one is used from
the repeats so not much room for play here.
arb255 is the 256 state arithmetic bijective file
compressor. It looks simalar in compression to the huffman
but dpending on how you handle the zero frequency
question for this example you could make it compress
much smaller than the huffman or not as well as the huffman.
In this example the huffman used one bit for each occurance
of the string of input bytes. That is the best it can do.
The arithmetic started with a lot longer length for the
repeated character and ended up using far less that a bit for
repeated bytes when near the end. Yet nothing is for free to
write the last token costs an extra 6 bits in these examples.
The bit compressor had its 2 state cell hit 8 times more than
the cells in arb255 so it cost 8 bits for the ending token
in arb2x.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| arniewang 2005-04-17, 3:56 am |
| I think it is not easy to say. there are at least 96Bits that can be
compressed to some degree, but I am not sure how much it can be
compressed.
| |
| arniewang 2005-04-17, 3:56 am |
| Can I combine for example 10 frames sequently then send out one frame
one time, on the other side I decompress it. I mean sequently.
may be it is better than only 1 frame compress.
by the way, scott will you give me idea what you have modified your
code?
| |
| arniewang 2005-04-17, 3:56 am |
| I mean stream compressing. will it work for this sequency of frame?
| |
| Ian Littman 2005-04-17, 3:56 am |
| If this isn't too stupid, can you simply compress multiple frames and
send them. It's just that there are lots of headers on compression
formats and the only way you can make such small stuff smaller is to
overcome the limiting factor of headers and pointers, either by vastly
shrinking or eliminating them (probably can't) or by compressing larger
amounts of data (diluting the headrs).
| |
| David A. Scott 2005-04-17, 3:56 am |
| "arniewang" <arniewang@yahoo.com.cn> wrote in
news:1113707308.881532.132060@l41g2000cwc.googlegroups.com:
> Can I combine for example 10 frames sequently then send out one frame
> one time, on the other side I decompress it. I mean sequently.
> may be it is better than only 1 frame compress.
>
If the data is almost the same between frames I
suspose you could. I don't really know anything about your
data.
> by the way, scott will you give me idea what you have modified your
> code?
>
I am not sure what you are asking. But since you have seem my
site. The source code is all there.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| David A. Scott 2005-04-17, 3:56 am |
| "arniewang" <arniewang@yahoo.com.cn> wrote in
news:1113709753.832161.300630@o13g2000cwo.googlegroups.com:
> I mean stream compressing. will it work for this sequency of frame?
>
I can't say for sure. But I am sure it will take a lot of modifying.
If the data in each frame looks as bad as sample frame and if the
data in frames unrelated you not going to get it compressed.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| arniewang 2005-04-17, 3:56 am |
| It is a real time app so I can not wait 10 frames and then compress it
and sended it out. but I am considering send it out in stream.
If I lose one of the 10 compressed frame then I will lose many of them,
so It is not very good.
| |
| arniewang 2005-04-17, 3:56 am |
| I have downloaded all the source code on you site. thank you, It
will take me some time to read it.
I mean if I want to use your code in my current data sample should
I modified some of your code? for example bit based compress or sequent
compress like stream video.
thank you.
| |
| David A. Scott 2005-04-17, 3:56 am |
| "arniewang" <arniewang@yahoo.com.cn> wrote in
news:1113714891.805185.28890@f14g2000cwb.googlegroups.com:
>
> I have downloaded all the source code on you site. thank you, It
> will take me some time to read it.
> I mean if I want to use your code in my current data sample should
> I modified some of your code? for example bit based compress or sequent
> compress like stream video.
>
>
The code is just of thoughts that interest me. I don't make any
promises. I really don't think it will help you that much it was meant
to be more of a learning tool. Not to many people interested in
my bijective type of compression. And your data seems to ramdom to
be compressed.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| David A. Scott 2005-04-17, 3:56 am |
| "arniewang" <arniewang@yahoo.com.cn> wrote in
news:1113714700.384452.152440@l41g2000cwc.googlegroups.com:
> It is a real time app so I can not wait 10 frames and then compress it
> and sended it out. but I am considering send it out in stream.
> If I lose one of the 10 compressed frame then I will lose many of them,
> so It is not very good.
>
My code at least the way I coded it. Is very slow. I am more interested
in doing interesting compression. But I am not that interested in speed.
I still don't think your going to get that much compression for what you
want.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
| |
| arniewang 2005-04-17, 8:55 am |
| In fact I think Compress ration is the first thing I am considering.
| |
| Tim Arheit 2005-04-19, 3:55 pm |
| On 17 Apr 2005 01:48:08 -0700, "arniewang" <arniewang@yahoo.com.cn>
wrote:
> Can I compress 45Bytes to 37Bytes?
> In fact I think Compress ration is the first thing I am considering.
>
It depends on what the 45 bytes are.
-Tim
| |
| bybell@rocketmail.com 2005-04-19, 3:55 pm |
| David A. Scott wrote:
> If the data is almost the same between frames I
> suspose you could. I don't really know anything about your
> data.
The thread originator talks about not being able to bundle up frames
into a stream and emit them as a larger superframe because the
potential for losing a whole compressed group of them at once is
unacceptable, but what's the MTU of his transmission medium? How much
data could it lose? What protocols (if any) are involved? What is the
time delta between consecutive frames? What data are contained in the
frame?
There's also the aspect that if he compresses data and it's corrupted,
how is he going to resync to the next uncorrupted set of data? With an
unreliable transmission medium, he'd have to build in synchronization
information (e.g., some header matchbit pattern) which would eat into
his compression ratio. Then he'd have to ensure that the next frame
correctly decompresses to 45 bytes, etc, and that he's back on track.
It doesn't sound like there is enough information to point him in the
right direction as there are too many unknowns. If he is however using
something like ethernet as a transmission medium, he could pack
together enough compressed frames to fill out an MTU. *shrugs*
-t
| |
| arniewang 2005-04-21, 3:55 pm |
| en it is not easy, I think many compress method are optimized for long
data compessing, isnot it true?
| |
| David A. Scott 2005-04-21, 3:55 pm |
| NNTP-Posting-Host: 7oYuLlwxk4LYJ3+kZQVn4w.domitilla.aioe.org
X-Complaints-To: abuse@aioe.org
NNTP-Posting-Date: Thu, 21 Apr 2005 17:02:59 +0000 (UTC)
User-Agent: Xnews/5.04.25
X-Face: *M,`iYi}2A#%e&7.vp<8f81-*udLB9<ppLF"bWcmt1_Z61X/9NPK/$nTz3[j\yWuLXM>nixvZ`=}%']'>qG%|M$ic5V6oey="NWI!LE.V|>|xmrCcP)w
Xref: number1.nntp.dca.giganews.com comp.compression:64259
"arniewang" <arniewang@yahoo.com.cn> wrote in
news:1114100928.926341.190170@l41g2000cwc.googlegroups.com:
> en it is not easy, I think many compress method are optimized for long
> data compessing, isnot it true?
>
>
Yes since most methods tend to handle large amounts of
data and small amounts they tend to use a fixed amount of
overhead to keep the code simple. Most tests are done on
large amounts of data. But if your data is somewhat random
without a good model to narrow the cases. It will expand when
you compress even for very long files.
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
|
|
|
|