What's in your zipmax.ini file?

[krick]

These are the settings that I normally use in my zipmax.ini file. Anyone want to share something different that they've had success with?...

[ZIPMAX]

work-recursive = 1
skip-internzip = 0
logfile = 1
thread-priority = normal
nobeep = 0
setcurrenttime = 1
showpackerwindow = 0

packer-exe-1 = 7za.exe
packer-cmd-1 = a -mpass=4 -mfb=255 -r -y -tzip %1 %2

packer-exe-2 = 7za.exe
packer-cmd-2 = a -mx -mpass=4 -r -y -tzip %1 %2

packer-exe-3 = C:\Program Files\WinZip\wzzip.exe
packer-cmd-3 = -a -ex -rp -whs -ybc %1 %2

packer-exe-4 = bjwflate.exe
packer-cmd-4 = -a -r -y %1 %2

packer-exe-5 = bjwflate.exe
packer-cmd-5 = -n -a -r -y %1 %2

// I still haven't tried the two below. As it is, running the above can take
// forever on a large file on my otherwise capable system (P4 3GHz & 2GB memory).
// I can't imagine how slow these would be...

// 7-zip extreme settings (-mfb=258 -mpass=32) [requires custom 7za compile]
// packer-exe-6 = 7za_custom.exe
// packer-cmd-6 = a -mpass=32 -mfb=258 -r -y -tzip %1 %2

// bjwflate extreme settings (-s8192)
// packer-exe-7 = bjwflate.exe
// packer-cmd-7 = -a -r -s8192 -y %1 %2

finalstep-exe = deflopt.exe
finalstep-cmd = %1

[MonitorGuru]

Preface: I'm anal and want the most bits compressed and do not care about computer time.  I have 2 3.2 HT Dual proc machines at work, a 3.0 HT at home, and a 1.8 Centrino at work, as well as a few ~1 GHZ other machines at home.

I also added stuff to ZipMax to allow you to distribute it over multiple machines, all fed from the same network share of files and neither duplicates the effort of the other.  I did this nearly a year ago and sent it to Roman , including new source code and read me files and he has not updated it unfortunately  So for now, I'm the only one distributing it across machines automatically.


Next, I run stuff through 4 passes (4 separate launches with different INI files) right now.  I could compress this to 2, but have broken out the BJWFlate stuff which is agonizingly slow so I can do a quick compress, then run those slower ones later as I free up computer time.

Finally the last pass is to handle the compressing programs out there that do not work with long file names correctly.  However, they still can sometimes produce a smaller image, but will simply fail on the LFN stuff.  If you try to include these compressors with the main run, then you will end up having to redo the failed files, and it still eats up all the time.  Its better to handle the LFN failures LAST than first.  

That said, here are my 4 INI files, in order of how I compress.   I contend I have pretty much the smallest zips possible, within some sane amount of reason ( I think it took about 30 days across 3, 3 GHZ machines, to rezip EVERY file in Mame .79.  Now incremental changes only take about 2 days for each release for computer power)


Here is how i laid out my directories:
----------------------------------------------
 Directory of C:\zm\1-LFN
12/09/2003  01:19 PM           471,552 7za.exe
12/15/2003  12:00 PM            30,208 DeflOpt.exe
10/15/2003  08:05 PM           235,008 PACOMP.EXE
01/16/2004  07:12 PM           339,456 PKZIP25.EXE
11/01/2000  04:00 AM           258,048 pkzipc.exe
01/30/2004  09:26 AM           409,600 ZipMax.exe
07/04/2004  10:30 AM             4,271 zipmax.ini

 Directory of C:\zm\2-BJW64
09/14/2003  12:00 PM            39,936 BJWFlate.exe
12/15/2003  12:00 PM            30,208 DeflOpt.exe
01/30/2004  09:26 AM           409,600 ZipMax.exe
07/04/2004  10:48 AM               769 zipmax.ini

 Directory of C:\zm\3-BJW8K
09/14/2003  12:00 PM            39,936 BJWFlate.exe
12/15/2003  12:00 PM            30,208 DeflOpt.exe
01/30/2004  09:26 AM           409,600 ZipMax.exe
07/04/2004  10:48 AM               771 zipmax.ini

 Directory of C:\zm\4-SFN
12/15/2003  12:00 PM            30,208 DeflOpt.exe
02/01/1993  02:04 AM            42,166 pkzip.exe
03/01/1999  02:50 AM            50,663 PKZIP250.EXE
01/30/2004  09:26 AM           409,600 ZipMax.exe
07/04/2004  10:37 AM             1,737 zipmax.ini


First run:
// ---------------------------------------------
// All Zippers handle Long File Names correctly.
// Does NOT include slow BJWFLATE zipping.
// ---------------------------------------------
[ZIPMAX]
work-recursive = 1
skip-internzip = 0
logfile = 1
thread-priority = normal

nobeep = 0
setcurrenttime = 0
showpackerwindow = 0
skipreadonly = 1
skiparchive = 1
setcurrentreadonly = 1

// ------------------------------------------------
// PKZIP25 (95/NT 1998) -lev=[0-9] 0 = uncompressed
// ------------------------------------------------
packer-exe-1 = pkzip25.exe
packer-cmd-1 = -add -level=1 -over=all -path=relative -rec %1 %2

packer-exe-2 = pkzip25.exe
packer-cmd-2 = -add -level=2 -over=all -path=relative -rec %1 %2

packer-exe-3 = pkzip25.exe
packer-cmd-3 = -add -level=3 -over=all -path=relative -rec %1 %2

packer-exe-4 = pkzip25.exe
packer-cmd-4 = -add -level=4 -over=all -path=relative -rec %1 %2

packer-exe-5 = pkzip25.exe
packer-cmd-5 = -add -level=5 -over=all -path=relative -rec %1 %2

packer-exe-6 = pkzip25.exe
packer-cmd-6 = -add -level=6 -over=all -path=relative -rec %1 %2

packer-exe-7 = pkzip25.exe
packer-cmd-7 = -add -level=7 -over=all -path=relative -rec %1 %2

packer-exe-8 = pkzip25.exe
packer-cmd-8 = -add -level=8 -over=all -path=relative -rec %1 %2

packer-exe-9 = pkzip25.exe
packer-cmd-9 = -add -level=9 -over=all -path=relative -rec %1 %2

packer-exe-10 = pkzip25.exe
packer-cmd-10 = -add -level=0 -over=all -path=relative -rec %1 %2


// -----------------------------------------------------
// PKZIP4.0 (WinCmdLine2000) -lev=[0-9] 0 = uncompressed
// -----------------------------------------------------
packer-exe-11 = pkzipc.exe
packer-cmd-11 = -add -level=1 -over=all -path=relative -rec %1 %2

packer-exe-12 = pkzipc.exe
packer-cmd-12 = -add -level=2 -over=all -path=relative -rec %1 %2

packer-exe-13 = pkzipc.exe
packer-cmd-13 = -add -level=3 -over=all -path=relative -rec %1 %2

packer-exe-14 = pkzipc.exe
packer-cmd-14 = -add -level=4 -over=all -path=relative -rec %1 %2

packer-exe-15 = pkzipc.exe
packer-cmd-15 = -add -level=5 -over=all -path=relative -rec %1 %2

packer-exe-16 = pkzipc.exe
packer-cmd-16 = -add -level=6 -over=all -path=relative -rec %1 %2

packer-exe-17 = pkzipc.exe
packer-cmd-17 = -add -level=7 -over=all -path=relative -rec %1 %2

packer-exe-18 = pkzipc.exe
packer-cmd-18 = -add -level=8 -over=all -path=relative -rec %1 %2

packer-exe-19 = pkzipc.exe
packer-cmd-19 = -add -level=9 -over=all -path=relative -rec %1 %2


// -----------------------------------------------
// PowerArchiver3.2 -c[0 1 2] (store, normal, max)
// -----------------------------------------------
packer-exe-20 = pacomp.exe
packer-cmd-20 = -a -r -p -c1 -w %1 %2

packer-exe-21 = pacomp.exe
packer-cmd-21 = -a -r -p -c2 -w %1 %2


// --------------------------------------------------------------------------------------
// 7ZIP -mx=[0 5 9] ; -mm=[Copy Deflate xDeflate64 xBZip2] ; -mfb=[32-255] ; -mpass=[1-4]
// --------------------------------------------------------------------------------------
packer-exe-22 = 7za.exe
packer-cmd-22 = a -mx=5 -mm=Deflate -r -y -tzip %1 %2

packer-exe-23 = 7za.exe
packer-cmd-23 = a -mx=9 -mm=Deflate -r -y -tzip %1 %2

packer-exe-24 = 7za.exe
packer-cmd-24 = a -mx=5 -mm=Deflate -mfb=32 -r -y -tzip %1 %2

packer-exe-25 = 7za.exe
packer-cmd-25 = a -mx=9 -mm=Deflate -mfb=32 -r -y -tzip %1 %2

packer-exe-26 = 7za.exe
packer-cmd-26 = a -mx=5 -mm=Deflate -mfb=255 -r -y -tzip %1 %2

packer-exe-27 = 7za.exe
packer-cmd-27 = a -mx=9 -mm=Deflate -mfb=255 -r -y -tzip %1 %2

packer-exe-28 = 7za.exe
packer-cmd-28 = a -mx=5 -mm=Deflate -mpass=4 -mfb=32 -r -y -tzip %1 %2

packer-exe-29 = 7za.exe
packer-cmd-29 = a -mx=9 -mm=Deflate -mpass=4 -mfb=32 -r -y -tzip %1 %2

packer-exe-30 = 7za.exe
packer-cmd-30 = a -mx=5 -mm=Deflate -mpass=4 -mfb=255 -r -y -tzip %1 %2

packer-exe-31 = 7za.exe
packer-cmd-31 = a -mx=9 -mm=Deflate -mpass=4 -mfb=255 -r -y -tzip %1 %2

packer-exe-32 = 7za.exe
packer-cmd-32 = a -mx -mm=Deflate -mpass=4 -r -y -tzip %1 %2


// -----------------
// Deflate Optimizer
// -----------------
finalstep-exe = deflopt.exe
finalstep-cmd = %1




Second run:
// ------------------------------------------------------
// All Zippers handle Long File Names correctly.
// Only does slow BJWFlate
// Internal zipping and NONE level compression is skipped
// (assumes LFN was used where this is done.)
// ------------------------------------------------------
[ZIPMAX]
work-recursive = 1
skip-internzip = 1
logfile = 1
thread-priority = normal

nobeep = 0
setcurrenttime = 0
showpackerwindow = 1
skipreadonly = 1
skiparchive = 1
setcurrentreadonly = 1


// -------------------
// BJWFlate -s[3-8192]
// -------------------
packer-exe-1 = bjwflate.exe
packer-cmd-1 = -a -n -s64 -r -y %1 %2


// -----------------
// Deflate Optimizer
// -----------------
finalstep-exe = deflopt.exe
finalstep-cmd = %1



Third run:
// ------------------------------------------------------
// All Zippers handle Long File Names correctly.
// Only does slow BJWFlate
// Internal zipping and NONE level compression is skipped
// (assumes LFN was used where this is done.)
// ------------------------------------------------------
[ZIPMAX]
work-recursive = 1
skip-internzip = 1
logfile = 1
thread-priority = normal

nobeep = 0
setcurrenttime = 0
showpackerwindow = 1
skipreadonly = 1
skiparchive = 1
setcurrentreadonly = 1


// -------------------
// BJWFlate -s[3-8192]
// -------------------
packer-exe-1 = bjwflate.exe
packer-cmd-1 = -a -n -s8192 -r -y %1 %2


// -----------------
// Deflate Optimizer
// -----------------
finalstep-exe = deflopt.exe
finalstep-cmd = %1



Fourth Run:
// ------------------------------------------------------
// All Zippers do NOT handle Long File Names correctly.
// Does NOT include slow BJWFLATE zipping.
// Internal zipping and NONE level compression is skipped
// (assumes LFN was used where this is done.)
// ------------------------------------------------------
[ZIPMAX]
work-recursive = 1
skip-internzip = 1
logfile = 1
thread-priority = normal

nobeep = 0
setcurrenttime = 0
showpackerwindow = 0
skipreadonly = 1
skiparchive = 1
setcurrentreadonly = 1


// ---------------------------------------------------------------
// PKZip 204g (DOS) -e<x|n|f|s|0> max, norm, fast, superfast, none
// ---------------------------------------------------------------
packer-exe-1 = pkzip.exe
packer-cmd-1 = -a -ex -rp -whs %1 %2.*

packer-exe-2 = pkzip.exe
packer-cmd-2 = -a -en -rp -whs %1 %2.*

packer-exe-3 = pkzip.exe
packer-cmd-3 = -a -ef -rp -whs %1 %2.*

packer-exe-4 = pkzip.exe
packer-cmd-4 = -a -es -rp -whs %1 %2.*

// --------------------------------------------------------------------------------
// PKZip 2.50 (DOS 1999) -e<xx,x|n|f|s|0> exterme, max, norm, fast, superfast, none
// --------------------------------------------------------------------------------
packer-exe-5 = pkzip250.exe
packer-cmd-5 = -a -exx -rp -whs %1 %2.*

packer-exe-6 = pkzip250.exe
packer-cmd-6 = -a -ex -rp -whs %1 %2.*

packer-exe-7 = pkzip250.exe
packer-cmd-7 = -a -en -rp -whs %1 %2.*

packer-exe-8 = pkzip250.exe
packer-cmd-8 = -a -ef -rp -whs %1 %2.*

packer-exe-9 = pkzip250.exe
packer-cmd-9 = -a -es -rp -whs %1 %2.*


// -----------------
// Deflate Optimizer
// -----------------
finalstep-exe = deflopt.exe
finalstep-cmd = %1





Note: These settings:
skipreadonly = 1
skiparchive = 1
setcurrentreadonly = 1


Have no effect on the released build of ZipMax. They are my multi-machine concurrent recompressing enhancements that have not been updated by Roman.   You can have them in your files but they do absolutely nothing to the current public ZipMax build.


Let me know if you have any questions / comments about my analness / etc...  If you want the best bang for your buck, combine the compressor from my run #2 into #1, and do not do run #3 (8192 BJWFlate) as it is obscenely LONG.    Then do my run #4 as your second run to handle the long file name issued ones.

Again the issue is that you can run that set on all your zips, and it WILL recompress some of your roms/icons/etc.. smaller, BUT if there happens to be a long file name either in the zip name or a file in it, the compressor will fail and the file will be skipped.  Therefore you want to do it LAST and separately since it's highly likely it will skip most files that would have a problem anyway since they'd have been compressed by a better ratio in the first pass anyway, with programs that can handle the long file names.

Hope this helps!

[MonitorGuru]

Oh yeah, also, I only do 8192 level BJWFlate on .zip's that are SMALLER than 1 Meg in size.  I would never think of using it on anything larger than that, as it can take almost 8 hours on a single file around 1 meg, depending on how large the files inside it are. (256K and bigger internal files make it take much longer)  Thats another reason I separated it from the rest of the runs.

[krick]

I think it took about 30 days across 3, 3 GHZ machines, to rezip EVERY file in Mame .79.  Now incremental changes only take about 2 days for each release for computer power

Wow.  This is exactly the kind of response I was looking for.

Mine took several weeks to complete as well.  Then I learned more about some of the compressors and went back and did it all again.

I'm in the middle of compressing everything using the most extreme 7Zip and BJWFlate options.  I sorted by size first (small to large) before dragging and dropping them onto ZipMax. That way, the smallest files get done and out of the way quickest in case I need to stop and restart it later.    It's been going since last night and it's supposedly 22% complete.


I haven't really experimented that much with running so many variations of each compressor.

Have you seen the BJWFlate docs that I dug up for Roman?...
http://www.clrmame.com/bjwflate.htm

I've been using these settings on BJWFlate...   -n -a -r -y %1 %2
Takes FOREVER but it does seem to squeeze out a little more.

According to the DeflOpt docs, there is no point in running it after BJWFlate compression as the technique that it uses is already incorporated into BJWFlate.


I have another INI file that has more compressors too.

I have problems with PKZIP 2.04g. I think it's the long filename thing you mention.
The other weirdness is that it always changes everything to upper case.  Luckily, ClrMame detects case problems and fixes them.

Here's the other compressors I have...

7za_custom.exe - 7zip custom build as per Ben Jos Walbeehm's instructions
to allow maximum compression settings:  -mfb=258 -mpass=32
http://3feetunder.com/files/7za_custom.exe  (exe only)

pkzip.exe - PKZip for DOS ver 2.04g
http://3feetunder.com/files/pkz204g.exe (full archive)

pkzip25.exe - PKZip for DOS ver 2.50
http://3feetunder.com/files/pkzip25.exe (exe only)

pkzipc.exe - PKZip for Windows Command Line ver 4.00
http://3feetunder.com/files/pkzipc.exe (exe only)

pacomp.exe - PowerArchiver Command Line (PACL) ver 3.20
http://3feetunder.com/files/pacl320.exe (full archive)

wzzip.exe - WinZip Command Line Support Add-On Version 1.0
This requires Winzip 8 SR1.  Both are included in this archive...
http://3feetunder.com/files/winzip81sr1.zip (full archive)

[MonitorGuru]

Good, I'm not the only anal compressor!   Ah, so you're the one that found the BJW stuff in the wayback machine.  I had searched for a lot of it right after he pulled his pages in whatever tiff he had with someone/something, but never found it, but didnt go back later after things started appearing in archives.

For each of my settings, I've had at least 1 file actually compress smaller, so I'm not just throwing settings that are duplicated.  However of course it depends on the order you have them done in, as if you do 8192 BJW, then most of the old compressors won't pick up much more compression, but of course some will.

So is the settings you use on BJWFlate basically 8192 partitions or is it somethng else? I havn't read the docs yet.

Running DeflOpt barely takes any time, but I guess if I dont need it, I can safely remove it.

Yes, I drag and drop the files in the same order.. small to large.

Actually since I have the compilation changes to distribute, I send the small files to the remote network machines (10b/g network) that are notebooks and smaller drives, then send the larger files to the 3.0 HT machines that are wired and have 2 gig ram and hard drive (to handle the larger files best).   They eventually meet somewhere in the middle of the list when done.


You are correct.. the old PKZip programs not only cant handle LFNs, but they also can't handle mixed case.  Thats another reason I run them LAST since i know they will screw up the files yet again, and if run last, I wont ave to re-case as many, if any.  I really think I'm going to modify ZipMax source code to add in a flag that will never take the file name out of the new images, only out of the original, however I think i've lookedat the code, and unfortunately it may key a hash out of them in order to guarentee the correct file is used when rebuilding the new zip.  I'll look at it when I get time.

I will try out your -258 build.  I wonder if it always is better than all the other flavors of 7z I feed it.


Two bits to remember regarding 7zip and WinZip past 8.x  :  They now offer Deflate64 and BZip compression. However neither of these are supported by Mame or its variants.  Therefore if you use these, be sure you specify never to compress to these compression methods otherwise Mame will never be able to open your zips.

Also: If you use Mame32Plus, be aware they are using a horribly buggy build of an unzipper, and if you use BJWFlate and/or DeflOpt, even though the zips are valid, Mame32 will complain that it can't read about half the files in every rom zip if they've been touched by these programs.  I posted a message back in February to Mame32Plus's msg board and they admited the problem but never fixed it. I posted again last month and they said they'd fix it "in the next build", whatever that means.


I chose not to use Winzip8.x as I first had some shell problems with it not always starting, plus I think on preliminary tests i didnt get better compression from it, but could definitely rerun everything through it and see.

[krick]

For each of my settings, I've had at least 1 file actually compress smaller, so I'm not just throwing settings that are duplicated.  However of course it depends on the order you have them done in, as if you do 8192 BJW, then most of the old compressors won't pick up much more compression, but of course some will.

Amazingly, I find that the old DOS PKZIP still occasionally picks up a little now and then.

So is the settings you use on BJWFlate basically 8192 partitions or is it somethng else? I havn't read the docs yet.

I'm not sure.  He doesn't say.  He just calls it "number of splits".
I'm sure that the 8192 number has some signifigance in the deflate algorithm.  I'll see what I can find.

I will try out your -258 build.  I wonder if it always is better than all the other flavors of 7z I feed it.

Again, I'm not sure but here's what he says...

Try 7-Zip for instance using 32 passes and 258 fast bytes (-mfb=258 -mpass=32) and then compare its speed to BJWFlate's. And there are other programs too that are slower than BJWFlate when you use them with "extreme" settings. As for 7-Zip and using 32 passes and 258 fast bytes, yes, it requires compiling your own version of 7-Zip. Instructions on which changes to make to the source code of 7-Zip can be found further down on this page. If you wonder about the 258: Without getting into too much detail, more than 258 is useless since 258 is the maximum length possible for a reference to an earlier block of data in the Deflate format.

Two bits to remember regarding 7zip and WinZip past 8.x  :  They now offer Deflate64 and BZip compression. However neither of these are supported by Mame or its variants.  Therefore if you use these, be sure you specify never to compress to these compression methods otherwise Mame will never be able to open your zips.

I won't use Winzip 9 for just that reason.  I notice that you put "-mm=Deflate" in your 7Zip command line.  Is this necessary?  I've always left it out because I assumed that Deflate was the default.

Also: If you use Mame32Plus, be aware they are using a horribly buggy build of an unzipper, and if you use BJWFlate and/or DeflOpt, even though the zips are valid, Mame32 will complain that it can't read about half the files in every rom zip if they've been touched by these programs.  I posted a message back in February to Mame32Plus's msg board and they admited the problem but never fixed it. I posted again last month and they said they'd fix it "in the next build", whatever that means.

Not a concern. I don't use Mame32 or any of its variants.

I chose not to use Winzip8.x as I first had some shell problems with it not always starting, plus I think on preliminary tests i didnt get better compression from it, but could definitely rerun everything through it and see.

I've only occasionally had Winzip result in better compression but it seems to run pretty fast so I leave it in just in case.   I use the Command Line Support Add-On and I've had no problems getting it working.  The only thing is that I have to call it using the full path (C:\Program Files\WinZip\wzzip.exe) because it's not on my path.  You can't put wzzip.exe in the folder with ZipMax.  Or at least I haven't found a way.

[MonitorGuru]

If you use an old enough version of 7zip, before they added Deflate64/BZip support then you have nothing to worry about (it was circa 2002/2003).  However if you are using their more recent code or your special build is built on it, then you very well could end up using Deflate64 or BZip accidentially.

I'd run a PKUnzip -v over your recently recompressed ones and send it to a text file and grep it for those compression methods.  By explicitly choosing it I know it wont screw up

I use advancemame myself (in my cabs) that has no problem with the files, but like to "check out" games using Mame32plus, and its annoying that it fails on these.

I see in the recently requested "250" zipper zipmax.ini file from Romans forum board, that BJW chose to play around with lots of compression around 255 through 258 and change the other parameter (passes?) -- i only glanced at it.  He then worked down on even partial powers of 2... 192, 160,128,....

I've always been meaning to start a comparison.. uncompressed, then run it through each and then find out which percentage compresses the most/least/ever and then structure things that way.  Yeah you might eventually "miss" one that would gain something extra, but could filter out the stuff that basically is redundant, rather than throwing 250 things at it.

I don't care throwing 250 things at someting, if they all were as fast as say PK stuff.  but throwing 250 flavors of intense 7zipping does push me past the analness point  but then again my 40 things makes Roman sick, as he does 3.


If I had ~300 GHz right now at my disposal, I'd throw every file in Mame and do a complete analysis of what produces:
a) identical bits every time (not just same size)
b) speed to produce identical bits
c) speed to decompress files of same size but different compressed bits
d) settings from top to bottom to determine best bang for buck.


Anyway, did you have any interest in the multi-machine supporting source changes to ZipMax? (Since it seems Roman really wants to wash his hands of it).  I can post them here if you want to recompile yours.... so long as I can find them. I know I have them at home, dont know if there're still here at work.  I'll probably do another post for ZIPMAX Source Changes/Suggestions here, as it might get more support here than at Romans

[MonitorGuru]

Oh yeah, if you don't specify -s, you get -s120 by default.  I do have -n on mine like you.

I found -s64 is relatively fast (even *bearable* on the 100 meg zips), while s120 was worse (probably twice as long)   -s8192 is the highest setting and incredibly slow (takes as long to do a 1 meg zip with s8192 as a 100 meg zip with -s64

[krick]

If you use an old enough version of 7zip, before they added Deflate64/BZip support then you have nothing to worry about (it was circa 2002/2003).  However if you are using their more recent code or your special build is built on it, then you very well could end up using Deflate64 or BZip accidentially.

I'd run a PKUnzip -v over your recently recompressed ones and send it to a text file and grep it for those compression methods.  By explicitly choosing it I know it wont screw up

Which version of PKUnzip should I use?  How will it report compression methods that it doesn't know about?

If I had ~300 GHz right now at my disposal, I'd throw every file in Mame and do a complete analysis of what produces:
a) identical bits every time (not just same size)
b) speed to produce identical bits
c) speed to decompress files of same size but different compressed bits
d) settings from top to bottom to determine best bang for buck.

I've thought about doing that as well.  However, I think I'd first modify the log format of ZipMax to make it more "parseable" and include timing information.

I'd also add a "packer-name-x" parameter to each entry so I could give them a short name that can show up in the log instead of 001 002 003 etc...

Anyway, did you have any interest in the multi-machine supporting source changes to ZipMax? (Since it seems Roman really wants to wash his hands of it).  I can post them here if you want to recompile yours.... so long as I can find them. I know I have them at home, dont know if there're still here at work.  I'll probably do another post for ZIPMAX Source Changes/Suggestions here, as it might get more support here than at Romans

Yeah, sure.  Throw it my way.  I'd give it a look.  My main machine is a P4 2.4 HT overclocked to 3.0, my MAME cabinet has a 2.8GHz (non HT) and I have another P4 1.6 overclocked to 2.0 (non HT) that I'm not using.  I think I could probably set up a compression farm like you're doing.  Oh, and I have a few P2/P3 class CPUs and motherboards sitting around that I could throw together just to make the party bigger.

What do you need to compile it?  I only have VC6.

[Silver]

Hope you don't mind me sticking my nose in briefly....

I used to be (relatively, after reading this thread ;-) ) anal about compression - back in the pre-windows days when I had serious space issues - but have become rather lazy with the advent of enourmous hardrives. However, the monster size of roms - and the fact there rather compressable - has piqued my interest a bit. I also dislike zip's as it tends to be the worst compressor....

Straight up, I don't have the time nor the processing power do run the kind of tests you guys are, but am intrigued by the process and results. Could you tell me:]

1) Does mame read all 7z file types natively?
2) Do you compress each file within a rom-set seperately? or just compress the whole game-rom and compare?
3) How does this effect decompression/mame rom loading? long waits? Or do you use this only for storage?
4) Forgive if this sounds v lazy - but do you have a general setting thats nearly the best 90% time?

Thanks

[JoyMonkey]

Good, I'm not the only anal compressor!

Big LOL!  

[MonitorGuru]

He He, Ha Ha, Who Who  JoyMonkey

Silver:  Check out the main ZIP Max thread for more info.  But in summary:

1) No, we use the zip-compatable format option of 7z only. Mame can't read anything other than standard Implode or Deflate ZIP formats (it can't even handle the new WinZip 9 Deflate64 or BZip formats, so you need to be careful of what zip programs you use and settings)

2) We use ZipMax to compress each file within a zip separately, then constructing a final zip given the smallest individual files from whichever compressor.  This is all automatic, we still deal at the .zip file level, but internally ZipMax finds the best matches.

3) Decompression does not slow down. It's still ZIP compatable formats using the defined zip structures. In fact, ZipMax does NOTHING to these structures, they are what are generated by each program. ZipMax only knows where each file in a zip is and mends together the best over all archivers.

4) No, there is no "general" setting.  The lists provided above will give you 99%+ best compression, but not 100%.

[krick]

MonitorGuru, I just did a little digging through the 7Zip docs in an attempt to understand the command line options a little better and I thought you might find this interesting...

-mm=Deflate