3.8 reports, queries and bugs

Started by Dotpitch,

Guest

I'm not sure what's going on with the latest EXE, but any modules I play that it supports by default will say "buffering..." and then crash... I've just been using the normal 3.8.5 EXE ever since but I'm not sure what's causing that that issue.  ???

winner

Quote from: GuestI'm not sure what's going on with the latest EXE, but any modules I play that it supports by default will say "buffering..." and then crash... I've just been using the normal 3.8.5 EXE ever since but I'm not sure what's causing that that issue.  ???
I can confirm this behavior with version 3.8.5.12 when trying to play .mod files.

Ian @ un4seen

Oops! Been a few mishaps recently ;D ... This one is when the output isn't set to 32-bit. Here's an update to fix it:

   www.un4seen.com/stuff/xmplay.exe

Guest


saga

There is an issue with the portamento between two different instruments in this tune: https://modarchive.org/module.php?60896 (right in the second pattern)
Using PT1 mode fixes it, but I think the current behaviour doesn't make a lot of sense in either mode.

Ian @ un4seen

Here's an update to get that file sounding better in "normal" MOD mode:

   www.un4seen.com/stuff/xmplay.exe

The change is in what happens when an instrument is used without a note. Please let me know if you find that's now broken for other files in "normal" MOD mode.

saga


Ian @ un4seen

The XMPlay 3.8.5 and 3.8.4 release versions seem to sound the same, so I guess the issue has been there a while, perhaps forever? From the note range used in the file, it doesn't look like it is actually meant to be played in PT1 mode? Still, I'll try to get it sounding closer to real PT1.

saga

Good point, it doesn't look like a ProTracker module. I mostly tried PT1 mode because the module uses Invert Loop, which requires PT1 mode in XMPlay. So in the end it looks more like XMPlay needs another way to enable EFx commands without enforcing PT1 limits... OpenMPT just supports them unconditionally, no matter which type of MOD file, and I'm not aware of any issues so far. Maybe XMPlay could enable EFx support by default as well?

Ian @ un4seen

Here's an update that enables the EFx effect in normal MOD mode too (still disabled in FT2 mode):

   www.un4seen.com/stuff/xmplay.exe

This update should also bring PT1 mode closer in accuracy, by having the arpeggio period/freq wraparound when that exceeds the limit, instead of capping it (like ST3 Amiga limits does).

saga

Yup, that both sounds good. Thanks for the fix!

brycco

Found some MOD playback bugs while working on a tune.

1. Tempo or Speed is handled incorrectly.
2. Volume change is delayed with EDx: Note Delay, but it should be instantaneous (unintuitive but that's PT...)

Ian @ un4seen

The tempo issue is caused by the file being detected as requiring VBlank timing. Here's an update that should fix that, and the note delay volume issue in PT1 mode (doesn't apply in normal/FT2 modes):

   www.un4seen.com/stuff/xmplay.exe

Ivan Lewis-Coker

I've got the opposite problem to the one described below. I *WANT* a separate instance of XMPlay to open when I click on an mp3 file in File Explorer.

I've checked "Allow multiple instances", but the newly clicked mp3 replaces whatever was playing in the current instance instead of opening a new one.  ???

Is this a bug?

Regards,

Ivan

Quote from: beanzncheezeApologies if I'm 50 ways ta Sunday wrong for posting here.
I just found your player yesterday and love it! Thanks

However I seem to have a problem, when playing flac files.

When I open a Folder with some flac files and click on a song everything is groovy, (it plays) but if I proceed to click on another song (while the player is still playing the other song) it will proceed to play the second song ok but in a separate (newly opened player) so both songs are playing at the same time in two separate players. And each new song I click on opens a new player all playing each song at the same time.

It doesn't happen with mp3's they are functioning normal, if I'm playing a mp3 then click on another the player will release that song and start the new song (in the same player) as it should.

Is this a bug? or something I'm doing wrong such as missing some plugin? 
I'm on window 10 32bit with the latest player.

thanks

Ian @ un4seen

Windows Explorer will send the files to an already running instance if there is one. I'm not sure there's any way to change that.

Enabling the "Allow multiple instances" option should allow you to launch multiple instances of XMPlay but it won't change Windows Explorer's behaviour.

tails__

There seems to be an issue with playlist format string when playing audio from URL. NoScanList=1 is set in xmplay.ini if it helps.

I use separate formats for extended list and normal one respectively:
%?5{%5 |}%?2{%2 - |}%?1{%1|%0}%?3{ [%3]|}
%?5{%5 |}%?1{%1|%0}

Now, if I try to open an URL from playlist which has title defined it looks like this:


If I however put "%1" into title format I get normal title from M3U, so somehow %?1 returns false here.



Ian @ un4seen

Please post the playlist file to check what's happening with it (you can PM it if it's private).

tails__

Hello Ian,

Here is an example file, URLs appear to be IP-locked and probably won't play.

Ian @ un4seen

The issue in this case is that XMPlay doesn't actually have any tags, so "%?1" is indeed false. XMPlay only has a preformatted title from the playlist ("#EXTINF" line), which it will use for the main title when there are no tags, but that isn't currently used for the separate "Playlist panel" title. I guess that could be changed, even though it won't necessarily match the specified format. Here's an update that does so, for you to try:

   www.un4seen.com/stuff/xmplay.exe

tails__

Thanks, this works exactly as expected now :)

IMHO pre-formatted title still counts as track title, pretty much like the one older Winamp plugins return.

brycco

#795
Thanks for the previous bug fix! Here is another possible .MOD issue.

PT1 mode: This song seems to expose a possible edge case when vibrato continue (400) is used with sample swapping:

http://amp.dascene.net/modules/J/Juice(CR)/MOD.cryptomnesia.gz

basically it sounds a bit steppy when it should sound smooth, possibly resetting the period when it shouldn't.

It is subtle, but should be noticable when isolating channel 0 and comparing the audio between OpenMPT and PT2-clone.


By the way, why is PT1 mode not called PT2 if it's specifically trying to match PT 2.x behaviour?

Ian @ un4seen

It's called PT1 mode because it is trying to emulate ProTracker v1 :)

I isolated the 1st channel in the linked MOD file and played it with ProTracker v1.3 (under WinUAE emulator) and with XMPlay's "PT1" mode, and they sounded very similar, ie. not quite as smooth as the "normal" MOD mode. If you're sure there's a problem, is it especially noticeable at a particular position in the MOD?

brycco

#797
Sorry for late reply. Here are two test cases that hopefully highlight what I'm hearing and proves I'm not crazy  :).

Firstly, I did all testing with interpolation and ramping "OFF".

Test1.mod exhibit two issues:
 - vibrato depth/speed sounds wrong
 - contains noise or aliasing due to higher root note?

Test2.mod exhibits only the first issue:
 - vibrato depth/speed sounds wrong

I find it odd that Test2 does not have the noise problem.

To produce the test cases, I just took specific sections of pattern 1 and modified the vibrato until it was more noticeable, and increased the tempo.

I included .opus recordings comparing PT2Clone / OpenMPT / XMPlay in that order.

Edit: I added another Test3.mod as a separate attachment. It shows more 'noise' or aliasing, with less clear sample swapping transitions in XMPlay than in other players. Taken from pattern 18.

Hmm the noise I'm hearing seems to be solved by the "Amiga resampler" feature that PT2Clone and OpenMPT use. Perhaps that would be a good addition to XMPlay?

garson

I'm having issue playing radio stream with XMPlay (latest stuff 3.8.5.20).

So I have this mp3 stream working fine:
https://maggie.torontocast.com:8020/mp3-320

But aac version is having issue:
https://maggie.torontocast.com:8020/aac-320

It plays for 4 seconds and then restarts by itself, like you double clicked again on the stream. And it happens every 4 seconds.
This is with built in aac decoder. I've tried with AAC plugin and it works fine.

In web browser this stream works fine.

Could this be related to XMPlay or its built-in aac decoder?

Sebby75

Quote from: garsonIt plays for 4 seconds and then restarts by itself, like you double clicked again on the stream. And it happens every 4 seconds.
This is with built in aac decoder. I've tried with AAC plugin and it works fine.



Same behaviour here with that stream..
Works fine with xmp-aac.dll (rev 7) but stops after 4 seconds without that plugin..