So the naming of ZipCreator is kinda incorrect as it can also deflate? (Haven't checked the code yet.. no VB @ work) :p
Printable View
So the naming of ZipCreator is kinda incorrect as it can also deflate? (Haven't checked the code yet.. no VB @ work) :p
Deflate is compression, Inflate is decompression.
The deflate code is pretty poorly coded, even with some simple math changes you can speed it up a lot. Don't know if I bother to do it... already a lot of things going on.
rm_03, I keep getting oveflow errors when trying to use your program, even on 4 kb files.
Run it in the IDE and tell me where the overflow occurs.
ehh.. yeh Inflate.. - Kinda got 'm mixed up there.
I just wish to add my two cents about language and their capacity (I didn't rapidely find a link in the chit chat forum) and share my knowledge about that.
If a language have theses 3 simple things:
1- register like variable (like the long format for the 32 bits)
2- the "goto" instruction
3- the "if" instruction
then you can code anything that come within the time/space complexity of current architecture of software hence the zip format.
Of course some languages are more suited for such requirement like C/C++ that handle low level byte more easily than vb (in my point of view) but in the end either can do it.
If a turing machine can do it. Vb / C/C++ / Cobol / Java to name a few can do it. Absolutely. It's only a matter of preferences and skills.
Sorry if I have bothered you I couldn't just let it go like that.
Yeah VB Can do it but very slowly! C++ is always the better choice but who wants to build binary trees and go about understanding the huffman algorithm anyway? We got winrar / winzip so wat the hell with creating a zip extractor that takes 2 minutes to compress/decompress a file!
I think you get overflow errors when you only try to add one file to the zip file.
Little bug in the percent calc.
Where can i get the jpeg compression in vb?
http://pscode.com/vb/scripts/ShowCod...50065&lngWId=1Quote:
Originally Posted by shragel
1) Huffman compression isn't that hard to understand. Theres some good sites out there that explain it well (if they are still around).Quote:
Originally Posted by RapchikProgrammer
2) Why not? Who cares if it takes longer, at least you've learnt something from it..
chem
Erm, I wouldn't agree to this either. A JPEG is yes, compressed in a way. The code that you are referring to, doesn't "decompress", it instead just loads the JPEG data. If you understand how a JPEG is compressed, it looses its quality. Kinda hard to explain, but I'm sure you get my point.Quote:
Originally Posted by RapchikProgrammer
chem
I find some of the posts here re-argues the same point over and over. Can we talk about something more constructive? Like what rm_03 did?
Agreed, some people just don't read the whole thread when they make their own statement and we end up talking the same points over and over again.
On the actual topic, I dared to take a quick minor optimization round to the deflate module and I tuned it up by about 10% - the code algorithm structure needs a complete rewrite if anyone wished for a better speed. However, there were many flawed ways to use variables and in-built functions. Here are a few common ones:
- incorrect datatypes matched against each other -> datatype coercion
- use of Variant arrays
- Fix(Number / Value) instead of Number \ Value - the latter is many times faster
- pointing to same array item multiple times within the same line instead of storing it to a variable
- using * when + could be used for faster math (ie. Number * 2 -> Number + Number)
- initializing static values to variables instead of constants with heavy math (such as Variable = 2 ^ 30)
So yeah, it has a lot of room for improvement.
Merri...I wonder if you wrote any programming books?
Nope. I'm "only" a hobbyist programmer.
Zip uses an algorithm called Deflate to do compression. It does the compression in two steps. The first part (LZ77) should be fairly simple. As it goes along it checks for previous copies of the current data, and if there aren't copies, it produces a literal representation of the data, and if it finds past copies it puts an offset/length pair to the previous copy instead of a literal representation of the data. The second step is huffman compression, which finds which are the most common symbols, and then the more common symbols get shorter bit lengths (so now some symbols will be less than one byte long, which means the data is now being handled at the bit level, not the byte level, and this can get VERY VERY VERY tricky in raw VB code, and so far I've never been able to write a successful huffman algorithm in VB6). So while it should theoretically be possible, the writing of the compression algorithm may very well take up the majority of the time you are spending on writing your program. Not to mention a raw VB6 implementation of the compression algorithm will likely run VERY VERY VERY slowly (due to the complexity of the algorithm, and the fact that VB6 runs MUCH slower than C++, Pascal, Delphi, and 99% of the other programming languages out there).
I'd like to add my 2 cents here, even though this is not Zip compression (deflate....lz77/huffman).
It encodes into huffman code, but my tree is not optimized so it will not compress at it's best but it compresses a lot already.
Also it will not write to file but if you take a quick look at text3.text (once click on Show Binary) this would be what would be in a file (to be read), the only thing missing is the header with how many extra 0 (bits) there is at the end, file length and the characters in order (from the most frequent to less frequent).
Although winzip uses LZ77 (which should be easier than huffman) and huffman, I'm sure their tree is created different, but the point here is that it can be done, I have shown you huffman code (without the proper tree format) but it is still huffman (compression) code.
It is not hard to make, but a bit harder to make it fast like winzip.
Here is the project. I will update it whenever I can.
Didn't check your project, just a hint - do you know this one?
http://www.shadoware.de/files/vb/compression_src.zip
Wolfgang
I know it's an old thread but just to let everyone know about this project I just completed: A single-class pure VB6 library for zip
The single `cZipArchive` class in `src` uses bytecode thunks (not ASM, but compiled from C source code) for deflate/inflate and CRC32 calculation so the speed is there and it has no external DLLs dependency.
cheers,
</wqw>