Topic: 3.8 reports, queries and bugs

[saga]

I guess this is not really a bug but a bit of a design limitation...?
I have a saved setting for an empty path, which resets all the MOD-related settings and other stuff to defaults, so that modules sound the same everytime I play them, no matter if the previous module was using non-default interpolation settings, etc.
However, I would like to extend those to xmp-openmpt as well, and it is not possible to create another path settings for an empty path. XMPlay won't let me do that. So what I'd need is the ability to specify my default settings for more than just one decoder.

Thinking a bit more about this, I came up with a workaround that might be simple enough to implement without having to redesign the whole concept.
What if two path settings could have an identical path, as long as they cover different settings? So I could have a saved setting for the empty path with "amp dsp loop mod" as I have now, and another one only for openmpt. XMPlay would simply apply all matching presets then. As each preset would cover different settings, it wouldn't matter in which order they were applied.

[guest]

Is it possible to choose which saved preset/settings will be auto-loaded?

[saga]

The best (most specific) match is always loaded, so if there is a preset for C:\foo and one for C:\foo\bar, a file in C:\foo\bar\baz will auto-load the second preset.

[guest]

What if I want auto-load other settings for the same file?

[saga]

That's exactly what my request above is about - it is currently not possible to auto-load more than one preset. If it was possible to auto-load several non-conflicting presets, that would help me a lot.

[Ian @ un4seen]

I guess this is not really a bug but a bit of a design limitation...?
I have a saved setting for an empty path, which resets all the MOD-related settings and other stuff to defaults, so that modules sound the same everytime I play them, no matter if the previous module was using non-default interpolation settings, etc.
However, I would like to extend those to xmp-openmpt as well, and it is not possible to create another path settings for an empty path. XMPlay won't let me do that. So what I'd need is the ability to specify my default settings for more than just one decoder.

If I understand correctly, you want to include settings for both the built-in MOD decoder and the OPENMPT plugin in a single saved settings entry? If so, it should be possible to do that by clicking on the "Decoder" box, unselecting the "Current" option and then selecting the decoders that you would like to have the settings saved for. So you could load your existing MOD saved settings (double-click it), remove that entry, and then re-add it with OPENMPT settings enabled too.

[saga]

Ah, I didn't realize that was possible! The OpenMPT plugin seems to show up with an empty name in that dropdown menu (but it's shown correctly in the preset list, e.g. "amp loop mod openmpt"). Do you have an idea what could cause that?

[Ian @ un4seen]

Oops, here's an update that should fix that:

   www.un4seen.com/stuff/xmplay.exe

Let me know if it still gives you any trouble.

[MagikGimp]

v3.8.3.4 is crashing with this module by Bee Hunter. Plays fine in foobar2000. I thought you should know...

[MagikGimp]

v3.8.3.4 is crashing with this module by Bee Hunter. Plays fine in foobar2000. I thought you should know...

But not this version of the file/song! Hmm, interesting. I don't even know why there are two versions of it in the first place. A problem with double file extensions, if you get what I mean (as in MOD. on the beginning and .neverland on the end) perhaps?

[MagikGimp]

Huh, now this one is crashing it too. Basically all the songs that I'm going through that I liked that have been played on Nectarine recently. What bad luck!

[saga]

It doesn't seem to crash here, but I noticed that when the file is still packed in its .gz container, libxmp (or any other plugin supporting gz containers) takes over the playback, rather than XMPlay's own module player. Can you confirm whether the file is handled by XMPlay or a plugin? You can see which plugin (if any) handles the file on the general info tab.

[MagikGimp]

...still packed in its .gz container...

I "unzip" all files from AMP. I didn't even realise files could be played in a compressed form in XMPlay. I know the Amiga format is a little different and can cause problems when extracted in certain Windows apps so that could be what's causing it I suppose but then it does play fine in Foobar2000 as already mentioned.

You can see which plugin (if any) handles the file on the general info tab.

I can add these files to the playlist, the crash occurs on attempting to play them, so (presuming I can view the files' info without playing it) I'll check later when I get home.

[saga]

That sounds like some plugin is trying to handle the file then which is not designed to do so (my bet would be the ffmpeg plugin, if you use that one ). Can you remove your input plugins one by one to find out if any of them are causing the crash?

[MagikGimp]

Can you remove your input plugins one by one...

Sorry, I completely forgot to check back on this thread, Anyway, I'm far too lazy to be doing any of that I'm afraid but I do have another one for you:
If you're going to maintain that "balls-on accuracy" you're all so proud of extolling here, explain why this one doesn't play properly- http://aminet.net/package/mods/xceed/Sensuality Hmm? HMMM? To be honest, I was surprised. I'm a bit fan of XMPlay but this shook my faith a little! I mean, c'mon; if foobar can do it right...
This thread might be of some useful reference. It's where I originally found the link.

[saga]

Sorry, I completely forgot to check back on this thread, Anyway, I'm far too lazy to be doing any of that I'm afraid

Well, that way, we cannot help you with figuring out why it's crashing.

if foobar can do it right...

If you're talking about foo_dumb, that uses (as far as I'm aware) eightbitbubsy's ported ProTracker rountines, so obviously it is as accurate as it could possibly be. The "problem" with the MOD format is that there is so much different software out there that has been used to write MOD files, and each of them does things slightly different. It's impossible for XMPlay (or any other player) to guess 100% accurately how a MOD file should be played. There is a "MOD playback mode" setting in the MOD settings of XMPlay which plays MOD files more like ProTracker would. Set it to "PT1" and the file will play correctly. Balls-on accuracy restored, phew! I bet Ian was already sweating!

[MagikGimp]

This is very interesting stuff. I know very little about this really so it's fascinating that it's not (quite) possible to have a one size fits all approach, if I'm understanding this correctly. I don't know why foobar2000 exclusively (?) got to use those routines you mention but it's implied that it must sometimes have a stumble over a particular file itself now and then too. I actually like the little mistake XMPlay makes on normal setting with sensuality.mod. That little grace note makes a nice but soppy tune just a bit more interesting.

I had a little play around with removing plugins but considering the other version of that song (kingdom of pleasure) is identical, I'm not sure it's worth it. I should imagine it's a compression issue with some obscure thing from the past but this must be a very rare occurrence for code that isn't updated that often anyway. Perhaps "neverland" means something to you; other than little boys who don't want to grow up of course...

[saga]

I uploaded an MP3 file, id3v2-comment.mp3, where XMPlay fails to display the ID3v2 comment. I suspect it's because it's a rather long text (around 15KB).

[Ian @ un4seen]

Yes, XMPlay does currently ignore individual ID3v2 tags that are over 10000 bytes long.

[OSH]

Well, I have problem with attached file. It crashes XMPlay instantly. This isn't problem with Delix, because it can be played even without Delix (what is a big surprise for me). This is problem with XMPlay itself, specifically version 3.8.2.x. Up to 3.8.1 playback is perfect...

[Ian @ un4seen]

That crash is related to the file's "last modified" time, which XMPlay wasn't verifying as valid. Here's an update to fix that:

   www.un4seen.com/stuff/xmplay.exe

[OSH]

Thanks Ian for you quick reaction!

[guest]

XMPlay doesn't  play instrument 8, for example in order 1:
ftp://ftp.modland.com/pub/modules/Impulsetracker/Ceekayed/ancardia.it

[saga]

Seems to be a side-effect of the odd "created with" value in the header. Whether IT 1.0 instruments should be used should be determined by the "Cmwt" ("compatible with") header value, not "Cwt/v".

[thanos]

Tried the most recent version (3.8.3.4) of xmplay and encountered an annoying bug where the program crashes whenever I hit the random track button at the exact same time the current track is ending. The timing doesn't even have to be that precise, I succeeded to crash xmplay about 4/5 of the times when I tried this delibrately.

Annoying! I don't know the exact cause but the crash doesn't happen in my previous edition (3.8.0.5) that I've been using for years