NOTE: This has only been done with one file.
If you've ever downloaded IT v1.06 and tried to open CREAGAIA.IT in anything that isn't IT itself or something modplug-based, you'll probably notice that it doesn't load. If you're that sort of person, you'll open it up in a hex editor and see the dreaded "ziRCONia" tag. This, my dear friend, is an MMCMP-compressed file.
While the original modplug author (not going to say his name in fear of misspelling it) managed to reverse-engineer it with some help from the MMCMP author from what I gather, he hasn't documented it. I haven't had much success myself, but I do have the main file structure at least partially documented, and a rough idea of how it actually compresses stuff.
It appears that the main compression scheme for MMCMP is simply to use explicitly defined Huffman trees and various levels of delta coding. DEFLATE (remember .zip? that's the compression you typically use with it) uses Huffman coding (either predefined or explicit) with an LZ77 scheme, so I'm really stumped as to why the MMCMP author believes it's better than .zip, apart from the fact that delta coding is used for samples... wouldn't it just make more sense to restructure + deflate the damn thing?
Rant aside, here's the structure as I see it.
For the header, you have the "ziRCONia" tag, and then a bunch of other crap I mostly haven't determined. There's 4 bytes unknown (first two are probably a 16-bit version thing), then a 16-bit block count, and a 32-bit destination filesize, followed by 6 more unknown bytes. After that, there's a bunch of 32-bit pointers - this is the block offset list, containing offsets to each block in the file.
Each block starts with two 32-bit values; the unpacked size, and the packed size. Then there's another 32-bit value which is most likely a checksum, and I suspect it's CRC32 as used in .zip, though there's a very fair chance that I'm wrong (noiw that I think of it, it could be Adler32). After that there's a 16-bit chunk count, a 16-bit value I've yet to determine, a 16-bit "unique symbol" count, and a 16-bit compression type.
Then we have the chunk delegation list. Each entry has two 32-bit values, the first is the offset in the destination file, and the second is the length. This is so that a block can be split into chunks and spread across the destination file. In most cases there will only be one chunk in a block, but CREAGAIA.IT has one block split into 3 chunks.
For compression type 0, what you have is plaintext. That's all I've determined.
For types 5 though 7, an explicit symbol table is used. I believe these are various levels of delta coding followed by Huffman coding with an explicit Huffman tree. 5 has no delta coding, 6 stores single deltas, and 7 stores double deltas.
For type 3, an explicit symbol table is also used, but I'm not sure what this format is for.
Finally, for types 0xE and 0xF, I really don't know. There's no explicit symbol table used from what I gather. I've tried to crack 0xE, and while I've suspected it uses a delta coding, I've yet to have any success. With that said, I suspect there may be a Huffman tree used, at least for type 0xF (repeated 0x55 and 0xAA bytes should tell you something).
If there is an explicit symbol table, it follows immediately after the header, and is a list of bytes in roughly descending order of frequency.
Unfortunately, I don't know how the Huffman tree itself is actually encoded. I suspect that a "canonical" Huffman scheme is used as in DEFLATE, but it's not encoded in the same way.
That's what I've gathered so far. Would anyone like to take this further and find out how the Huffman trees are actually encoded? Once that's established, decompression of the 5-7 range should be fairly trivial (fingers crossed).
