Topic: 3.8 reports, queries and bugs

[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...

[Geoffrey]

The latest exe seems to break the Enhancer 0.17 plugin winamp plugin for me. If I open the player there's an error message saying "Can't access registry information" and it resets my enhancer preset. If I swap it with an older exe it works as intended again.

[Ian @ un4seen]

Yeah, it looks like both of those Winamp plugins need VirtualStore to be enabled. in_vtx because it writes a temporary file (in_vtx.dl_) to the installation folder, and dsp_enh because it stores its config in the HKEY_LOCAL_MACHINE registry branch. No doubt there are other old plugins that will need VirtualStore enabled too, so here's an update that re-enables it:

   www.un4seen.com/stuff/xmplay.exe

This update will still enable the per-user config option by default when installed in Program Files, but leaves VirtualStore enabled for when that's needed. It also adds support for Winamp's IPC_GETINIFILE message and tweaks the IPC_GETINIDIRECTORY message support, so that at least some Winamp plugins (using either of those messages) will obey the per-user config setting. Please let me know if you still see problems with any plugins.

[saga]

I can confirm this version works again with in_vtx, and the panning issue is also resolved.

[saga]

The original release of Purple Motion's Soul-O-Matic from the Journey 2 musicdisk (https://files.scene.org/view/mirrors/hornet/music/disks/1993/journey2.zip, SOUL-O-M.MOD) gets butchered in current XMPlay, which used to be not the case. The problem with this file is that its loop data exceeds the sample length, for which interpretation changed because of a fix for another MOD file.
What I do in OpenMPT is that that the fix for that other MOD file is only applied for MOD files that satisfy the following requirements:
- Magic bytes are M.K.
- No notes outside of the three octave supported by Amiga
- No empty sample slots have a default volume of 64 (because this is mostly encountered with PC trackers like Scream Tracker and MPT)

Doing that in XMPlay will most likely fix Soul-O-Matic there.

[Ian @ un4seen]

I notice in that Soul-O-Matic file's case that the sample loop lengths are set to the sample length, like it's a loop end position rather than a loop length. Perhaps there was a tracker that treated it like that? From the included text files, it sounds like the file may have been created with a pre-release version of ST3, and so perhaps that had a loop length/end bug? That would make some sense, as the S3M format does store loop end positions rather than loop lengths.

[saga]

It is very much likely that this is a bug only encountered in an unreleased ST3 version, indeed. It's pretty clear that Purple Motion used ST3 for writing everything included in the musicdisk. However, as I'm not aware of any other MOD files with this problem, and all the S3Ms in that musicdisk were written with ST3.00 - which has not been released, the earliest available release is ST3.01, and that doesn't have this bug - it might not be a good idea to implement special interpretation of the loop length as loop end, and instead just clamp the loop length as before the fix for shorttune2. As the fix for shorttune2 should only affect ProTracker MODs anyway, verifying that the conditions above are met might be the safest way to go. I did edit my post above because there was a typo in the last condition (an empty slot with a default volume of 64 hints at a PC tracker, not a default volume of 0).

[Ian @ un4seen]

I think FT2 also sets unused sample volumes to 0 and uses the "M.K." signature in 4 channel MODs, so I'm not sure that's a reliable ProTracker indicator.

Have you encountered any other MOD files broken by that ProTracker compatibility tweak so far? If it's only Soul-O-Matic then the looplength=length test (or non-"M.K." signature) may be good enough for disabling the tweak? The nice thing about that test is that it's quick and easy

[saga]

I think FT2 also sets unused sample volumes to 0 and uses the "M.K." signature in 4 channel MODs, so I'm not sure that's a reliable ProTracker indicator.

Well, in the end it only has to be stable enough for broken files, and I don't think that FT2 ever writes broken loop data, for example, so it's not really applicable to this case. But sure, if you add a special case for replen == sample length, that would probably also work fine.

[Ian @ un4seen]

OK, here's an update that will only apply the ProTracker sample loop/length tweak when the loop length doesn't equal the sample length and the file's signature is "M.K.":

   www.un4seen.com/stuff/xmplay.exe

Please let me know if you see it causing problems for any MODs.

This update also has a few other changes, including a new "tools" feature that allows tracks to be passed to external tools/apps via the right-click menu, eg. for editing/tagging/etc. Example settings for OpenMPT are included

[saga]

Soul-O-Matic plays fine now. And that Tools menu is definitely a great addition, I can already see myself using that (instead of going through "Explore Folder" all the time).

[yoba]

After updating to that last version 3.8.5.52 from previous (?) 3.8.5.48:

Panels' state was dropped, equalizer and playlist were hidden, now they are visible, why? Default skin. What it have to do with these "Tools"?

In settings, besides new obvious "Tools" parameters, there also another new:

WindowSnap=9
SpectrumSolid=1
Panels=0

Whats that?

Bad update   

[Ian @ un4seen]

Another change in the last update (besides the new "Tools" feature) is that the panels no longer slide but rather go in/out on a single click, ie. the state is in/out now and never somewhere in between, so the old "PanelPos" setting was replaced by a "Panels" setting. The panel state is still saved, just in a different setting.

The "SpectrumSolid" setting has been present for a while now. You can toggle it by middle-clicking in the "Spectrum" visuals display.

[yoba]

the old "PanelPos" setting was replaced

So this useless now parameter wasn't removed by program and must be removed manually.
I wonder how many dead and useless parameters in my few years old xmplay.ini.
May be some "sanitise" function? Or placing old parameters in some dedicated section after some warning, like "Settings after this line have not been recognized by the current version"?\

The "SpectrumSolid" setting has been present for a while now.

Not before 3.8.5.52. Or was it "secret" setting before and now it is not secret?
What does it even mean SpectrumSolid

And what is WindowSnap=9?
What is 9?

[Ian @ un4seen]

So this useless now parameter wasn't removed by program and must be removed manually.

It doesn't have to be removed. Unused XMPLAY.INI settings don't have any effect, so you can just leave them there. Note that if you ever tried any plugins then they may have left some settings in there too. If you don't want any unused settings then you can delete the XMPLAY.INI file for a fresh start.

The "SpectrumSolid" setting has been present for a while now.

Not before 3.8.5.52. Or was it "secret" setting before and now it is not secret?
What does it even mean SpectrumSolid

It was introduced in 3.8.5.43. You can middle-click (press the mousewheel) in the spectrum vis display to see what it does.

And what is WindowSnap=9?

That's related to window position being snapped to the edge of the screen.

[Luka]

Since the last few "beta" updates moving xmplay file into a folder is not possible will only create a shortcut

[Dirge]

WASAPI Exclusive mode quit working …

Everything about XMPlay 3.8.5.0 was working fine until yesterday when WASAPI Exclusive mode quit working: playback doesn't quite lockup, but it slows to about 1/100th normal speed. I had used WASAPI Exclusive mode about two weeks ago without issue, but when I tried it yesterday the problem arose. I tried deleting and reinstalling XMPlay and all of its plugins and trying different settings, but to no avail. WASAPI Shared mode works fine.

It appears that Windows Update did change some audio-related software in the last two weeks, so I rolled back to previous AMD and Realtek audio drivers, but that didn't have any effect. All of my other audio players work fine in WASAPI Exclusive mode. I'm guessing that some other aspect of the Windows update has caused problems for XMPlay's WASAPI plugin, but I don't know. Does anyone have ideas/suggestions?

I'm running an up-to-date version of Windows 11 22H2 on a laptop with an AMD Ryzen 5 CPU and built-in AMD and Realtek audio.

[Luka]

the "cant move to new folder" bug still not fixed

[Ian @ un4seen]

Since the last few "beta" updates moving xmplay file into a folder is not possible will only create a shortcut

This seems to be because XMPlay now adds itself to the "App Paths" registry, which allows you to run XMPlay by entering "xmplay" in Windows' search (Win+S) or run (Win+R) boxes. You can still move the file by holding down the Ctrl key.

WASAPI Exclusive mode quit working …

Everything about XMPlay 3.8.5.0 was working fine until yesterday when WASAPI Exclusive mode quit working: playback doesn't quite lockup, but it slows to about 1/100th normal speed. I had used WASAPI Exclusive mode about two weeks ago without issue, but when I tried it yesterday the problem arose. I tried deleting and reinstalling XMPlay and all of its plugins and trying different settings, but to no avail. WASAPI Shared mode works fine.

It appears that Windows Update did change some audio-related software in the last two weeks, so I rolled back to previous AMD and Realtek audio drivers, but that didn't have any effect. All of my other audio players work fine in WASAPI Exclusive mode. I'm guessing that some other aspect of the Windows update has caused problems for XMPlay's WASAPI plugin, but I don't know. Does anyone have ideas/suggestions?

I'm running an up-to-date version of Windows 11 22H2 on a laptop with an AMD Ryzen 5 CPU and built-in AMD and Realtek audio.

That's strange. I don't seem to be able to reproduce that here, so perhaps it's device/driver-specific. What driver are you currently using? If Realtek's driver then you could try uninstalling that and using Microsoft's, or vice versa, to see if that makes any difference. If you have another soundcard available, you could also try that. Please also confirm the exact Windows version/build number.

I doubt it'll make a difference, but you could also try this latest XMPlay build:

   www.un4seen.com/stuff/xmplay.exe

[Dirge]

Since the last few "beta" updates moving xmplay file into a folder is not possible will only create a shortcut

This seems to be because XMPlay now adds itself to the "App Paths" registry, which allows you to run XMPlay by entering "xmplay" in Windows' search (Win+S) or run (Win+R) boxes. You can still move the file by holding down the Ctrl key.

WASAPI Exclusive mode quit working …

Everything about XMPlay 3.8.5.0 was working fine until yesterday when WASAPI Exclusive mode quit working: playback doesn't quite lockup, but it slows to about 1/100th normal speed. I had used WASAPI Exclusive mode about two weeks ago without issue, but when I tried it yesterday the problem arose. I tried deleting and reinstalling XMPlay and all of its plugins and trying different settings, but to no avail. WASAPI Shared mode works fine.

It appears that Windows Update did change some audio-related software in the last two weeks, so I rolled back to previous AMD and Realtek audio drivers, but that didn't have any effect. All of my other audio players work fine in WASAPI Exclusive mode. I'm guessing that some other aspect of the Windows update has caused problems for XMPlay's WASAPI plugin, but I don't know. Does anyone have ideas/suggestions?

I'm running an up-to-date version of Windows 11 22H2 on a laptop with an AMD Ryzen 5 CPU and built-in AMD and Realtek audio.

That's strange. I don't seem to be able to reproduce that here, so perhaps it's device/driver-specific. What driver are you currently using? If Realtek's driver then you could try uninstalling that and using Microsoft's, or vice versa, to see if that makes any difference. If you have another soundcard available, you could also try that. Please also confirm the exact Windows version/build number.

I doubt it'll make a difference, but you could also try this latest XMPlay build:

   www.un4seen.com/stuff/xmplay.exe

I've tried the last four Realtek drivers (I'm currently using 6.0.9366.1), the Microsoft driver, and the current beta version of XMPlay, but there's no change. Windows Update must have corrupted some little thing on my PC that's only affecting XMPlay's WASAPI plugin. I'll (naively) hope that a future update will magically fix it.

Windows 11 Home
Version   22H2
OS build   22621.1848

[Ian @ un4seen]

Please try this BASSWASAPI test for comparison:

   www.un4seen.com/stuff/basswasapi-test.zip

Extract that to a folder and open it in a Command Prompt window, and then run ".\contest -x <filename>" and ".\contest -x -e <filename>", where "<filename>" is an audio file.

Also, does the file's sample rate have any bearing on the problem, with either XMPlay or this BASSWASAPI test? You can check that with XMPlay by enabling the "Apply sample rate to all file formats" option in the "Output" options page and then setting the "Sample rate" option to various values.

If you have another soundcard available (eg. USB), please do also try that, to see whether the problem is only affecting the Realtek.