munch.py is .it's equivalent of .xm's BoobieSqueezer, except it works quite differently.
It can be obtained here: https://raw.github.com/iamgreaser/it2everything/master/munch.py
If you don't have a Python environment installed for some reason, then here is a Win32 archive with munch.exe.
Read the zREADME.TXT inside of it.
How does it work?
Firstly, it decompresses and then recompresses the samples (as IT214 and IT215, then it picks the better of the two).
It then works out what's used and what isn't.
Meanwhile, it marks bytes that are essentially unused.
Once its established what's used and what's not, it removes unused stuff and rearranges patterns / samples / instruments.
After that, the blocks are arranged in a lovely overlapping fashion.
And then it's saved.
How good is the sample compression?
Suboptimal, but better than ImpulseTracker most of the time. There are two* algorithms, and it would be nice if it could mix them, but the aim is to get an optimal algorithm first. There's a roughly 50:50 split between which of the two algorithms perform better, although one is preferred over the other simply due to complexity.
* there's one in development** but it's a piece of crap, there's also another algorithm which is computationally equivalent to the one used
** it hasn't been touched in a while so that term may be misleading
The default algorithm (recursive crater) has been formally proven to be suboptimal, but it's a fairly simple algorithm. Feel free to add your own proof here. The other algorithm (fillin) hasn't been proven suboptimal (there's likely room for improvement), but it's quite complex, hence the "abstract fillin" approach which is currently not recommended at all.
Why does XMPlay hate munched modules?
XMPlay loads the file into memory, replaces some bytes in various text fields, and does something with the various values in the file after that. Because blocks tend to overlap here, often the length of a sample will get mangled.
There is a version of XMPlay here which works.
Why do XMP and MilkyTracker hate munched modules?
OK, they don't. But the handling of IT215-compressed samples in xmp-3.3.0 and MilkyTracker is... well, bullshit. It checks the "compatible with version" field in the header which is WRONG - the correct method is to check bit 2 (0x04) in the Cvt field of a sample to determine IT214 or IT215.
The XMP developers have been informed of this and a patch has been submitted by an XMP developer (plus it should soon tell you that the file's been munched :D).
As for MilkyTracker... why the hell are you playing .it files in MilkyTracker, anyway?
I have stereo samples but now they're mono!
Go play it in XMPlay.
There's that "fixed" version; you might want to try that.