Topic: 3.8 reports, queries and bugs

[guest]

"Separate subsongs" option does not separate all selected library entries ("Separate subsongs" option returns more playlist entries for the same content).

For example, HVSC #80 contains 58150 SID files.
After adding all SID files to an empty playlist, selecting all and separating subsongs, there are 83721 entries.
After adding all SID files to an empty library, selecting all and separating subsongs, there are:
- 79881 entries if the library is sorted ascending by file size
- 79682 entries if the library is sorted descending by file size.

[Jackalope]

Thank you very much for the reply and explanation.

(While I'm here, thank you for XMPlay, too!  It took no time at all to be totally sold on switching from Winamp.)

[Ian @ un4seen]

For example, HVSC #80 contains 58150 SID files.
After adding all SID files to an empty playlist, selecting all and separating subsongs, there are 83721 entries.
After adding all SID files to an empty library, selecting all and separating subsongs, there are:
- 79881 entries if the library is sorted ascending by file size
- 79682 entries if the library is sorted descending by file size.

Here's an update that should fix the problem:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still see it happening.

[guest]

This MTM should probably have no subsongs, but XMPlay detects 7.

[Ian @ un4seen]

Oops, it seems XMPlay should be ignoring "F00" effects in MTM files. Here's an update that does so:

   www.un4seen.com/stuff/xmplay.exe

[saga]

Something goes a bit wrong with the end-of-song calculation for this track:
https://files.scene.org/view/parties/2018/nordlicht18/tracked_music/triace_-_zappeldisco-geblinke.zip

XMPlay reports a length of 3:31 (which is consistent with OpenMPT), but once it reaches that position, it continues playing even if looping is disabled. The song does not stop or fade out.

Speaking of song lengths, can you please check my question here? http://www.un4seen.com/forum/?topic=15448.msg142639#msg142639

[guest]

• XMPlay reports duration of 0:39 but the playback of this module stops at 0:00.

• After loading the saved settings with the reduction auto-amp set to e.g. +20 dB for this MOD, the amplification slider starts jumping back and forth.

[Ian @ un4seen]

Something goes a bit wrong with the end-of-song calculation for this track:
https://files.scene.org/view/parties/2018/nordlicht18/tracked_music/triace_-_zappeldisco-geblinke.zip

XMPlay reports a length of 3:31 (which is consistent with OpenMPT), but once it reaches that position, it continues playing even if looping is disabled. The song does not stop or fade out.

The end detection is a bit different during length scanning and playback. The length scanning will check for a loop in the file at every row (after considering pattern loops), while playback will only check for a loop at an order number change. I don't remember the reason for that, but I would guess it was to avoid possibly ending too early with dodgy pattern loops. In this file's case, the pattern data is never-ending but the loop point isn't on a pattern break (it's on the 2nd row of order 36), so unfortunately it isn't detected during playback.

]XMPlay reports duration of 0:39 but the playback of this module stops at 0:00.

This is similar to the case above, but here's an update that should help:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you see this cause ending problems for other files, eg. perhaps they become never-ending.

After loading the saved settings with the reduction auto-amp set to e.g. +20 dB for this MOD, the amplification slider starts jumping back and forth.

I don't seem to be able to reproduce this. I guess it may depend on what settings are used, so please also upload your XMPLAY.SET and XMPLAY.INI files to show what settings you're using:

   ftp.un4seen.com/incoming

[guest]

After loading the saved settings with the reduction auto-amp set to e.g. +20 dB for this MOD, the amplification slider starts jumping back and forth.

I don't seem to be able to reproduce this. I guess it may depend on what settings are used, so please also upload your XMPLAY.SET and XMPLAY.INI files to show what settings you're using:

   ftp.un4seen.com/incoming

This happens when saved setting is auto-loaded.
I uploaded settings to ftp.

[Ian @ un4seen]

The problem still isn't happening here even with those settings. When starting playback of the MOD file, the amp slider immediately drops down to -3.2dB and stays there.

If you delete your XMPLAY.INI file for a fresh config and then put back the "AutoPreset" line, does it still happen?

[guest]

This only happens when "Automatically load saved settings" option is active.

[Ian @ un4seen]

The problem isn't happening here even with that enabled.

Does it still happen there after you reset your config (delete XMPLAY.INI), and only put back the "AutoPreset" line and enable "Automatically load saved settings"?

[guest]

Yes, I also noticed that this occurs when I manually set the amplification slider to +20 dB during playback.

[Ian @ un4seen]

OK, so the saved settings don't matter? In that case, does it happen if you reset the config (delete XMPLAY.INI) and then just set the amp slider to +20dB and auto-amp to "reduction"? And does it still happen if you set a lower amp level (eg. +19dB) or different auto-amp mode?

[guest]

This seems to happen in all auto-loaded auto-amp modes (with one exception: Fade-in + "Reset on new track" is enabled).
For lower values (eg. 18-19 dB) the slider jumping sometimes takes a short time.
When auto-loading is disabled and "Reset on new track" is enabled when playback starts, the problem does not occur, but can be triggered manually by adjusting the slider eg. to 20 dB.

I uploaded a screen recording to ftp showing what it looks like.

[saga]

I uploaded a file, "22 - Vessel.mp3", that shows a very strange peak value of -1.#J dB in the info window. Playback works as intended, so I'm more concerned if XMPlay's float formatting. I believe that this may either mean that the value stored in the file is -inf or NaN - which both don't make much sense as a Peak value and should probably be ignored / not displayed.

[Ian @ un4seen]

This seems to happen in all auto-loaded auto-amp modes (with one exception: Fade-in + "Reset on new track" is enabled).
For lower values (eg. 18-19 dB) the slider jumping sometimes takes a short time.
When auto-loading is disabled and "Reset on new track" is enabled when playback starts, the problem does not occur, but can be triggered manually by adjusting the slider eg. to 20 dB.

I uploaded a screen recording to ftp showing what it looks like.

Ah, I know what it is now. If there's a brief large spike in the level then auto-amp will restore the previous level afterwards (in case the spike was just due to corruption). In this file's case, it's all brief spikes, so the auto-amp bounces back and forth. Here's an update with a little tweak to reduce that:

   www.un4seen.com/stuff/xmplay.exe

I uploaded a file, "22 - Vessel.mp3", that shows a very strange peak value of -1.#J dB in the info window. Playback works as intended, so I'm more concerned if XMPlay's float formatting. I believe that this may either mean that the value stored in the file is -inf or NaN - which both don't make much sense as a Peak value and should probably be ignored / not displayed.

Oops, XMPlay is incorrectly assuming LAME info follows the file's "Xing" VBR header and so ends up reading random Replaygain values. The update above should fix that.

[guest]

Ah, I know what it is now. If there's a brief large spike in the level then auto-amp will restore the previous level afterwards (in case the spike was just due to corruption). In this file's case, it's all brief spikes, so the auto-amp bounces back and forth. Here's an update with a little tweak to reduce that:

   www.un4seen.com/stuff/xmplay.exe

This still happens for this module when MOD pan separation is set to 100.

[XMGabe]

I use multiple devices with Onedrive to sink my stuff, included my favourite musics and my XMPLAY configurations. Would it be possible to have the library memorize the paths to music files with the user profile path environment variable? As of now it records them with the full absolute path, eg. "C:\Users\username\onedrive\music\mytune.mp3", while ideally it should use: "%USERPROFILE%\Onedrive\music\mytune.mp3", this would make the library "portable" and available no matter what the original profile path is, and would work with other cloud storage solutions.

The update above adds support for this. If it works well then it may be enabled by default, but for now you can enable it by adding a "UserProfile=1" line to your XMPLAY.INI file. I don't think it'll cause any problems, but you should probably backup your XMPLAY.LIBRARY and XMPLAY.PLS files first just in case.

Thanks a lot mate, this works like a charm! And i noticed it even automatically "fixed" all my previous library entries.

So far, so good - will let you know if some problems come up.

Gabriel

[saga]

I think the tremor effect must have broken a while ago. In the attached example, XMPlay mutes the first phase of the tremor effect and plays the second phase, but it should be the other way around: The beeps should trigger together with the bass drum, but they trigger on the off-beat instead!

[Ian @ un4seen]

This still happens for this module when MOD pan separation is set to 100.

The post-spike amp level restoring was mainly to recover from the amp level dropping very low while suppressing loud noises from corrupt MP3 data, but the MP3 decoder does a better job of suppressing corrupt noises itself these days, so the amp level restoring might not be needed any more. Here's an update that disables it:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you start seeing the amp level drop very low with corrupt MP3 (or other format) files.

I think the tremor effect must have broken a while ago. In the attached example, XMPlay mutes the first phase of the tremor effect and plays the second phase, but it should be the other way around: The beeps should trigger together with the bass drum, but they trigger on the off-beat instead!

It looks like that was changed in XMPlay 3.8.2 for some unknown reason. The update above puts it back how it was. Please let me know if you now hear broken tremor in other S3M files.

[saga]

It looks like that was changed in XMPlay 3.8.2 for some unknown reason. The update above puts it back how it was. Please let me know if you now hear broken tremor in other S3M files.

Thanks, that sounds better! Note that Scream Tracker does not reset the tremor counter when restarting playback (and also not when loading another module), so it could be that an observation was made regarding the tremor effect after playing two different songs one after another in Scream Tracker (or just playing the same song twice) and the change was made based on the observeration. This behaviour certainly threw me off when building the test case in ST3...

[saga]

Shared effect memory in S3M modules appears to have broken a while ago... In the attached example module, both channels should fade out at the same rate (the H81 parameter is transferred to the K command as K81, which effectively results in a K01 command). Most famously this breaks Satellite One by Purple Motion, although in that case XMPlay currently somehow still manages to apply a volume fade (but it's way too fast), so I'm not exactly sure how this broke.

[Ian @ un4seen]

It seem like the S3M "Hxx" effect writes to the shared effect memory even though it doesn't read from that, eg. "Hxx" affects "D00" but "Dxx" doesn't affect "H00". Here's an XMPlay update that should do the same:

   www.un4seen.com/stuff/xmplay.exe

Please let me know if you still see any problem with it.

[saga]

Fix confirmed.
Indeed, all effect commands (including the "empty" effect that doesn't do anything, so really just any non-zero parameter in the pattern data) write to the shared effect memory, but only the following commands read from it: Dxy, Kxy, Lxy, Exx, Fxx, Ixy, Jxy, Qxy, Rxy, Sxy. Hxy and also Uxy have their own memory (they have to, for command Kxy to work correctly). The same is true for command Gxx for a similar reason (sharing its memory with Lxy).