Apparently this plugin stores its data in ZIP format. This data is then embedded in the OpenMPT module, and somehow the unzip implementation is extremely eager to find this ZIP file hidden in the middle of the module file. I guess we might have to find a way for minizip to be less eager detecting such files, because the file neither starts with the PK signature (which doesn't matter) nor does it end with an end-of-central-directory signature.

If you try to open your MPTM file in e.g. 7-zip, you will see the contents of the plugin's data chunk, which shows that it's not just minizip that's so eager to find it.

For the time being, you can circumvent this issue by loading a sample that's at least a few KB in size (10KB or so should be enough, I didn't verify how far into the file minizip tries to find the ZIP signature). This will avoid the ZIP-inside-MPTM being detected by minizip and the file will load as a regular MPTM file. Obviously this is not a long-term fix but it allows you to use the plugin at least.

Ah thanks! That all makes sense, good to know there's a workaround for the time being. :)

Update: unfortunately adding samples doesn't seem to solve it (even over 10MB worth of samples, at which point 7-zip stops detecting it as a zip). I guess minizip has no limit on how much of the file it searches? Or the limit is super high.

I did add a sample and it worked fine here, but just to be clear the module needs to be in IT or MPTM format for that workaround, for XM it won't work because samples are stored before plugin data, not after. From my understanding of minizip's source code, the global comment following the central directory index may be at most 65535 bytes long, so any sample longer than that should work around the problem, but I found it to work properly even with smaller samples.

I'll report this issue to the plugin developer as well, because any other application that can handle both music files and zip files will have the same issue. Maybe the plugin developer can change their chunk storage format.

One way forward for OpenMPT would be to expect ZIP files to start with the "PK" magic bytes before passing the ZIP file even on to minizip, similar to how we do it with RAR files. This would remove the possibility to extract modules from self-extracting ZIP files (which exploit exactly the behaviour you encountered here), but I guess that's not OpenMPT's main functionality as well, so it's something we can do without.

Ahh right, yes I was using XM, verified that the sample data was at the front and mistakenly thought that was desirable x)

Reported to the plugin author: https://github.com/tommitytom/RetroPlug/issues/25

I guess from here there are two ways forward to fixing this in OpenMPT without requiring a plugin fix (and hardening against similar plugins that we don't know about yet):

• Don't pass files to minizip if they don't start with PK magic bytes - removes support for self-extracting ZIPs
• Restructure code so that first module formats are tried, and only if they fail handle archive formats.

As of r16517, OpenMPT first tries to load files as modules, and only if that files it tries again loading them as an archive and extracting modules from that archive.
This fixes modules using RetroPlug, but also crazy modules that contain ZIP files as raw samples (I wouldn't be surprise if that has been done already).