Author Topic: 3.8 reports, queries and bugs (Read 353773 times)

saga · « **Reply #850 on:** 20 Feb '22 - 00:07 »

XMPlay doesn't show various instrument names in this module: https://modarchive.org/index.php?request=view_by_moduleid&query=195593
I didn't have a closer look but I guess they might start with a NUL character.

Ian @ un4seen · « **Reply #851 on:** 22 Feb '22 - 12:59 »

It is indeed leading NULs. Here's an update that will convert them to spaces:

www.un4seen.com/stuff/xmplay.exe

This update also automatically applies the "scaler_listtext" fix for old black skins like Neutron, so that they shouldn't require updating for the recent skinning tweaks mentioned in the previous post, but please let me know if you (or anyone else) do still spot any looking dodgy.

saga · « **Reply #852 on:** 22 Feb '22 - 21:25 »

Thanks for both fixes! I don't really use any skins other than Neutron, and Neutron looks fine now.

yoba · « **Reply #853 on:** 28 Feb '22 - 04:40 »

Dear Ian!

I see that you sometimes update formats plugins, usually together with BASS plugins, couple days ago FLAC plugin was updated.
But what about Monkey's Audio (APE)? Project is very active again after years of some hibernation, there are many changes, including some breaking ones. Current XMPlay plugin is from 2010 and BASS is from 2014.
I know that these plugins are not yours but from Sebastian Andersson (MaresWeb) and he is no longer active, but same were other plugins like for example AAC one which you updated few times already.
Can it be updated? SDK is freely available.

Thanks in advance!

sveakul · « **Reply #854 on:** 28 Feb '22 - 05:45 »

Ian @ un4seen · « **Reply #855 on:** 28 Feb '22 - 12:16 »

That's a coincidence! I noticed just a few days ago that there had been quite a bit of activity on Monkey's Audio, and was planning to create a new plugin for XMPlay (and BASS) based on the latest stuff this week. It shouldn't take long.

Ian @ un4seen · « **Reply #856 on:** 3 Mar '22 - 13:38 »

The new Monkey's Audio plugin is up on the XMPlay page now.

Forgiven12 · « **Reply #857 on:** 31 Mar '22 - 19:02 »

Hello. First time posting here because I couldn't find a solution on my own.

One particular .s3m audio file is recognized, and XMPlay starts to playback it, but there's no audio! I've tried it in both versions of 3.8.4 and 3.8.5 and there's no output. Audiocity and VLC both playback the particular song fine. XMPlay plays other .s3m files fine that I've tested. Also tested a "fresh" folder of XMPlay with all default settings but no avail either.

I attached a link the the audio file (on my Google Drive). Feel free to run it through Virustotal and whatever as a precaution

. I'd just like somebody more technically knowledgeable to figure out what's up with it.

Thanks for reading. Been using XMPlay since 2016.

https://drive.google.com/file/d/1fAhzrwavH3q7hacBaC4YDMnmmzvk6Y68/view?usp=sharing

Ian @ un4seen · « **Reply #858 on:** 4 Apr '22 - 17:10 »

That file is also silent when played in Scream Tracker and Impulse Tracker. For some reason, it has its default global volume set to 0. Do you know what tracker it was made with? I guess it must have been one that didn't support global volume. To avoid the issue, here's an XMPlay update that will ignore a 0 global volume setting in S3M files:

www.un4seen.com/stuff/xmplay.exe

saga · « **Reply #859 on:** 4 Apr '22 - 18:06 »

There is a small number of very early ScreamTracker modules with the same issue (DARKNESS.S3M by Purple Motion being another example), but the files appear to be genuinely made with ScreamTracker 3. For what it's worth, OpenMPT ignores a global volume of 0 for S3Ms made with Scream Tracker versions before 3.20, because I have never come across an S3M file with a cwtv value of 0x1320 having that problem. I suggest for XMPlay to do the same.

Ian @ un4seen · « **Reply #860 on:** 5 Apr '22 - 12:37 »

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 · « **Reply #861 on:** 9 Apr '22 - 13:48 »

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 · « **Reply #862 on:** 30 Apr '22 - 22:24 »

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 · « **Reply #863 on:** 4 May '22 - 18:03 »

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 · « **Reply #864 on:** 4 May '22 - 20:49 »

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 · « **Reply #865 on:** 29 Jun '22 - 21:06 »

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 · « **Reply #866 on:** 30 Jun '22 - 17:03 »

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 · « **Reply #867 on:** 30 Jun '22 - 22:30 »

Quote from: Ian @ un4seen on 30 Jun '22 - 17:03

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 · « **Reply #868 on:** 1 Jul '22 - 12:44 »

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 · « **Reply #869 on:** 1 Jul '22 - 13:16 »

Quote from: Ian @ un4seen on 1 Jul '22 - 12:44

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 · « **Reply #870 on:** 1 Jul '22 - 16:28 »

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 · « **Reply #871 on:** 29 Sep '22 - 09:32 »

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 · « **Reply #872 on:** 14 Mar '23 - 19:16 »

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 · « **Reply #873 on:** 15 Mar '23 - 14:49 »

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 · « **Reply #874 on:** 15 Mar '23 - 19:02 »

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.