Importing XM files to OpenMPT adds popping?

[alexparr]

I've been trying to mess around with XM files with OpenMPT for the fun of it, but noticed that something's wrong with the way OpenMPT imports them; for some reason, it adds a noticeable "pop" to some of the notes whenever one is interrupted. I've tried reinstalling the application and resetting the settings to no avail. Does anyone know what settings I should use to prevent this?

Below I've attached two example audio clips of an XM file; one of the original file, and the other of the same file after being imported into (and subsequently exported out of) OpenMPT. Both were recorded using XMPlay and the OpenMPT extension, and the track comes from SpongeBob SquarePants: SuperSponge on the PS1.

Before (original file): https://alexparr.neocities.org/extras/BeforeMPT.mp3
After importing + exporting with OpenMPT: https://alexparr.neocities.org/extras/AfterMPT.mp3

[Saga Musix]

In general there can be a variety of reasons, most typically related to the volume ramping settings (but as you said you reinstalled OpenMPT so it should be using its default ramping options, which shouldn't click). Without having access to the actual module in question (and preferably also your mptrack.ini settings file), it's hard to tell what is going on.

[alexparr]

Without having access to the actual module in question (and preferably also your mptrack.ini settings file), it's hard to tell what is going on.

Here's both; please note though that the XM file is split up into 3 distinct "sections"; the song that played in the previews I sent starts at section 3 (wherever pattern 12 is).

[Saga Musix]

Okay, I think I have a better picture of the situation now.

First off, I have to guess that in the XMPlay plugin configuration, you have disabled volume ramping. Volume ramping is meant to prevent these sort of clicks, so it is not unexpected that they appear when playing a file with volume ramping completely disabled.

Now for the question why the volume ramping appears to work before the file is re-saved in OpenMPT: libopenmpt and in turn xmp-openmpt by default emulate FastTracker 2's extremely soft volume ramping for XM files made with FastTracker 2. This ramping is so soft that it may completely destroy the attack phase of instruments like kick drums. This behaviour can be enabled as well in OpenMPT, but by default it is turned off (hidden setting "SmoothFT2Ramping" to automatically enable it for any newly-opened XM file saved with FastTracker 2, or through compatibility settings for individual XM files). When re-saving the XM file in OpenMPT, the status of this compatibility flag is saved in the file, and in turn xmp-openmpt will respect this setting. That is, if the XM file was saved with the compatibility flag not being set (the default), then xmp-openmpt will just proceed to use the volume ramping exactly as you configured it in the plugin.

[alexparr]

Now for the question why the volume ramping appears to work before the file is re-saved in OpenMPT: libopenmpt and in turn xmp-openmpt by default emulate FastTracker 2's extremely soft volume ramping for XM files made with FastTracker 2. This ramping is so soft that it may completely destroy the attack phase of instruments like kick drums. This behaviour can be enabled as well in OpenMPT, but by default it is turned off (hidden setting "SmoothFT2Ramping" to automatically enable it for any newly-opened XM file saved with FastTracker 2, or through compatibility settings for individual XM files).

Yep, turning that on seemed to do the trick. The "converted?" file now sounds indistinguishable from the original. Thanks!