Plays in ModPlug Player 1.46.01 (last one) flawlessly here. No corruption of playlists whatsoever...

ModPlug player can't even see the rest of the patterns because of that invalid gap in the order list...

Sounds more like unused scraps to me, which doesn't surprise me coming from necros. foo_dumb.

What's really disturbing is in OpenMPT the mangled note data is all like "let's play D-? on instrument number 234" and in IT.EXE the mangled pattern data does all sorts of really screwed up effect data, even effects that show characters used in the GUI elements like the blips in the note dot display...

I know those songs are used and there's a "no loops" version on ModLand which has the patterns I'm talking about playing correctly and not horribly mangled.

EDIT: Infact here's the thing I mentioned in comparison artscene.textfiles.com/music/mods/S3M/M ... loops).s3m

The file could've intentionally been modified to prevent trackers from loading it properly, yet still leaving it possible to play the file back normally in a music player... That's just a wild guess though.

Holy.... I tried loading this in ScreamTracker 3.20 and it showed a ^^? in the note column on the affected pattern I was talking about... I've officially died...

I wonder how I could invoke this particular song in Pursuit of Greed then...

Hmm, it looks like that when the song was made, unused (deleted) patterns in the middle were left out of the file, and thus there are several pattern pointers that are zero. As these are unused patterns, they are not pointed to anything (in the order table), so nothing tries to play them.

It is possible that the song was not made in ST3 but with something else, if this is not compatible with ST3.

But to me it sounds normal that patterns that do not exist are not stored in file, and Audacious (which uses ModPlug) plays it fine.

I did some more research. The file is definitely corrupted, 0xE00 bytes starting from offset 0x7200 to 0x7FFF should be pattern data but looks more like sample data. Patterns 51,52 and 53 are affected and won't decode properly.

Looking at the order table, the song may contain several subsongs, or then it just wants to jump around a lot. Anyway, I didn't try to figure out if those patterns are ever played or if the song end is hit before those patterns. I have some ideas how the file could be fixed, but I have no knowledge which ways would work best in different players/trackers or would these cause other problems.

By all means share with me your ideas, perhaps the corruption is probably stemming from how buggy ST3 was when saving files?

Yeah I also recall it sometimes corrupted something.

Anyway, I hope you have a good hex editor.

The first thing to try is to fill out the corrupted area with zeroes. Zero data byte means end of row in the file.
Then hope whatever is going to play it will stop when it has read 64 rows in a pattern, no matter how many bytes a packed pattern is said to be.

If that does not help, in addition you need to adjust the size of packed patterns to match 64 empty rows. Then it is easier to also zero out the whole pattern 51 as well so you zero out patterns 51, 52 and 53. These start at file offsets 0x6FB0, 0x7590, 0x7D00. So to these three offsets, you need to write packed pattern length (0x42, 0x00) because the length of 66 includes the two length bytes and 64 zeroes that are end of row markers. This is better, but there are now unused gaps in the file, some S3M loader might expect the next pattern starts after previous has completed.

But it just occured to me that maybe it would be simpler to just keep the corrupted area as it is now, and just edit the order table and headers to remove any reference to patterns 51, 52 and 53. There would still be surprising unused gaps where nothing in the file points to.

OK so I tried that. Replaced references to patterns with end of song markers (5 bytes) and then changed pattern data pointers to point to zero (6 bytes). Before the file did not load in MilkyTracker, now it does.

Here, have a try.

Yeah this also get's it to load in some really cranky players.

I actually took the "no loops" pattern data and merged it with the corrupt patterns so they work again, but another funny thing I noticed.

Some of the samples aren't right between the two files... Maybe the samples that were supposed to be in SONG0 somehow ended up as pattern data? ST3 must of had a major heart attack saving that file back then...

Actually, this kinda reminds me of one of my favourite module tunes that was originally distributed with most of its sound channels turned off, thus it sounds kinda lame, but when you turn all the sound channels on it sounds freakin' amazing! ;D

Let me get back to you guys on that one once I can dig it up and see if I can find it in its originally distributed form...

EDIT: Nah, the download on MOD Archive has since been corrected. :B

This song for the curious: http://modarchive.org/index.php?request=view_ … eid&query=45655

Note the single review of it from over a decade ago says it's only four channels, when in fact, it uses 9. ;D