Author Topic: Crashing with playback of specific .XM files (with latest version of XMPlay)  (Read 1163 times)

donots

  • Posts: 3
Hello, good develeopers and regulars of this forum,

I have been using the current version of XMPlay to date (3.8.2), and it's been a spectacular experience and overallsatisfaction, so thank you VERY much for that. Outstanding well-programmed and well-designed work.

As for my issue, the problem is, a select few (like 50 out of 3000) .XM files, when attempted to be played, crash XMPlay 3.8.2. Suspecting it could be some .dll/library issue or simply a problem in the executable, I tried using an older version of XMPlay (3.4.2), and that file worked perfectly (as well as other previously functional files).

Here are my questions:
- Why is this happening? Why would the compatibility worsen with newer versions? Or could it be some other plug-in in the website is causing interference? (In which case, none of my plugins relate to XM file playback, but only other formats such as .rad, .amd, .v2m etc..)
- Is there any way to fix this in the current version? Or would perhaps even replacing some of the new version's files with older ones work?

Here is one music file I tested this with: http://www.keygenmusic.org/music/tsrh/TSRh-MagicPhotoEditor3.5kg.rar (Don't worry, despite the domain name, the website has nothing BUT music only, and has nothing illegal in it. It essentially only contains music used by the demoscene.)

Any ideas?


EDIT: I decided to test things further, so I started downloading many versions of XMPlay until I found the problem.

First I tested 3.8, which, to my surprise, also worked just like version 3.4.2, so then I moved to the next one, 3.8.1, and, that also worked!

By that point I redownloaded the latest version, 3.8.2 while wondering if that would also play right, and whether or not I did something wrong with XMPlay on my computer. But nope, it's been confirmed: it is specifically version 3.8.2 of XMPlay that has this .xm file playback issue for some files.
Does this information somehow help the devs identify what is the problem?
« Last Edit: 30 May '16 - 12:12 by donots »

saga

  • Posts: 2183
Quote
Why is this happening? Why would the compatibility worsen with newer versions?
Bugs happen. Noone intentionally inserts crashes into a program.

Anyway, the file does not crash here using the latest test version of XMPlay, so you should probably try that version first. If it still doesn't work, there may be a plugin at fault that you didn't put in the same folder as the other versions you tested.
« Last Edit: 30 May '16 - 17:15 by saga »

donots

  • Posts: 3
Quote
Why is this happening? Why would the compatibility worsen with newer versions?
Bugs happen. Noone intentionally inserts crashes into a program.
Obviously. But more specifically, I wonder, for example, why the segments that allow .XM playback were tampered with, considering the program, at least to my knowledge, has played .XM files with perfection for over a decade. Is there anything else to be improved on it? Because considering how amazingly good it already is, I'd find that shocking!

Basically, I was just curious as to why exactly this happened, if there's even any specific reason. Like "because we were still trying to improve the .XM playback" or "it was accidentally tampered with, it did not require any further coding or revision actually", in case the devs have anything to add. It's interesting to know.

In any case, thanks for the test version. For now, I'm content with using version 3.8.1, as I switched to that for the time being, and it seems completely functional with everything I have, but I'll come back to that one later if I ever have any problems.

saga

  • Posts: 2183
While XM playback is amazingly good in XMPlay, it's not 100% perfect (it probably never will be, given the crazy FastTracker 2 code :) ) and improvements are still being made every now and then. It is entirely possible that the crash is also due to some changes in a part of the code that is not necessarily exclusive to XM but is used in the XM code - only Ian can tell.
Quote
In any case, thanks for the test version. For now, I'm content with using version 3.8.1
So does the bug still persist in 3.8.2.9 or not?

In case you are interested, the XM file you supplied was edited manually to save a few bytes, and there are several XM players out there which will choke on it because of that.

Dotpitch

  • Posts: 2871
While XM playback is amazingly good in XMPlay, it's not 100% perfect (it probably never will be, given the crazy FastTracker 2 code :) ) and improvements are still being made every now and then.
Indeed, looking at the changelog for 3.8.x, there's a number of changes in module playback, usually because saga stumbles upon a hardly-documented FT2-quirk ;).

donots

  • Posts: 3
While XM playback is amazingly good in XMPlay, it's not 100% perfect (it probably never will be, given the crazy FastTracker 2 code :) ) and improvements are still being made every now and then. It is entirely possible that the crash is also due to some changes in a part of the code that is not necessarily exclusive to XM but is used in the XM code - only Ian can tell.
Quote
In any case, thanks for the test version. For now, I'm content with using version 3.8.1
So does the bug still persist in 3.8.2.9 or not?

In case you are interested, the XM file you supplied was edited manually to save a few bytes, and there are several XM players out there which will choke on it because of that.
Ah, that's fascinating. :) Thanks for the details.

And I just tested it, and I see the bug indeed does not persist in version 3.8.2.9 that you provided! That was a quick fix! I also was surprised to see XMPlay could still play files (at least .xm) without any of its pre-packaged DLLs!

deus-ex

  • Posts: 235
I also was surprised to see XMPlay could still play files (at least .xm) without any of its pre-packaged DLLs!

Damn, I still can't figure out why Ian named this nice little proggy XMPlay.

Ian @ un4seen

  • Administrator
  • Posts: 20437
As for my issue, the problem is, a select few (like 50 out of 3000) .XM files, when attempted to be played, crash XMPlay 3.8.2.

I recall there was an issue with the initial 3.8.2 release (which may be causing that crash) and an update was released soon after. Perhaps you have the initial 3.8.2 release version rather than the update? The current release version is 3.8.2.3. If you don't have that, please give it a try and let me know if you still get the crsah with it.

kode54

  • Posts: 100
While XM playback is amazingly good in XMPlay, it's not 100% perfect (it probably never will be, given the crazy FastTracker 2 code :) ) and improvements are still being made every now and then.
FT2Play may be a useful reference for some of this, since it is based on hand interpreting the FastTracker 2 source code. Or at least, one particular private leak of the FT2 source code. Short of interpretation or coding errors, which are still being found, it's pretty damn good. The only aside is that either the original or my library version (here) is that the sound mixing code is not entirely the original. It is an improvement of the original, including compile and runtime configuration of note on/of and full volume/panning change ramping.

The ST3 AdLib code still needs to be examined and interpreted some day, though, so for now, I've got some crappy approximation of what I could understand from Schism Tracker for those parts.

PSXGamerPro1

  • Posts: 258
While XM playback is amazingly good in XMPlay, it's not 100% perfect (it probably never will be, given the crazy FastTracker 2 code :) ) and improvements are still being made every now and then.
FT2Play may be a useful reference for some of this, since it is based on hand interpreting the FastTracker 2 source code. Or at least, one particular private leak of the FT2 source code. Short of interpretation or coding errors, which are still being found, it's pretty damn good. The only aside is that either the original or my library version (here) is that the sound mixing code is not entirely the original. It is an improvement of the original, including compile and runtime configuration of note on/of and full volume/panning change ramping.

The ST3 AdLib code still needs to be examined and interpreted some day, though, so for now, I've got some crappy approximation of what I could understand from Schism Tracker for those parts.

Wow that totally must suck. I hate guessing sometimes too (Onnly to be 95% wrong) :P This is why I like Running XMPlay in Visual Studio's little nice Debugger so that way I can see the exception names that it gets. (So that way it can help Ian out if it does crash). Although I do Admit I think XMPlay needs some sort of Dialog that handles all exceptiosn and have that dialog generate a "stack" trace as well. It would be nice and clean and prevent the "XMPlay.exe has stopped working." stuff.

Also I see you have a github. I do too. :P
« Last Edit: 4 Jul '16 - 10:43 by PSXGamerPro1 »