4.0 reports, queries and bugs

[kakuyoshi]

I understand, thank you very much

[saga]

When scanning for missing files, XMPlay seems to take both the filename and the known filesize into account. A while ago I have recompressed a large part of my FLAC collection, and XMPlay wasn't aware of the new smaller filesize, so I believe that this is the reason why XMPlay managed to locate some missing files after moving them, but others it didn't manage to locate, even if I pointed it right at the directory containing the files. In the general case this design makes sense, but I think it would be nice to have the option to scan for missing files ignoring file size mismatches.

[piovrauz]

Here's an update that extends the "%USERPROFILE%" support (in playlists) to tool and encoder command-lines:

    www.un4seen.com/stuff/xmplay.exe

Taking your example, %USERPROFILE% would be "C:\Users\secretusername", so you could use "%USERPROFILE%\AppData\Local\ocenaudio\ocenaudio.exe".

Thanks a lot, it's doing exactly what I wanted/needed.
Took me a while to come back and check, things happened.

Oh, and the now site / forum is beautiful.
Essential and to the point, just how like it - too bad the rest of the web doesn't care.

[Knurek]

Would it be possible to add Amiga style sufix.prefix filenames handling to priority filetypes?

I'm using the Delix plugin to play some of the exotic Tracker types, and have mod as priority extension set to Delix.

If I take, for example, mod.level1 from Premiere game rip and try playing it with XMPlay, it's detected as a Generic MOD and played (extremely incorrectly) by the XMPlay PT routine.
But if I manually rename the file to level1.mod (and have the mod priority filetype in Delix set), it gets passed on to Delix and is played correctly.

Would it be possible for the module to play without having to rename it?

[Ian @ un4seen]

Would it be sufficient for XMPlay to only recognise "mod." prefixes and no others? I'm not very familiar with Amiga filenaming conventions but from what I see on download sites it seems like prefixes generally aren't used for other file formats? I'd like to minimize false filetype detections, eg. on a MIDI.TXT file.

[Knurek]

Would it be sufficient for XMPlay to only recognise "mod." prefixes and no others? I'm not very familiar with Amiga filenaming conventions but from what I see on download sites it seems like prefixes generally aren't used for other file formats? I'd like to minimize false filetype detections, eg. on a MIDI.TXT file.

I'm not 100% sure, but I think having it be restricted to mod.* should be enough...
Other formats use their own prefixes, but aren't usually structured like ProTracker modules internally, so don't cause problems from what I could gather.

[Ian @ un4seen]

I'm not 100% sure, but I think having it be restricted to mod.* should be enough...

OK, here's an update for you to try then:

    www.un4seen.com/stuff/xmplay.exe

Let me know if you have any trouble with it.

When scanning for missing files, XMPlay seems to take both the filename and the known filesize into account. A while ago I have recompressed a large part of my FLAC collection, and XMPlay wasn't aware of the new smaller filesize, so I believe that this is the reason why XMPlay managed to locate some missing files after moving them, but others it didn't manage to locate, even if I pointed it right at the directory containing the files. In the general case this design makes sense, but I think it would be nice to have the option to scan for missing files ignoring file size mismatches.

Yes, XMPlay will usually also check that the file size matches (when it's known), but the update above adds an "Ignore file size" option to the "Scan for new locations" folder selector to disable that.

[Alex Mortar]

When XM started some artifacts from other windows appears on skin. This things is only when application started. On previous versions there was never such problem. Suspect it is because of new skin color transparent engine

[Ian @ un4seen]

I haven't seen that problem so far. Is it a skin-specific issue, ie. it only happens with some skins? If so, please give examples of affected and unaffected skins to see if there's a pattern. Also, does it happen every time you start XMPlay or only sometimes? And does it also happen when switching skins? Please also confirm what Windows version you're using.

[Alex Mortar]

There is no problem with standard 4.0 skin. I tested MMD3,WAmodern and Escape and this problem appears on all of them.

https://printskrin.ru/i/snapshot-1.eBulwk


It happens every time but only when started, when switch there is no problem. I use  win 10 x64

[Ian @ un4seen]

That looks like it's probably a problem with the side panel z-order positions (they're under the other windows). Here's an update for you to try:

    www.un4seen.com/stuff/xmplay.exe

If the problem persists, please check if it also happens when the info window is closed.

[Alex Mortar]

I checked, with this update there is no problems appeared. Tested on the same skins

Thanks

[Rah3D]

Hey there! I recently noticed that dropping a file on the main window playlist's "+" button replaces the entire playlist with the song that was dropped, instead of adding it to the bottom of the playlist. This still works in the extended playlist. I remember this working in 3.X, but it might be my memory playing tricks. Is it supposed to do that?

[Ian @ un4seen]

I checked, with this update there is no problems appeared. Tested on the same skins

Great!

I recently noticed that dropping a file on the main window playlist's "+" button replaces the entire playlist with the song that was dropped, instead of adding it to the bottom of the playlist. This still works in the extended playlist. I remember this working in 3.X, but it might be my memory playing tricks. Is it supposed to do that?

Yeah, it used to be that dropping files on any part of the playlist panel would default to adding to the list (instead of replacing it), but many skins (including the 4.0 default) now have the playlist panel merged with the main panel so it can be confusing exactly what parts are the playlist panel. So now XMPlay defaults to only adding/inserting to the list if you drop the files in the actual playlist area, but you can hold down the shift key while dropping anywhere to always add to the list.

But now that you mention it, it could also be nice to have dropping on the "Add files" button adding to the list. Here's an update that should do so:

    www.un4seen.com/stuff/xmplay.exe

[Knurek]

Is it me, or are all Encoder presets broken in 4.0?
The pure WAV Writer works fine, but using Encoder presets (doesn't matter whether LAME/FLAC/OGGenc or anything I personally added) makes XMPlay crash frequently (depending on content either on second subsong or few files into the playlist).
I went back to 3.8.5 for my wavewriting setup, no crashes there.

[Ian @ un4seen]

Here's a little update for you to try:

    www.un4seen.com/stuff/xmplay.exe

If it still crashes, please provide a dump file to have a look at. You will hopefully find one in the "%LOCALAPPDATA%\CrashDumps" folder, which you can then ZIP and upload here:

    ftp://ftp.un4seen.com/incoming/

[Knurek]

Here's a little update for you to try:

    www.un4seen.com/stuff/xmplay.exe

That seems to have fixed the issue, thank you.

[winner]

Where is the "Input" menu item under DSP-> Plugins, where I used to find and work with the midi plugin???

[Rah3D]

Yeah, it used to be that dropping files on any part of the playlist panel would default to adding to the list (instead of replacing it), but many skins (including the 4.0 default) now have the playlist panel merged with the main panel so it can be confusing exactly what parts are the playlist panel. So now XMPlay defaults to only adding/inserting to the list if you drop the files in the actual playlist area, but you can hold down the shift key while dropping anywhere to always add to the list.

But now that you mention it, it could also be nice to have dropping on the "Add files" button adding to the list. Here's an update that should do so:

    www.un4seen.com/stuff/xmplay.exe

Thank you!

[Ian @ un4seen]

Where is the "Input" menu item under DSP-> Plugins, where I used to find and work with the midi plugin???

The input (and archive) plugins are now in the new "Decoders" options page, which includes the built-in decoders too.

[winner]

Where is the "Input" menu item under DSP-> Plugins, where I used to find and work with the midi plugin???

The input (and archive) plugins are now in the new "Decoders" options page, which includes the built-in decoders too.

Wow, OK. Big change. I wasn't aware of that. Thanks.

[winner]

I am trying to use XMPlay to encode a wav file to MP3. I have set the output to the lame encoder. But I get error "can't start encoder." Please assist to get this to work.

[saga]

The new advanced drag&drop in XMPlay 4.0 can be quite useful at times, but I feel that most of the time it hinders my playlist editing. If I wanted to move a track a long way across the playlist, for example, I could just drag it way outside of the XMPlay window, which would then move it in the playlist very quickly. Now, dragging it outside of the window does something completely different.
Maybe as a compromise, to keep both features possible, the advanced drag&drop could only be activated when e.g. the Shift key is held, and the old behaviour is used when it's not held?

Also, I find myself wanting to search song lyrics quite often. Would it be possible to extend the XMPlay library with an additional field that would be populated with the usual ID3 and Vorbis tags for unsynced (and I guess also synced, if available) lyrics?

[Ian @ un4seen]

I am trying to use XMPlay to encode a wav file to MP3. I have set the output to the lame encoder. But I get error "can't start encoder." Please assist to get this to work.

Do you definitely have the LAME.EXE file in the same folder as XMPLAY.EXE? If you aren't already using it, please also try the latest XMPlay build:

    www.un4seen.com/stuff/xmplay.exe

The new advanced drag&drop in XMPlay 4.0 can be quite useful at times, but I feel that most of the time it hinders my playlist editing. If I wanted to move a track a long way across the playlist, for example, I could just drag it way outside of the XMPlay window, which would then move it in the playlist very quickly. Now, dragging it outside of the window does something completely different.
Maybe as a compromise, to keep both features possible, the advanced drag&drop could only be activated when e.g. the Shift key is held, and the old behaviour is used when it's not held?

I think the current behaviour should probably stay the default because it seems more standard (eg. like File Explorer) and so more intuitive to most people? But perhaps it can be tweaked to scroll the list more quickly. I'll look into that and hopefully come back with something for you to try.

Also, I find myself wanting to search song lyrics quite often. Would it be possible to extend the XMPlay library with an additional field that would be populated with the usual ID3 and Vorbis tags for unsynced (and I guess also synced, if available) lyrics?

I'll look into this too. Note it would break back-compatibility, ie. it wouldn't be possible to use the library with an older XMPlay build afterwards.

[saga]

I'll look into this too. Note it would break back-compatibility, ie. it wouldn't be possible to use the library with an older XMPlay build afterwards.

If compatibility already needs to be broken anyway, maybe it would be an opportunity to design new field extensions in a way that would remain backwards-compatible using key/value pairs, assuming that older XMPlay versions would then keep unknown keys in the library even when modifying it?