Print

[pailes]

I will deal with that case in the XM module loader.

[sverx]

According to the official XM spec 0x13 is not a valid sample type. 0x10 specifies 16 bit sample type but 0x3 is undefined.

I also didn't find type 0x3 in the specs, so I thought it was simply that that I couldn't find the latest specs...  ... then I saw MilkyTracker loading the loop that way so I made the correspondance  0x3 = One Shot loop but I was wondering why it was doing ping-pong... 

So you're saying that XMs shouldn't contain this kind of loop (one-shot) at all, and type 0x3 should be considered just a mistake and whatever the player will decide to do with it is ok anyway? Well, I finally chosed to convert it to a forward loop in my little player, even if that particular XM I found was playing fine with ping-pong... but -you know- the other option is to stop loading and say "module broken" 

Ciao

[Saga Musix]

This file seems to be created with some strange tracker. Yes, modplug supports module comments for XM files (which FastTracker 2 didn't do), but this definitely hasn't been created in ModPlug. The Format ID is "FastTracker v 2.00" instead of "FastTracker v2.00".

[pailes]

This file seems to be created with some strange tracker. Yes, modplug supports module comments for XM files (which FastTracker 2 didn't do), but this definitely hasn't been created in ModPlug. The Format ID is "FastTracker v 2.00" instead of "FastTracker v2.00".

Thanks for pointing this out. I didn't recognize the Modplug-Message at the end of the file. So my guess is that this file has been created with an old Modplug version because I've never seen any tracker which writes the same kind of text tag. The tracker ID was probably fixed some time after this track has been created.