seems like the second file is already compressed ...
I also figured out why I was having problems ... when encoding the 3.3gb file, the variable would overflow and start from beginning ...
Printable View
seems like the second file is already compressed ...
I also figured out why I was having problems ... when encoding the 3.3gb file, the variable would overflow and start from beginning ...
In that test, the 2nd file is indeed already compressed, essentially an executable zip file.Quote:
Originally Posted by slavik
And we've all done the int instead of long in a loop thing at some point ;)
..sooo
i need to run it on a non-compressed file ?
i eluded to the knoppix 4.0.2 DVD (ISO) as already being compressed as well - i got no response about it, so i presumed it doesn't matter....i mean if klaus knoppix could release a 128MB CD. instead of a 3.3GB DVD, don't you think he would've already ?
i also tried it on a 950MB+ Nero .NRG file (Image) - and it just hung there "reading contents" - though admittedly, i didn't wait very long.
what ? for ISO files only ?
and why don't i see any other results from fellow sharks ?
What? And take time away from gaming?Quote:
Originally Posted by I4one
Note that ISO files (and NRG) are more of a format spec than having anything to do with compression.
Some Linux distros will release CDs full of .tar (no compression) or .rpm (modest compression sometimes). Those that include lots of gzipped files will compress much less. I'm not familiar with Knoppix, so can't say where they fall in the range.
well, the thing is that long int are same size as int ... at least on my system with mingw ...
I am working on code to calculate everything properly ... also, for a 3.3GB ISO it took my system about 10 minutes ... and 1 min for a 614MB ISO image ...
the reason why it's a bad idea to run it on a compressed file is that usually, you cannot compress the file any better anyway ... so find some large install file or something ...
'Cuz it's an exe, and therefore I'd have to reboot into Windows to make it work. ;)Quote:
Originally Posted by I4one
Slavik, http://developer.apple.com/documenta...Long-Long.html
Think that'll be big enough?
I'll give it a try after my current run goes through ...
alright - the last guinea pig entry for awhile
like i said - this file was already compressed on the Knoppix 3.6 CD-R...as any knoppix ISO 4.0.2 DVD will surely contain many "compressed" files...perhaps the jump from CD (700+MB) to DVD (3300MB) allowed him to keep the least used apps (or extra stuff) only to remain highly compressed - (up to a total of over 8.0GB of data on the DVD). I copied this 725MB file back over to desktop from CD to run this testCode:C:\WINDOWS\Desktop>huffman.exe C:\windows\desktop\knoppix\knoppix
Reading C:\windows\desktop\knoppix\knoppix
File size = 725253780 bytes
Encoded size = 188382868 bytes
Compression ratio = 25.9748% ((encoded file size)/(original file size))*100%
Space Saved = 536870912 bytes
C:\WINDOWS\Desktop>
nice ... once I can get it to compute the encoded size properly, I will start working on releasing the program in 3 versions ...
1 to compress, 1 to decompress and 1 to analyze ... eventually I will merge them into 1 and then allow command line options (-c, -d, -a)
EDIT: Good news ... thanks to Candyman, the calculation works properly :) you can go to the site and redownload the program ... now it should read everything properly ...
EDIT2: I was thinking ... to avoid the problems of int ... to implement my own "wrapper" classes so that I do not have to rely on the basic data type, exept for char and pointers to char and my "custom" classes.