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

Guest

  • Guest
Re: 3.8 reports, queries and bugs
« Reply #775 on: 3 Mar '21 - 23:54 »
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

  • Posts: 306
Re: 3.8 reports, queries and bugs
« Reply #776 on: 4 Mar '21 - 00:16 »
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.  ???
I can confirm this behavior with version 3.8.5.12 when trying to play .mod files.

Ian @ un4seen

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #777 on: 4 Mar '21 - 17:10 »
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

  • Guest
Re: 3.8 reports, queries and bugs
« Reply #778 on: 4 Mar '21 - 17:47 »
Works now, thanks for the fix! ;D

saga

  • Posts: 2749
Re: 3.8 reports, queries and bugs
« Reply #779 on: 27 Mar '21 - 23:31 »
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

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #780 on: 30 Mar '21 - 16:31 »
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

  • Posts: 2749
Re: 3.8 reports, queries and bugs
« Reply #781 on: 6 Apr '21 - 23:01 »
It seems like combining instrument swaps with arpeggios is now broken in PT1 mode: https://modarchive.org/index.php?request=view_by_moduleid&query=191419

Ian @ un4seen

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #782 on: 8 Apr '21 - 17:54 »
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

  • Posts: 2749
Re: 3.8 reports, queries and bugs
« Reply #783 on: 8 Apr '21 - 18:13 »
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

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #784 on: 9 Apr '21 - 17:12 »
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

  • Posts: 2749
Re: 3.8 reports, queries and bugs
« Reply #785 on: 9 Apr '21 - 21:58 »
Yup, that both sounds good. Thanks for the fix!

brycco

  • Posts: 41
Re: 3.8 reports, queries and bugs
« Reply #786 on: 5 May '21 - 14:21 »
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

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #787 on: 7 May '21 - 16:01 »
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

  • Guest
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

Apologies 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

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #789 on: 11 May '21 - 16:28 »
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__

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #790 on: 12 May '21 - 15:20 »
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

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #791 on: 19 May '21 - 16:55 »
Please post the playlist file to check what's happening with it (you can PM it if it's private).

tails__

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #792 on: 20 May '21 - 07:59 »
Hello Ian,

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

Ian @ un4seen

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #793 on: 21 May '21 - 16:17 »
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__

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #794 on: 21 May '21 - 18:46 »
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

  • Posts: 41
Re: 3.8 reports, queries and bugs
« Reply #795 on: 2 Jun '21 - 12:51 »
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?
« Last Edit: 2 Jun '21 - 13:04 by brycco »

Ian @ un4seen

  • Administrator
  • Posts: 26102
Re: 3.8 reports, queries and bugs
« Reply #796 on: 3 Jun '21 - 15:58 »
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

  • Posts: 41
Re: 3.8 reports, queries and bugs
« Reply #797 on: 6 Jun '21 - 04:06 »
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?
« Last Edit: 6 Jun '21 - 04:46 by brycco »

garson

  • Posts: 181
Re: 3.8 reports, queries and bugs
« Reply #798 on: 14 Jun '21 - 21:58 »
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

  • Guest
Re: 3.8 reports, queries and bugs
« Reply #799 on: 14 Jun '21 - 22:53 »

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.



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