Mail Archives: djgpp/1996/11/10/19:37:35
> > archives then I can throw together a good archiver for the job in
> > less than a week. It would not be as fast as pkzip, but should get
> > significantly better ratios without too much more time. Is there any
> > interest in this?
> Would you use the Deflate algorithm or one from RKIVE?
No, I was thinking of an algorithm similar to one used in an earlier
version of RKIVE but optimised for speed and using less memory.
> I think Deflate
> is good enough and with some improvements (bigger dictionary, treating
> ALL files as one stream of data without clearing the dictionary every
> time new file is read, sorting files by type - i.e. extension, creating
> a complete histogram before compressing) it would give much better
> results tan either ZIP or PKZIP.
Just increasing the dictionary isn't a great improvement. On most
files it'll hurt compression (that's why 64K or 32K dictionaries are
generally the largest that older LZ archivers had) you'd have to at
least raise the minimum match length for the larger offsets.
Having said this I think a completely new algorithm would be called
for. PKzip uses huffman coding on everything, but arithmetic is
better (slower though) for example.
> I think it is important to stay at the
> ZIP file format so that all the tools still work with it. This, of
> course, wouldn't increase compression ratio as much as a completely new
> archiver, but still it'd better than the old, good ZIP.
I don't think it would be possible to stay with the zip format. Just
going to solid mode compression (all files in one stream) would break
it anyway.
Malcolm
- Raw text -