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

Ian @ un4seen · « **Reply #500 on:** 14 Sep '17 - 15:39 »

Oops! Here's an update to fix that:

www.un4seen.com/stuff/xmplay.exe

This update also moves the info window text buffer to the heap (rather than the stack). It's still limited to 40 KB, but at least any overflows won't corrupt the stack now.

saga · « **Reply #501 on:** 18 Sep '17 - 16:14 »

Without doubt this module here is corrupted: https://modarchive.org/index.php?request=view_by_moduleid&query=107890
However, it seems that XMPlay may read from some uninitialized memory when decoding the patterns, which it definitely should not do.
If you load this MOD file and some other file(s) alternatingly several times in a row, you should be able to observe in the pattern vis that the content of the first played pattern changes occasionally.

Ian @ un4seen · « **Reply #502 on:** 21 Sep '17 - 16:23 »

Yep, if a MOD file ends in the middle of the pattern data, then XMPlay will currently be repeatedly reading (from memory) the 4 bytes after the end for every row after that. I will sort it for the next update.

sveakul · « **Reply #503 on:** 10 Oct '17 - 04:28 »

Is it possible to add display values corresponding to "bitrate" and "sample rate" to the optional formatting string choices in the Titles option?

Ian @ un4seen · « **Reply #504 on:** 10 Oct '17 - 18:02 »

Unfortunately, that isn't possible currently because the bitrate and sample rate info isn't retained by XMPlay; it only has that info for the file that is currently playing.

sveakul · « **Reply #505 on:** 11 Oct '17 - 04:37 »

OK thanks for the info Ian! Something for the "Wishlist" then

saga · « **Reply #506 on:** 12 Oct '17 - 11:31 »

Has anyone else noticed that XMPlay (for quite a while now) occasionally drags two adjacted playlist entries even though only one of them is visibly selected? I cannot quite tell how to reproduce it because it's random, but it's happening all the time to me - it's rather annoying.

saga · « **Reply #507 on:** 15 Nov '17 - 17:52 »

There are two "flavours" of 8xx panning found in MOD files: IT/XM-like, ranging from 800 to 8FF, and S3M-like, from 800 to 880 + 8A4 for surround. For example, Dimension 2012 by Necros uses the latter. XMPlay seems to use the former way unconditionally. However, it's relatively easy to tell the two pan modes apart heuristically. What OpenMPT does is checking if there are any panning commands > 88F (not > 880 as one might assume, to allow for some notation mistakes found in some modules) that are not 8A4. If such commands are not found, panning should be interpreted as 7-bit panning + surround.

Ian @ un4seen · « **Reply #508 on:** 17 Nov '17 - 18:02 »

Thanks, here's an update that does what you describe:

www.un4seen.com/stuff/xmplay.exe

Let me know if you find it still has trouble with any files.

aspertyx · « **Reply #509 on:** 22 Nov '17 - 17:19 »

While listening to BBC Radio3 http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio3_mf_p, XMPLAY "glitches" or stutters for a few seconds every minute or so. XMPLAY plays other internet radio stations perfectly. I notice that the Track Info page blanks out momentarily when this occurs. XMPLAY 3.8.2.37 is installed. I do not see this glitch playing the BBC3 stream wih PotPlayer. I prefer using XMPLAY. Suggestions?

beanzncheeze · « **Reply #510 on:** 24 Nov '17 - 08:21 »

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

saga · « **Reply #511 on:** 24 Nov '17 - 11:33 »

Make sure that Options & Stuff -> Misc -> Allow multiple instances is not checked.

Ian @ un4seen · « **Reply #512 on:** 24 Nov '17 - 16:04 »

Quote from: aspertyx on 22 Nov '17 - 17:19

While listening to BBC Radio3 http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio3_mf_p, XMPLAY "glitches" or stutters for a few seconds every minute or so. XMPLAY plays other internet radio stations perfectly. I notice that the Track Info page blanks out momentarily when this occurs. XMPLAY 3.8.2.37 is installed. I do not see this glitch playing the BBC3 stream wih PotPlayer. I prefer using XMPLAY. Suggestions?

That sounds like the server connection is dropping and XMPlay is reconnecting. To confirm that, is the time display resetting to 0:00 too? I don't currently seem to be able to reproduce that here. Is it always happening for you there, or only sometimes? Does increasing the buffer size in the Miscellaneous options page help?

You could try the radio 3 HLS stream instead:

http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_three.m3u8

If you're in the UK, you can use this higher bitrate one:

http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/uk/sbr_high/ak/bbc_radio_three.m3u8

beanzncheeze · « **Reply #513 on:** 25 Nov '17 - 03:30 »

Yess!!!!
I swear I tried that... well... Thanks so Much!!!

gul · « **Reply #514 on:** 2 Dec '17 - 23:36 »

Hello everyone,

Excuse my bad English, this is a translation made with the Google translator ...

I am using win7x64-SP1 and a RME Babyface-Pro USB sound card.

For several months and even years I have noticed that mono files reproduce with a slight imbalance but did not give importance.

Today I discovered that it can be a bug in the ASIO output plugin (revision 7a) because using the WASAPI output plugin (revision 4) the playback is perfect.

To confirm all this I used this test file 0_16_96.wav 1 kHz sine, 0 dBFS, 16 bit mono wave file, 96 kHz sample rate downloaded from http://www.rme-audio.de/en/downloads/tools. php # 5 in the following way and results:

1- I play it with XmPlay and ASIO output device - Fireface USB. The DIGICheck Vector Audio Scope shows:

2- Now change to WASAPI output and the results are perfect:

3- To rule out that the problem is in the ASIO driver of my RME Babyface-Pro I now play the 0_16_96.wav in Samplitude_ProX3_Suite with the ASIO - Fireface USB output, perfect result also:

Have any of you also seen this behavior?
Can anyone confirm that the ASIO output plugin (revision 7a) behaves that way?

Thanks in advance.
regards

Ian @ un4seen · « **Reply #515 on:** 4 Dec '17 - 16:36 »

Just to be sure, do you have XMPlay's balance slider set to "centre"? The ASIO plugin does not apply the balance setting itself, so if there is a bug, it will probably be in XMPlay. If you have not already done so, please try this latest XMPlay build:

www.un4seen.com/stuff/xmplay.exe

Let me know if you still get the problem with that.

gul · « **Reply #516 on:** 4 Dec '17 - 23:28 »

Quote from: Ian @ un4seen on 4 Dec '17 - 16:36

Just to be sure, do you have XMPlay's balance slider set to "centre"? The ASIO plugin does not apply the balance setting itself, so if there is a bug, it will probably be in XMPlay.

That was the problem! tremendous mistake on my part!
I'm ashamed, I'm so sorry!

The skin I have been using for several years, Windows Cassic 2.1, has no balance control so I could not see it.
All correct with version 3.8.2.32. I'll try the one you tell me here.

Thanks for your time.
Best regards.

Javier.

Sajadi · « **Reply #517 on:** 8 Dec '17 - 18:56 »

As the dev of the XMPlay SID plugin seems not to respond anymore, the issue is XMPlay with the latest version of the plugin is crashing quite often after playing a couple of random sid tracks. Perhaps you can do something against it?

saga · « **Reply #518 on:** 9 Dec '17 - 12:44 »

Quote from: Ian @ un4seen on 17 Nov '17 - 18:02

Thanks, here's an update that does what you describe:

www.un4seen.com/stuff/xmplay.exe

Let me know if you find it still has trouble with any files.

I forgot one detail that OpenMPT does to fix some files like this one: If there are no pannings values < 0x80, 8-bit panning is also assumed. This helps when all channels are centered in the 8-bit panning scheme.

Azevedo · « **Reply #519 on:** 10 Dec '17 - 17:07 »

I'm using v3.8.10 but this is an old bug...

When loading a playlist, if the first track (random) of playback is missing xmplay ~~striketrough~~ the track but does not play the next track.

The option Playlist / List advancing / [ ] Stop at dead track only works if the dead track is not the first in the playback

saga · « **Reply #520 on:** 16 Dec '17 - 14:16 »

Instrument 12 and 13 in this IT have some negative volume envelope values. IT itself seems to get confused by this as well, but clamping them to 0 plays the song as intended. This is what Schism Tracker already did and OpenMPT does now, too. BASS/XMPlay should probably follow.

FIX94 · « **Reply #521 on:** 26 Dec '17 - 01:42 »

Just updated to 3.8.3 and I think something with the aac/alac/mp4 detection is not quite right or too aggressive or something, attached an example file. Normally it should get picked up by the dedicated .mdx plugin I have in my plugins folder but instead gets assigned its filename as title and a 0:00 length and when I attempt to play it, xmplay crashes saying something went wrong with the media foundation codecs. In older versions (newest one I tested was 3.8.2.39) it works just fine. Also, setting the plugin file extension priority does not seem to help either, the internal detection still picks it up instead.

Ian @ un4seen · « **Reply #522 on:** 27 Dec '17 - 16:34 »

Oops. Here's an update that should fix that:

www.un4seen.com/stuff/xmplay.exe

Let me know if you still get the problem happening.

FIX94 · « **Reply #523 on:** 27 Dec '17 - 18:53 »

Quote from: Ian @ un4seen on 27 Dec '17 - 16:34

Oops. Here's an update that should fix that:

www.un4seen.com/stuff/xmplay.exe

Let me know if you still get the problem happening.

Thanks, already working better, tracks now play back fine again, but interestingly enough they still show up wrong when I just drop them into the playlist with the filename as title only, the correct title only loads once I play them back so I assume only them does the plugin get used.

Ian @ un4seen · « **Reply #524 on:** 28 Dec '17 - 17:38 »

Is the track info not appearing at all or is it just delayed? When adding new files to the playlist/library, only the file's format is checked (not its tags/etc), so that the files can be added more quickly. The track info is scanned afterwards. By default, XMPlay will check the existence of all files in the playlist/library at launch, to find any dead ones. That is done by the same thread that does the info scanning, so the info scanning could be delayed by it. You can check whether XMPlay has finished checking for dead tracks by opening the "Playlist -> Dead" options page (it'll say "scanning" if not finished). You can also disable the scanning there, via the "Check for dead tracks upon launch" option.

If the info isn't appearing at all (before playing the file), please upload an affected file to test with here:

ftp.un4seen.com/incoming/