TripleA

Perhaps add HashCheck as well as keeping HashTab? At least initially to forestall any unforeseen complications.

Thank you for the clarification. I assume you got an out-of-memory (or an error of some sort, at any rate) when compressing? I.E. Not a silent failure. => My archives are (probably) OK! Sorry if I'm a bit single minded, here... To get back on topic, I successfully re-compressed the visual style packs here with decent space saving. Certainly not worth the effort on its own, to be sure, but something to keep in mind if you ever refresh/update any of them, Kel.

This is almost certainly not decompressor related, as the FreeDB archives come from a Unix FS. Have you read their FAQ? Here's the relevant section: http://www.freedb.org/en/faq.3.html#33 In any case, Kel's comment, as I understand it, refers to compressing the files. About 7-Zip, the only problem I'd expect might arise with sane archives (I'd expect anything to overflow if, say, dealing with millions of files) is insufficient memory: please note the memory requirements listed for compression and decompression as you select the compression options. Note that diminishing returns set in pretty quickly for most types of data, so it usually isn't economical to select the highest options anyway. Frankly, my concern regarding this potential issue exceeds saving a few mebibytes and transcends open- vs. closed-source feuds. At least from my PoV: I've been archiving a lot of data into multi-volume 7z archives with .PAR recovery data and I would like to know if some of that data is potentially lost.

I'm confused. Could you please explain what you mean by 7z not being able to handle that big a folder? I used it to compress folders with over 4 thousand files and over 1GiB in size without incident. In any case, I unpacked the three large visual style packs and repacked them using 7z v4.57, all three together and each separately, without any problems. Rather smaller than .RAR, I might add: 57MiB vs. 78MiB...