I am currently comparing XMplay (using 3.8.3.4 right now) to Audacious for Linux. The latter is really bad with hotkey config (like other apps on Linux, too), but I don't want to go into detail unless requested. (rant risk)
Audacious has a compatibility mode for Windows where it can interpret \ in the playlist as /. (I am testing with PLS files. I assume it is similar for other formats.) XMPlay does it, too, without pointing it out as an option. So this would, in theory, allow interoperability of playlists between two such systems.
But the problem is that neither can save playlists properly for this purpose:
If you save the playlist to D:\MUSIC\FOLDER1, it saves paths for files in there without folder structure of course, starting right with the filename:
song.mp3
But if that playlist also contains files from FOLDER2, then it bases the path on the root instead of a truly relative path.
What it does: \MUSIC\FOLDER2\song.mp3 (This does not work on Linux then, because it embeds Windows partitions differently in its directory structure. XMPlay omits the drive letter, so it goes half the way.)
What it should do: ..\FOLDER2\song.mp3 (Which is actually less interpretative effort and a truly relative path. And since compatibility/flexibility is the whole point of relative paths, this is how it should be doing it.)
Furthermore, this could even be considered a privacy / information disclosure issue, if you are really pushing the correctness. Such a playlist potentially exposes additional folder structure that is of no concern to it.
Audacious does the same, just that it adds its own directory structure in front, which contains Linux-exclusive elements.
Which is actually doubly frustrating, because it means even if XMPlay does this properly, then sharing and updating the playlist still only works one way. (And I CBA to see whether I can conveniently contact the Audacious devs to suggest such a change.)
Considering both players do it this way, I am wondering whether there is a really good reason why dotted paths are not used.
