Topic: .it files packed with munch.py fail to load sample data correctly

[GreaseMonkey]

I've been working on a tool to, well, "destroy" the structure of an .it file you give it in such a way as to reduce the file size. Unfortunately, XMPlay has issues loading the sample data, and so the samples sound all wrong. I have tested this in XMPlay 3.4 and XMPlay 3.6 using Wine (and I assure you, it is not a Wine issue).

I'll probably get shot by the forum software if I attempt to paste a link, but here's a link to one which DOESN'T have IT214 or IT215 compression: http://pubacc.wilcox-tech.com/~greaser/mods/deja_vu.it (I hope I got that right). Later versions of munch.py have IT214/IT215 sample compression, but I believe those would be handled by XMPlay otherwise.

And before you ask: Yes, it works fine in IT 2.14p5.

P.S. If you're not doing it already, if an IT21x sample block fails, IT 2.14 will still attempt to decode the next block (if I recall correctly). Modplug-based stuff will stop decoding the sample altogether.

[Jimmy Neutron]

I really don't understand what you're talking about, but from what I gather, is that you've destroyed the file format and then things just don't work correctly?  Do I have that right?

[Ian @ un4seen]

It looks like you have overlapped IMPI/IMPS blocks. When reading the texts, XMPlay may modify them (eg. replace 0s with spaces), and in this case the filename entry in an IMPI block is being modified, which is corrupting the length information in an overlapping IMPS block, and that's causing the sample's length to become very large and the memory allocation to fail.

Here's an update to try, which will take a copy of the text before modifying it...

   www.un4seen.com/stuff/xmplay.exe

[GreaseMonkey]

Yes, that appears to work fine, even with the IT214/IT215 compressed stuff. Thanks for that.

P.S. I find it interesting that you actually attempt to play compressed stereo samples. I think I'll fix my encoder to take advantage of the way you do it (currently I just compress it as one double-length sample, instead of compressing the two channels as two consecutive sets of blocks). Modplug and its derivatives (e.g. SchismTracker, which almost butchers the code to oblivion) only try to decompress one channel, and apparently it's not even supported in IT 2.14 (or is it?) (OK, it's done, all I need to do is make the stereo decompression work properly.)

[saga]

There is no standard behaviour defined in the algorithm on how to treat compressed stereo samples, since IT didn't even have stereo samples. It is not defined whether to treat stereo samples as one big audio stream or as two consecutive, separate streams. Before anyone starts messing around with compressed stereo samples, someone should better define how to treat them. In theory this "someone" would be Jeff Lim of course.