next »

[Ian @ un4seen]

This is an interesting feature. The gf sure loves it because it keeps the playlist neat and while I do too, I've run into a small problem. I have playback position saving upon closing enabled but if I close XMPlay with "remove after playing" enabled, the next time I start it, the track has already been removed so playback can't resume.

Good point. Here's an update that should fix it...

   www.un4seen.com/stuff/xmplay.exe

[xaos]

uhm... doesn't seem to be covered, but sometimes it takes too long to read everything .. was wondering, for those of us who like to keep our media tags 'cleanish' , is there, or would it be possible to add to XMPlays saved settings the ability to save just our ratings .. as in not to the tag itself, but as an XMPlay specific file akin to a playlist but with only a list of the relevant file information (derived from tag?) and it's rating as given within XMPlay? .. thousands of files and their ratings are about the only thing that keep getting lost

[Dotpitch]

for those of us who like to keep our media tags 'cleanish' , is there, or would it be possible to add to XMPlays saved settings the ability to save just our ratings .. as in not to the tag itself, but as an XMPlay specific file akin to a playlist but with only a list of the relevant file information (derived from tag?) and it's rating as given within XMPlay?

Put your tracks in the library. XMPlay stores all tags and ratings in the xmplay.library file, not in the tags.

[xaos]

Put your tracks in the library. XMPlay stores all tags and ratings in the xmplay.library file, not in the tags.

sigh: not really what was asked but it could be the question wasn't specific enuff. guess it depends on what exactly gets replaced in the library info when all the original files have been moved. other question being how often the library rescans the directories, and the final part of it being, never cared for 'folder monitoring' in the first place .. so
.. an associative file that stores ratings regardless of whether the file is in the library's list, and can apply said ratings to what's in the playlist according to the/a files' matching tag. (yes it could cause multiple tracks to end up with a rating they didn't originally have, but that would mean the tagger managed duplicates somehow and wouldn't be the fault of the player) ... just a thot, question, query, whichever , is all.

[amit]

The amp and volume settings are currently applied separately, but the sample data remains floating-point throughout, so that should have no detrimental effect on quality. Depending on the output system, the volume may not be applied at all by XMPlay, but rather the device/driver: that's the case when using DirectSound or WASAPI (if the device/driver has its own volume control), or when the default output system is used on Vista/above.

Can you add keyboard shortcuts for reducing/increasing the pre-amp value of replaygain?
I was thinking - if all tracks have replaygain info this could serve as a single volume system that can be enough in most cases.

[miggyb]

Something quick and dirty:

Grabbing the "iTunes Library.xml" file and updating the XMPlay library to match that.

I know, I know. I should go ahead and uninstall iTunes. But I need it for my iPhone because I am a huge faggot that sucks a thousand dicks.

Anywho, it looks relatively easy. Here's an example snip of it:

...
<key>Track ID</key><integer>3302</integer>
<key>Name</key><string>Don't Get Lost In Heaven</string>
<key>Artist</key><string>Gorillaz</string>
<key>Album</key><string>Demon Days</string>
<key>Genre</key><string>Alt Rock</string>
<key>Kind</key><string>MPEG audio file</string>
<key>Size</key><integer>5036279</integer>
<key>Total Time</key><integer>120424</integer>
<key>Disc Number</key><integer>1</integer>
<key>Disc Count</key><integer>1</integer>
<key>Track Number</key><integer>14</integer>
<key>Track Count</key><integer>15</integer>
<key>Date Modified</key><date>2011-12-15T02:20:56Z</date>
<key>Date Added</key><date>2007-01-21T16:18:21Z</date>
<key>Bit Rate</key><integer>320</integer>
<key>Sample Rate</key><integer>44100</integer>
<key>Play Count</key><integer>31</integer>
<key>Play Date</key><integer>3404021818</integer>
<key>Play Date UTC</key><date>2011-11-13T14:36:58Z</date>
<key>Skip Count</key><integer>5</integer>
<key>Skip Date</key><date>2011-08-02T14:22:48Z</date>
<key>Rating</key><integer>100</integer>
<key>Album Rating</key><integer>80</integer>
<key>Album Rating Computed</key><true/>
<key>Artwork Count</key><integer>1</integer>
<key>Persistent ID</key><string>5C3FD60D1A91EE2C</string>
<key>Track Type</key><string>File</string>
<key>Location</key
<string>file://localhost/Users/miggyb/Music/iTunes/Gorillaz/Demon%20Days/14%20Don't%20Get%20Lost%20In%20Heaven.mp3</string>
...

The quickest, dirtiest way of doing it would be to just grab the file location, put it in the library, then let XMPlay figure out the track title, etc. Even better would be if the ratings got imported as well.

I didn't find anyone else who suggested this so I might just be a special case. If that's so, then is there any kind of beginners developer guide for it? I'd love to take a look at it if you guys would like to focus on the more interesting problems

[Dotpitch]

This certainly sounds possible, especially if you use a separate application. There's a description of XMPlay's library file format on the Support Site, you can put the fields you need from the iTunes library (filename, rating, play count and last play) right in there. I'd suggest to let XMPlay read the rest of the tags from the file itself.

[synth]

I've been using XMPlay since 1.7. Thanks for the greatest player ever.

Suggestions for XMPlay 3.7
...
Playlist

...

• Disable 'Remove & delete file' in track context menu

I'm very disappointed to see this feature gone. Please, at least make having 'Remove & delete file' item in context menu an option. I agree that deleting a file is a crucial action, but many players have an option to include this item in menu. As do some file managers have an option to 'Delete permanently' in addition to just 'Delete'.

I have seen that xmplay plugin for last.fm is available. Are there plans to develop similar plugins to support Magnatune or Jamendo? If no, then I'm suggesting it

[Pike84]

This means an option to disable the feature by user. I don't think any options will be removed.

Also note, that Dotpitch's list contains pretty much everything that's suggested by anyone here at the forums - it's not by any means a to-do list by the developer Ian Luck.

[xaos]

Adjustable font size and type in extended playlist.

[Zarggg]

Those are controlled by the skin you are using.

[xaos]

Those are controlled by the skin you are using.

..perhaps then it ought to be separated, being haven't found an easy option to alter the 'skins' default font size as of yet and it would be nice to change for days when the eyes don't read smaller fonts too well

[amit]

You can use a skin that comes in multiple sizes , something like nuetron.

[xaos]

You can use a skin that comes in multiple sizes , something like nuetron.

.. so apparently one has to be a member here to be taken seriously ... hey Ian, nothing against you. XMplay is by far the best audio player I've used. ... so if you'd be willing to respond it would be appreciated, seems others can't think beyond the end of their own noses.

[Pike84]

No, you don't have to be a member to be taken seriously.

Just because you got some "sub-optimal" suggestions/answers, from normal users that can't do much more anyway, it doesn't mean what you proposed went unnoticed .

I'm sure Dotpitch will gladly add this to his list of suggestions.

[Jimmy Neutron]

Well, I'm just a normal person around here, but...

If you want to use a compiled skin, you will have to find one that has a bigger/different font that is more pleasing to you.

If you want to download the source of a skin, you can (within limits) change stuff in that skin for your own use.  Take a look at the skinning kit.

If you'd rather not hear it from me, please ignore this post.

[xaos]

ah, so there are thinkers around here ... yes, i'm aware of those options, (seems there are too many 'not so bright' users around that everything has to be specifically stated before the original idea is comprehended) .. anyway .. it makes more sense to have adjustable font size for the extended playlist separate from the skin than to be 'forced' to switch skins, or try to modify an existing one. ... it seems you can already 'customize' nearly every other aspect of what's displayed in the extended playlist, why not the font size (and perhaps type) as well ... oh, anyone care to address my very first post there about a ratings file idea?

[Dotpitch]

it makes more sense to have adjustable font size for the extended playlist separate from the skin than to be 'forced' to switch skins, or try to modify an existing one.

Yep. Looking at the skinning kit, adjusting the playlist font size already works fine on skins without a playlist panel (like Multipass). Having a font size selector on the Playlist page of Options and stuff would be enough. Skins with a playlist panel (like the default skin) have the track entry height defined by the bitmap mask for the panel; ignoring that height for the Extended playlist and only applying the font size there should make it work for those skins as well.

for those of us who like to keep our media tags 'cleanish' , is there, or would it be possible to add to XMPlays saved settings the ability to save just our ratings .. as in not to the tag itself, but as an XMPlay specific file akin to a playlist but with only a list of the relevant file information (derived from tag?) and it's rating as given within XMPlay?

Put your tracks in the library. XMPlay stores all tags and ratings in the xmplay.library file, not in the tags.

guess it depends on what exactly gets replaced in the library info when all the original files have been moved. other question being how often the library rescans the directories, and the final part of it being, never cared for 'folder monitoring' in the first place .. so
.. an associative file that stores ratings regardless of whether the file is in the library's list, and can apply said ratings to what's in the playlist according to the/a files' matching tag. (yes it could cause multiple tracks to end up with a rating they didn't originally have, but that would mean the tagger managed duplicates somehow and wouldn't be the fault of the player)

Could you explain why you don't want to use the library for this? Folder monitoring is not required for the library.
I'm not really fond of creating a rating-list outside of the library, as that would need additional managing/cleaning with a GUI interface. Binding the rating to the tags sounds right (as long as you have all your files tagged properly, obviiously), but do you move and rename your audio files that often that it's not reliable to bind the rating to the file path and name?

[xaos]

..Thanx DotPitch .. appreciated ...

Skins with a playlist panel (like the default skin) have the track entry height defined by the bitmap mask for the panel; ignoring that height for the Extended playlist and only applying the font size there should make it work for those skins as well.

nice to know how it works/would work .. ah, that font size ought also to apply to the library as well (yeah yeah, i know i'm not using it right now) ..

but do you move and rename your audio files that often that it's not reliable to bind the rating to the file path and name?

i have in the passed, present, and likely to do it in the future, but my tags stay consistent with a minimum of the track name in them, and max of track num, name, artist, album, year, and sometimes genre.

Could you explain why you don't want to use the library for this? Folder monitoring is not required for the library.

Font size issues for one, sorting, searching, and I generally find it easier to just browse my directories via my file explorer and add as needed rather than try to scan the library window. Related back to how often I mess with filenames and locations. ... And it seems the library is either created or recreated from the current loaded tracks with no monitored directories selected, or overwritten if monitored directories are added.

I'm not really fond of creating a rating-list outside of the library, as that would need additional managing/cleaning with a GUI interface. Binding the rating to the tags sounds right (as long as you have all your files tagged properly, obviiously)

It wouldn't need anything extra. Same idea as the 'saved settings' thing (which still isn't completely clear to me). Just a saved setting that stores the ratings for rated files according to their tags track name, or file name if no tag. Can use what it already stores in the library.
something like ...

tag("title-of-my-favorite-track") -> rating="5"
or If no tag
filename("my-other-favorite-track.mp3") -> rating="4"

It could be set to auto-save ratings on player close, or left up to the user to remember to do. The only issue would then be for renamed files without tags losing their rating, all others could retain theirs regardless of location, and perhaps even be imported into a different Xmplay instance without the need for the entire library.
And yeah, being the library and playlist work best with well formatted tags, it makes more sense that it would be tied to the tag first.

[xaos]

... i should expand on that a little .. it should be able to be done in tandem with the library/current loaded files, same way it's done on player start or close.

..to try to avoid ratings appearing on duplicate tag("title-of-my-favorite-track")  or filename("my-other-favorite-track.mp3"), optionally store length as well.

... being the idea could create an overwrite or loss of current ratings within the library ... on first use/load .. option
start with new file and import ratings from current library/loaded files list, or load file and append ratings from current library/loaded files list, and/or append ratings to library, or just ('auto-load and use extended ratings')

basically persistent ratings, if both are in use they can be updated together, but neither overwrites the other. .. means your library ratings will always be your defaults, but can be extended by a ratings file with existing ratings, and you'll never loose your main ratings unless you delete your saved ratings & muck with your library.

would allow for the sharing of ratings too if all you do is load and append from your library then pass it on. (could make for an interesting way to start a database of popularly rated songs) (someone else could write the GUI for that if they were so inclined)

sorry if it all sounds like too much... just thinking, OR, take the standard playlists XMplayer can create, and allow/add an extra comment that XMplayer recognizes as the rating. then we can just manually save a list of our rated files with their rating and alter it however we need.