▲

[Ian @ un4seen]

OK, thanks for the info. The update above isn't checking the version but just assumes that any 0 default global volume is a mistake. I guess that should be safe enough. Can't be many intentionally silent files

[saga]

Well, the file could have a fade-in at the start of the file - which would of course get "fixed" as soon as the first Vxx command is encountered in the pattern, but still, I felt safer to just ignore it for older ST3 versions because newer versions clearly don't have this particular issue.

[saga]

This SoundTracker MOD sounds a bit strange when played through XMPlay: https://modarchive.org/module.php?196668
OpenMPT plays it without issues, but I didn't do any deeper investigation what the difference is. sounds like some sample's length is off by a bit.

[Ian @ un4seen]

It seems like the file may be missing 1024 bytes from the end? That's messing-up XMPlay's 15-sample MOD detection/processing. Part of that involves checking that there's enough data in the file for the number of patterns in the orders list. When the orders list contains unplayed patterns (beyond the length in the header), XMPlay will drop them if the file isn't big enough to contain that number of patterns (I seem to recall that being needed for some 15-sample MODs). In this case, the file is only big enough for 10 patterns, while the orders list contains an unplayed 11th pattern. It looks like 11 is correct to get to the proper sample offsets, but the 1024 missing bytes makes it look incorrect.

[saga]

Hm, true. Essentially I think OpenMPT addresses the same issue the other way around: If there's extra hidden patterns, it does a plausability check, i.e. try to read the extra patterns and if the pattern data looks off (e.g. notes outside Amiga range, or sample numbers > 15), it will assume that those extra patterns aren't present in the file and that the data it just read is sample data.

[doom_hamster]

Hello, i want to report a crash on xmplay ver 3.8.5.

Its a bit weird, but i was able to troubleshoot it, i think.

Steps to reproduce:
- Put more than 100 tracks in xmplay's playlist.
- Open "Find tracks" window, and input some word* and hit Apply, close search window. (corresponding line in xmplay.ini is "Find=")
- Try to playback a track numbered 100, or higher. It will crash. Tracks numbered 1-99 play fine.

*weirdly, not every search word results in crash. For example, any of these words will lead to crash: fire, ice, fight, size, far.
So im really curious whats going on.

[Ian @ un4seen]

Please first try this latest build:

   www.un4seen.com/stuff/xmplay.exe

And if the crash still happens with that then please upload a dump file from it. You can generate a dump file using the ProcDump tool. For example, run "procdump -e -ma -x . xmplay.exe". Then ZIP and upload the generated dump file to have a look at here:

   ftp.un4seen.com/incoming/

[doom_hamster]

Please first try this latest build:

   www.un4seen.com/stuff/xmplay.exe

And if the crash still happens with that then please upload a dump file from it. You can generate a dump file using the ProcDump tool. For example, run "procdump -e -ma -x . xmplay.exe". Then ZIP and upload the generated dump file to have a look at here:

   ftp.un4seen.com/incoming/

Yes, it still happens with this build.
I tried uploading the dump file to the ftp from windows explorer, file named xmplay.exe_220701_022243.zip, did you catch it?

[Ian @ un4seen]

Yes, your dump file was received, thanks. Here's a little update for you to try:

   www.un4seen.com/stuff/xmplay.exe

Please let me know if the problem still happens with that, and upload a new dump file if so.

[doom_hamster]

Yes, your dump file was received, thanks. Here's a little update for you to try:

   www.un4seen.com/stuff/xmplay.exe

Please let me know if the problem still happens with that, and upload a new dump file if so.

It appears to be fixed in this version, i can't reproduce it anymore. Good job! Can you shed some light on what was wrong, in simple terms?

[Ian @ un4seen]

Good to hear that the update seems to have fixed the problem. The crash was in drawing the combined search text and playlist position display in the info window playlist, when the window's width was too small to fit any of the search text.

[Elrinth]

Priority doesn't work if file is played from a .m3u file...

I have two plugins: in_nez.dll (nezplug v0.9.4.8 + 3 + 24.10 (x86) and GME (rev .41fork))

I add priority file types: "sgc kss" for the GME plugin.
But when a kss file is played from a .m3u playlist it will use in_nez instead.

[saga]

https://files.scene.org/view/parties/2013/tum13/tracked_music/1388097391_mod.hey_hey_tum_edit

This MOD has a bit of a panning issue. I think it might have played fine previously because it's been in my playlist for a while, and I would probably have been pretty annoyed by the whole tune being panning 100% to the right.
As all the panning commands in this tracke are 888, it is safe to assume 8-bit panning (like in XM) rather than 7-bit panning (like in S3M).

[Ian @ un4seen]

For some reason that I unfortunately don't recall right now, S3M panning is being assumed if all 8xx effects are below 90 (but not equal to 80). Can you think of a reason for that? I guess it must have been done for some particular MOD file(s).

Actually, searching the forum for a possible explanation, I found this

   www.un4seen.com/forum/?topic=15425.msg125436#msg125436

I guess it could check for below 80 instead of 90, which would fix this case, but that may cause problems for some other files that you mentioned there?

[saga]

Unfortunately I don't remember which specific files required extending the check for values up to 88F.
In general, OpenMPT's decision tree looks something like this:
- If no commands above 830 are found, ignore panning completely. This helps with modules that use 8xx as sync commands in some demo soundtracks.
- If any pan commands < 880 are found, but no commands > 88F (ignoring 8A4 for surround), assume S3M-style panning.
- Otherwise, assume XM-style panning.

So far these heuristics have been pretty stable.

[saga]

I have found the module that required checking for values between 880 and 88F: https://modarchive.org/module.php?95797

[Ian @ un4seen]

OK, here's an update that should only assume S3M panning if there are 8xx effect values below 80 and none above 8F (except A4):

   www.un4seen.com/stuff/xmplay.exe

Please let me know if there's still any dodginess with it.

[saga]

There's definitely something dodgy, but not with the playback... When I try to run this version, it shuts down immediately. No crash prompt.

[Ian @ un4seen]

Strange. Does that happen even if you put XMPlay in an empty folder for a fresh config?

I don't know if it's related, but one change in this update that I should mention is that it disables Windows' automatic use of VirtualStore for XMPlay's config files (when it's installed in Program Files) and instead enables per-user config whenever the installation folder is unwritable. If you happen to have been using VirtualStore then you would need to manually move the files from there (%LocalAppData%\VirtualStore) to the per-user config folder (%AppData%\XMPlay).

[saga]

Interestingly, it does seem to work if I copy the XMPlay installation out of the Program Files folder - including all plugins. The plugin that seems to cause this problem for me is in_vtx (as available on the XMPlay support site). If I remove that from my Program Files installation, XMPlay starts normally. Which is interesting, since I don't see any traces of that plugin in VirtualStore, while some other plugins do leave some stuff in that folder...