f



Problem implementing STAC

Hi!  I've been trying to implement my own version of the Stac compression t=
echnique and am running into a problem: a poor compression ratio.  I use th=
e resource "https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Stac" =
and know about the encoding of LZ distance and length codes and the literal=
 encoding.  Am I missing something?  :(

BTW, my code follows:
-----------------------------
		cin=3D&InBuffer[vz.InPos];
		//if (HuffEnv.entrynum[*cin]<0 || HuffEnv.entrynum[cin[1]]<0 || HuffEnv.e=
ntrynum[cin[2]]<0) {
		//	CompBin01U (); ++vz.InPos; continue;
		//}
		lenc=3DGetLZW (vz.InPos);
		if (lenc && GetLZW (vz.InPos+1)<=3Dlenc+0 /*&& GetLZW (vz.InPos+2)<=3Dlen=
c+0*/) {
		//if (lenc && GetLZW (vz.InPos+1)>lenc+0 && GetLZW (vz.InPos+2)>lenc+0) {
			//++techLZW.pos;
prints ("lenc=3D"); printu (lenc); printcr();
			techLZW.pos=3Dcin-techLZW.pos;
			writeoutf_11 ();
			if (techLZW.pos<128) {
printscr ("Pos<128");
				writeoutf_11 ();
				writeoutf (techLZW.pos, 7);
			} else {
printscr ("Pos>=3D128");
				writeoutf_01 ();
				writeoutf (techLZW.pos, 11);
			}
			if (lenc<5) {
				writeoutf (lenc-2, 2);
			} else if (lenc<8) {
				writeoutf (lenc-5+4, 4);
			} else  {
				j4=3D(lenc+7)/15;
				j3=3D-(j4*15)-7;
prints ("Large Len.: "); printu (lenc); printc (','); printu (j4); printcr =
();
				while (j4--) writeoutf (15,4);
				writeoutf (j3, 4);
			}
		=09
			vz.InPos+=3Dlenc;
			continue;
		}
		writeoutf_01 (); writeoutf (*cin, 8);
--------------------------
Where lenc is the returned length of an LZ match, vz.InPos is the current p=
os., writeoutf() writes a value to the output of the length specified by th=
e second parameter, GetLZW() gets the LZ info, and print*() prints informat=
ion to the screen.
0
Harry
9/27/2016 12:43:53 PM
comp.compression 4696 articles. 0 followers. Post Follow

6 Replies
70 Views

Similar Articles

[PageSpeed] 51

I am wondering how Stacker does so good at compressing drives when the technique it uses is so poor.  :/  Again, am I missing something?  Again, something *must* be missing.  :(
0
Harry
9/29/2016 11:04:13 PM
On Friday, 30 September 2016 07:04:14 UTC+8, Harry Potter  wrote:
> I am wondering how Stacker does so good at compressing drives when the technique it uses is so poor.  :/  Again, am I missing something?  Again, something *must* be missing.  :(

Are you sure practically it is that good ? I were only able to get about 25% extra space for practical uses, not another 100% as advertised. Same for DriveSpace or DoubleSpace
0
Fibonacci
10/2/2016 9:39:26 AM
On Sunday, October 2, 2016 at 5:39:27 AM UTC-4, Fibonacci Code wrote:
> On Friday, 30 September 2016 07:04:14 UTC+8, Harry Potter  wrote:
> > I am wondering how Stacker does so good at compressing drives when the technique it uses is so poor.  :/  Again, am I missing something?  Again, something *must* be missing.  :(
> 
> Are you sure practically it is that good ? I were only able to get about 25% extra space for practical uses, not another 100% as advertised. Same for DriveSpace or DoubleSpace

I found the problem: according to Stacker's docs. the technique was updated after the documentation I have.

BTW, you're right.  Compression varies and can only do so much.  :(
0
Harry
10/2/2016 8:44:35 PM
On Sunday, October 2, 2016 at 3:44:42 PM UTC-5, Harry Potter wrote:
> I found the problem: according to Stacker's docs. the technique was updated after the documentation I have.

STAC was never that great.  The only reason it was acceptable is because it was fast, and in version 3.x and later, had an offline optimal parsing option in a disk utility you could use to gain slightly more compression.

Why are you implementing STAC?  LZ4 is much better in all areas and has freely-available information and source code.
0
Jim
10/10/2016 8:22:18 PM
On Monday, October 10, 2016 at 4:22:24 PM UTC-4, Jim Leonard wrote:
> STAC was never that great.  The only reason it was acceptable is because it was fast, and in version 3.x and later, had an offline optimal parsing option in a disk utility you could use to gain slightly more compression.
> 
> Why are you implementing STAC?  LZ4 is much better in all areas and has freely-available information and source code.

I thank you for your input.  I'll look into it now.  :)
0
Harry
10/11/2016 11:16:35 AM
On Tuesday, October 11, 2016 at 7:16:36 AM UTC-4, Harry Potter wrote:
> I thank you for your input.  I'll look into it now.  :)

I looked into it.  The docs. said that LZ4 was worse than LZO, and LZO worse than Deflate.  :(  
0
Harry
10/11/2016 9:58:15 PM
Reply: