Author Topic: Suggestions for 3.9  (Read 89431 times)

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: Suggestions for 3.9
« Reply #350 on: 10 Aug '17 - 17:28 »
I'm using an ultra high resolution monitor and the default skin is nearly unreadable, but the 'hours' is shown - the skin I'm using I got from someone on another forum and it appears that when the "font_listsize" and "font_listnumsize" is set above about 48-52 points it cuts the 'hours' off. When I drag and drop a track that's over an hour into the playlist it cuts off the 'hours'  and that's true whether for not the 'type' column is active or not. But, switching skins back and forth or restarting xmplay it displays correctly.Also this is with the playlist panel and not when the playlist is incorporated into the main panel- I hope that makes sense.

Please upload that skin to have a look at here:

   ftp.un4seen.com/incoming/

Can the 'Total time/count display' be given it's own setting in 'skinconfig.txt' maybe a new parameter 'font_listtimesize' can be created so that the size can be set independently - right now it uses the 'font_listnumsize' which is also used as the playlist track number/time.

Yes, I think that can be arranged.

I haven't noticed that before, but apparently there's a need for correction on how XMPlay's maximum text width works:



Here, I set it to 24 characters and used absurdly long path with a long album title. As can be seen the text is broken between letter characters but as Japanese language doesn't use spaces the line is not broken as supposed. Or maybe that's because of squareness of the characters.

P.S. In case you wonder, Japanese sentence can be split mid-word, that's normal.

XMPlay currently splits lines at spaces. I suppose XMPlay would need to detect when Japanese characters are used, and perhaps others too? Do you know what Unicode blocks it should look for?

P.P.S. Apparently there's an issue with splitting file path when XMPlay is running under Japanese system and ¥ character is used instead of \

Can either character be used, ie. could XMPlay simply replace all '¥' in filenames with '\'? For reference, please upload your XMPLAY.PLS file to have a look at here:

   ftp.un4seen.com/incoming/

mortstev

  • Posts: 8
Re: Suggestions for 3.9
« Reply #351 on: 11 Aug '17 - 21:44 »
Please upload that skin to have a look at here:
   ftp.un4seen.com/incoming/

It's there - at least I hope it is, when I do an 'ls -l' it doesn't appear in the listing, but I uploaded it and did get "Transfer complete".

The file names are:
albumart.xmpskin
and
albumart-bigger.xmpskin

You can also make those available in the 'skins' section for everyone to download if you'd like.

Thanks for you help!

Mort
--

tails__

  • Posts: 8
Re: Suggestions for 3.9
« Reply #352 on: 14 Aug '17 - 00:18 »
Quote
Can either character be used, ie. could XMPlay simply replace all '¥' in filenames with '\'? For reference, please upload your XMPLAY.PLS file to have a look at here:

I've uploaded the playlist to FTP. As far as I can see, it's just the font having backslash symbol replaced with half-width yen character for compatibility reasons.


Now, about unicode blocks. Main CJK stuff can be found in this range:



And second Chinese block is there:



Then, there is U+FF00–FFEF range which defines full-width ASCII variant with half-width katakana (second Japanese syllabary) which begins at U+FF66 and ends at U+FF9F:



Characters U+FF9E and U+FF9F have to be stacked together with character they came after though.
« Last Edit: 14 Aug '17 - 00:22 by tails__ »

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: Suggestions for 3.9
« Reply #353 on: 14 Aug '17 - 18:17 »
It's there - at least I hope it is, when I do an 'ls -l' it doesn't appear in the listing, but I uploaded it and did get "Transfer complete".

The file names are:
albumart.xmpskin
and
albumart-bigger.xmpskin

The skins were received, thanks. I don't seem to be able to reproduce the problem though. Do I need to make some changes to the skin's skinconfig.txt file? If so, please give those too.

I've uploaded the playlist to FTP. As far as I can see, it's just the font having backslash symbol replaced with half-width yen character for compatibility reasons.

Oh, is it just the font that is making the backslashes look like something else? If so, I'm not sure what can be done about that. Do you see it happen with all fonts? If so, I guess it affects other software too?

Now, about unicode blocks. Main CJK stuff can be found in this range:



And second Chinese block is there:



Then, there is U+FF00–FFEF range which defines full-width ASCII variant with half-width katakana (second Japanese syllabary) which begins at U+FF66 and ends at U+FF9F:



Characters U+FF9E and U+FF9F have to be stacked together with character they came after though.

Does that mean everything between 3190-A48F and 20000-2FA1F can be split anywhere?

tails__

  • Posts: 8
Re: Suggestions for 3.9
« Reply #354 on: 14 Aug '17 - 18:42 »
Quote
Oh, is it just the font that is making the backslashes look like something else? If so, I'm not sure what can be done about that. Do you see it happen with all fonts? If so, I guess it affects other software too?

Yes, actually, with Korean fonts backslash is replaced with something like W, so this is just font issue. Still, cutting text at "\" character code would be nice.

Quote
Does that mean everything between 3190-A48F and 20000-2FA1F can be split anywhere?

It is, yes.

mortstev

  • Posts: 8
Re: Suggestions for 3.9
« Reply #355 on: 15 Aug '17 - 20:55 »
The skins were received, thanks. I don't seem to be able to reproduce the problem though. Do I need to make some changes to the skin's skinconfig.txt file? If so, please give those too.

No. No changes to the  skinconfig.txt file are needed.

Maybe a little better description of the problem will help...
The hour seems to get cut off if you drag and drop into the player. Also it appears more often if there is only one sound file over an hour in length being dragged and dropped, but not always, sometimes if you drag and drop a bunch of short files (~4-5 minutes each maybe 6 of them) and with a couple of long (over an hour) length files it cuts the hour number off. If there are already entries in the playlist over an hour and you drag another entry over an hour in length into the playlist it resizes that column to accommodate the 'hour' - I hope that makes sense, if you need anything more let me know.

Also unrelated, but can an option to display the MP3 Tag Version (ie. ID3v2, ID3v1, APEv2, etc.) be added to the Info display-maybe as part of 'skinconfig.txt' in the form of 'pos_infoIDver' to display or hide the ID Version.

Thanks for your help.

Mort


mortstev

  • Posts: 8
Re: Suggestions for 3.9
« Reply #356 on: 18 Aug '17 - 21:21 »

Okay here's how I've been able to consistently reproduce the problem with the 'hours' column...

I've uploaded to the ftp site a file with the mp3 files I've noticed the problem it's called "hourproblem.zip" I also re-uploaded a files called "aaskins.zip" to be sure you have the exact same skin files as I do and included in there is my "xmplay.ini" (in case there's something in there that's unique to my system, one last thing I'm using XMPlay version 3.8.2.30.

Start by opening XMPlay and setting the 'album-art' skin, open the playlist (if not already opened) then closing XMPlay then:

1) open xmplay, open the playlist (should already be opened), right click on the "X" (next to 'random' on the righthand side of the playlist panel) and select 'remove all', exit xmplay

2) start xmplay, select all the files in the 'hourproblem' folder, drag them into xmplay and release them over the 'loading....' position bar (I don't know if this really makes any difference).

The image file "hourcolproblem.gif" shows the results with the hours column missing.

I hope this helps... doing it this way I've been able to reproduce the cut off 'hours' column 100% of the time. Also, if you remove the files from the list and then drop the files back into the player without exiting and restarting the player it loads the 'hour' column correctly - I believe this problem is somehow related to the mp3 files being cached and how long it takes to read the MP3 ID Tags and determine the length of the file. Also the problem is reproducible by dragging the 'zip' file into the xmplayer instead of the uncompressed files. One final thing I first noticed this loading sound files from a USB stick, but I've since done it from hardrives, SSD as well as RAM drives and as long as the files aren't cached I've been able to reliably reproduce it.

FWIW... I have the parameter "PlayDelay=3" set in the 'xmplay.ini' file, but in changing it to different values it doesn't appear to have any effect on the problem.

Also... there seems to be a problem with the way CUE files are handled. In that directory is a cue file named "03. Cue_File.cue" if you drag it into the player nothing happens, but if you rename it to "03. Apollo-13-Problem.cue" and then drag it in the player it works fine... somehow the 'FILE' portion in the cue file is  being ignored and for some reason the name of the cue file has to match the name of the MP3 file. Cue files are just plain ASCII text and can be opened with with Window's notepad and you'll see the 'FILE' name set correctly. I probably didn't do a very good job explaining the problem, but if you drag the cue file into the player then rename it and do the same thing I think you'll see what I'm talking about. :)

Another suggestion... sorry I'm being a pest! :) But, can the playlist panel be made to 'snap' against the edges of the XMplayer? Makes positioning it with the player a whole lot easier.

Thanks, again for putting up with me! :)

Mort
--

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: Suggestions for 3.9
« Reply #357 on: 31 Aug '17 - 18:04 »
I haven't noticed that before, but apparently there's a need for correction on how XMPlay's maximum text width works:



Here, I set it to 24 characters and used absurdly long path with a long album title. As can be seen the text is broken between letter characters but as Japanese language doesn't use spaces the line is not broken as supposed. Or maybe that's because of squareness of the characters.

Here's an update for you to try...

   www.un4seen.com/stuff/xmplay.exe

If there are no spaces before the max width is reached, then it will just break the text mid-word rather than breaking at the next space.

Okay here's how I've been able to consistently reproduce the problem with the 'hours' column...

I've uploaded to the ftp site a file with the mp3 files I've noticed the problem it's called "hourproblem.zip" I also re-uploaded a files called "aaskins.zip" to be sure you have the exact same skin files as I do and included in there is my "xmplay.ini" (in case there's something in there that's unique to my system, one last thing I'm using XMPlay version 3.8.2.30.

Start by opening XMPlay and setting the 'album-art' skin, open the playlist (if not already opened) then closing XMPlay then:

1) open xmplay, open the playlist (should already be opened), right click on the "X" (next to 'random' on the righthand side of the playlist panel) and select 'remove all', exit xmplay

2) start xmplay, select all the files in the 'hourproblem' folder, drag them into xmplay and release them over the 'loading....' position bar (I don't know if this really makes any difference).

The image file "hourcolproblem.gif" shows the results with the hours column missing.

Oh yes, I can reproduce that. The update above should fix it. Let me know if you still see it happen.

mortstev

  • Posts: 8
Re: Suggestions for 3.9
« Reply #358 on: 1 Sep '17 - 21:42 »
Oh yes, I can reproduce that. The update above should fix it. Let me know if you still see it happen.

seems to have fixed it -- thanks

augitesoul

  • Posts: 2
Re: Suggestions for 3.9
« Reply #359 on: 19 Sep '17 - 16:44 »
Would Discord integration be possible? It could show the music you play currently in the "Playing:" textfield.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: Suggestions for 3.9
« Reply #360 on: 21 Sep '17 - 16:25 »
I'm not familiar with how Discord works, but perhaps it would be possible to adapt the old MSN "now playing" plugin for it? That plugin works by finding the MSN window and sending a WM_COPYDATA message (containing the title) to it. The source code is included in the XMPlay plugin SDK, which is available from the XMPlay page.

Alternatively, if Discord needs to pull the title from XMPlay, that is available via DDE: service = "XMPlay", topic = "info0" (for the General info window text).

augitesoul

  • Posts: 2
Re: Suggestions for 3.9
« Reply #361 on: 21 Sep '17 - 18:17 »
I will look into the plugin, to adapt it, thanks

saga

  • Posts: 2181
Re: Suggestions for 3.9
« Reply #362 on: 28 Oct '17 - 00:19 »
It appears that for WAV files, XMPlay attempts to decode metadata as UTF-8 and if that fails, it falls back to ANSI. It is apparently very little known that there is actually a RIFF chunk for setting the character set for strings! It's the "CSET" chunk, it exists since the very early RIFF days and the first two bytes of that chunk indicate the Windows codepage (which can also be UTF-8, CP 65001). Maybe XMPlay should first try to read the metadata according to the CSET chunk before falling back to heuristics.
I've attached two example files, both have a CSET chunk that indicates an UTF-8 codepage, but one of them contains a malformed UTF-8 string. Still, both should be decoded as UTF-8.

cong

  • Posts: 2
Re: Suggestions for 3.9
« Reply #363 on: 29 Oct '17 - 01:43 »
Better file type names rather than have everything called "XMPlay-able file".

and maybe more icon choices for each type of file. Currently it let's us choose one icon for all supported files. One icon design is great but I like my playlists and songs to have a different icon.

Also windows doesn't let me associate files with xmplay. I think that's broken in windows 10.

saga

  • Posts: 2181
Re: Suggestions for 3.9
« Reply #364 on: 29 Oct '17 - 10:51 »
Using the most recent XMPlay version, file types should actually no longer show up as "XMPlay-able file" but rather "MP3 file" or similar. There are some icon packs for various formats available on the forum, but you have to assign them manually. You should be able to find them by doing a forum search.

cong

  • Posts: 2
Re: Suggestions for 3.9
« Reply #365 on: 29 Oct '17 - 17:51 »
I made my own icon because I didn't like the xmplay one. Nothing fancy, something to fit in with the rest. I'm using the most recent, 3.8.2.3.



Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: Suggestions for 3.9
« Reply #366 on: 30 Oct '17 - 16:51 »
It appears that for WAV files, XMPlay attempts to decode metadata as UTF-8 and if that fails, it falls back to ANSI. It is apparently very little known that there is actually a RIFF chunk for setting the character set for strings! It's the "CSET" chunk, it exists since the very early RIFF days and the first two bytes of that chunk indicate the Windows codepage (which can also be UTF-8, CP 65001). Maybe XMPlay should first try to read the metadata according to the CSET chunk before falling back to heuristics.
I've attached two example files, both have a CSET chunk that indicates an UTF-8 codepage, but one of them contains a malformed UTF-8 string. Still, both should be decoded as UTF-8.

Interesting. I'll look into that, thanks.

I made my own icon because I didn't like the xmplay one. Nothing fancy, something to fit in with the rest. I'm using the most recent, 3.8.2.3.

3.8.2.3 is the current release version, but the latest "in development" XMPlay build (that saga is referring to) is available here:

   www.un4seen.com/stuff/xmplay.exe

obertres

  • Guest
Re: Suggestions for 3.9
« Reply #367 on: 7 Nov '17 - 02:36 »
I would like the function to modify the name and size of the typeface of the playlist. I'm short of sight. Thank you.

Azevedo

  • Posts: 24
Re: Suggestions for 3.9
« Reply #368 on: 10 Dec '17 - 17:20 »
I really would like to see the options window re-organized in a future version. The layout is all clumsy and too tight.

Make the text size a little larger and spaced

I guess it was designed thinking of the 640x480 screen user. Nobody uses 640x480 anymore.