Full Version:
OpenMPT v1.17.02.50
Has the bug occured in previous versions? If yes, please specify version(s): (This option is optional, and doesn't need research. But in case you know...)
All versions.
Description of the bug:
Some S3M files have partly corrupted samples in Modplug, wheras they sound ok in any other tracker.
Some examples:
94hitmix.s3m (http://modarchive.org/data/downloads.php?moduleid=62004#94hitmix.s3m) (samples 1,11)
spectral.s3m (http://modarchive.org/data/downloads.php?moduleid=58039#spectral.s3m) (samples 1,2)
I don't understand how they can sound ok in another tracker.
I tried both old MPP and .50 and both acted in the correct way imo.
Because these 4 samples have in common, that there is a very nasty HF artifact at the end of the sample.
Sometimes it seems ok, but that's because the sample is cut off for another one, before the end.
This can be heard, if e.g. looping the first pattern of 'spectral' with sample 2.
The HF noise that you mention is not intended. It does not belong to the sample. It's neither there in ScreamTracker, nor in XMplay or any other app I've tested. It's probably some overflow error...
now i also checked Impulse Tracker and Fast Tracker 2. Surprisingly, they also had noise in the end of the samples. Programs that work correctly:
- Scream Tracker (doh)
- XMPlay
- DeliPlayer
XMPlay is ok indeed, but I noticed a strange text in the General info of 'spectral':
Length : 6:24 - 60 orders
_______ 6:21 - 59.038 (trimmed)
JetAudio also had the noise.
It maybe an overflow error, but if I save such a sample with MPT, the HF end is there.
XMPlay has the option to trim out silence. I think that everything estimates this to be silence while it really isn't, and that the noise isn't being heard because it is being trimmed off.
I haven't tested the songs myself for this though, but thats the first thing that came to mind when I read trimming.
Trimming has nothing to do with trimming samples. As LPChip pointed out, silence at the end of the song is removed.
I have found out what's wrong here. Those sample had very short loops before the actual "corrupted" sample data which were so small that OpenMPT simply disabled them. It's very unlikely, but this could potentially break a few S3M modules. While I don't think that it will happen (tried it with a big part of my S3M collection), maybe one of you will find a "weak spot". I'll provide an updated test version ASAP.
Okay, so here's a debug build to try out:
http://sagagames.de/stuff/mptrack.exe
Sorry 'bout the icons! =)
Please play a lot of modules with this version. If you find any mods that sound different compared to previous versions, let me know.
I've uploaded a recent dev build, again with the s3m loop fix (the last few uploaded files didn't include the fix). So if anyone feels like loading a few dozen modules and check if all loops sound ok, feel free to do so with this build. :)
Of course it was just a matter of time until I would find a S3M file that would break because of this... Changed the fix a bit, so an updated test build is up (Also with a completely new PSM loader \o/).