next »

[amit]

I think if you reset the age then the counter can be reset too. The other way is to accumulate the current age with previous.

It isn't possible to accumulate the age as it's based on the time that the track was added to the library (as shown in the "Track Info"), but here's an update with an "Average play count/year" option in the library header right-click menu...

   www.un4seen.com/stuff/xmplay.exe

The play count isn't currently reset automatically when a track is added to the library.

Is this option suppose to be visible in the "play count" column?

Does averaging to years look useful? I think it was better to show the ratio between play_count and seconds/minutes of age.

Maybe you tried to avoid very small numbers... That is why I suggested 'average frequency' (dividing the age with play_count).This way you would get the average periods of times between each listen in seconds/minutes/days etc' without any weird mathematical figures.

[saga]

*  a range of -36dB is way to small
Foobar2000 has -100dB range by default and 1dB steps per 'click' , and even that can be adjusted further to your personal preference (I use 0.25dB or 0.5dB per click)

What exactly is so great about being able to listen to music at exactly -48.25dB? The more quiet the output is (and at -48dB, it is extremely quiet), the more noise you get, doesn't that disappoint you as an audiophile? If a track is too loud, I turn down the slider by 10-20 units. With the next track, I just return to the old volume. I wouldn't even hear the difference between 0dB and -0.25dB, I guess. And I bet you wouldn't in an ABX test.

[Dotpitch]

... here's an update with an "Average play count/year" option in the library header right-click menu...

There's something really wrong with the library headers in this update. Selecting 'Age' will have all sorts of colums show up (rating, length, last play, play count, comment, etc.), but not the age. In addition, bookkeeping on what columns are shown is broken, making it possible to show two rating columns. Oh, and it doesn't show the average, just the normal count.

a range of -36dB is way to small

Has this always been a problem to you, or only now that the volume level has been converted to decibel display?

Does averaging to years look useful? I think it was better to show the ratio between play_count and seconds/minutes of age. ... That is why I suggested 'average frequency' (dividing the age with play_count).

The ratio of age over play count results in the least popular tracks receiving the highest play interval (not play frequency, btw ), which makes sorting a bit awkward. I'm not sure whether plays per year or play interval would be better.

[oddiophile]

*  a range of -36dB is way to small
Foobar2000 has -100dB range by default and 1dB steps per 'click' , and even that can be adjusted further to your personal preference (I use 0.25dB or 0.5dB per click)

What exactly is so great about being able to listen to music at exactly -48.25dB? The more quiet the output is (and at -48dB, it is extremely quiet), the more noise you get, doesn't that disappoint you as an audiophile? If a track is too loud, I turn down the slider by 10-20 units. With the next track, I just return to the old volume. I wouldn't even hear the difference between 0dB and -0.25dB, I guess. And I bet you wouldn't in an ABX test.

A 48dB range would be just about right. The 100 dB range in Foobar2000 is overkill (nice for testing your threshold of hearing, but overkill for music), while 36dB is too low.

And I can tell a difference even with 0.25dB steps. It all depends on the relative volume and frequency spectrum of the audio being played (the sensitivity of the human auditory system is nonlinear)

0.5 dB (or even 1dB) per click would be fine instead of the current 1.8dB.

[Ian @ un4seen]

*  1.8dB change per mousewheel 'click' is too coarse

*  a range of -36dB is a bit small

Here's an update in which the range is increased slightly to 40dB (-40dB = 1%)...

   www.un4seen.com/stuff/xmplay.exe

The volume slider still has 100 steps, so the minimum step is 0.4dB, eg. when dragging the slider. The mousewheel doesn't do 1 step at a time as that would mean a lot of wheeling to get from one end to the other; it previously moved the slider 5 steps at a time (5/100*36 = 1.8dB), but that is now reduced to 3 (3/100*40 = 1.2dB).

Does averaging to years look useful? I think it was better to show the ratio between play_count and seconds/minutes of age.

Maybe you tried to avoid very small numbers... That is why I suggested 'average frequency' (dividing the age with play_count).This way you would get the average periods of times between each listen in seconds/minutes/days etc' without any weird mathematical figures.

Yes, the thinking behind the yearly average was to avoid tiny fractions with rarely played files, and it also avoided the need for a new column. I guess a year is probably a bit too long, though. The update above uses a monthly average instead. Is that any better? Note the average is displayed to 1 decimal place, but the sorting will use the exact averages.

There's something really wrong with the library headers in this update. Selecting 'Age' will have all sorts of colums show up (rating, length, last play, play count, comment, etc.), but not the age. In addition, bookkeeping on what columns are shown is broken, making it possible to show two rating columns. Oh, and it doesn't show the average, just the normal count.

That's strange. Please upload your XMPLAY.INI file to get some clues on what has gone wrong...

   ftp.un4seen.com/incoming/

Is anyone else seeing the same thing?

[Dotpitch]

There's something really wrong with the library headers in this update. Selecting 'Age' will have all sorts of colums show up (rating, length, last play, play count, comment, etc.), but not the age. In addition, bookkeeping on what columns are shown is broken, making it possible to show two rating columns.

That's strange. Please upload your XMPLAY.INI file to get some clues on what has gone wrong... Is anyone else seeing the same thing?

I've uploaded the INI. Still happens with the new stuff version, btw.

[amit]

Does averaging to years look useful? I think it was better to show the ratio between play_count and seconds/minutes of age.

Maybe you tried to avoid very small numbers... That is why I suggested 'average frequency' (dividing the age with play_count).This way you would get the average periods of times between each listen in seconds/minutes/days etc' without any weird mathematical figures.

Yes, the thinking behind the yearly average was to avoid tiny fractions with rarely played files, and it also avoided the need for a new column. I guess a year is probably a bit too long, though. The update above uses a monthly average instead. Is that any better? Note the average is displayed to 1 decimal place, but the sorting will use the exact averages.

I am not sure whether a reference of months is small enough or weeks will be better (I guess per day' will be too small).

Either period you choose eventually - can the calculation be accurate and only presented roughly in the library? For example if average per months is chosen the calculation would be :

  Average = play count / Age in seconds X 2592000 (seconds in 30 days)

There's something really wrong with the library headers in this update. Selecting 'Age' will have all sorts of colums show up (rating, length, last play, play count, comment, etc.), but not the age. In addition, bookkeeping on what columns are shown is broken, making it possible to show two rating columns.

That's strange. Please upload your XMPLAY.INI file to get some clues on what has gone wrong... Is anyone else seeing the same thing?

I've uploaded the INI. Still happens with the new stuff version, btw.

I don't see any problem with the library here.

[Ian @ un4seen]

I've uploaded the INI. Still happens with the new stuff version, btw.

The "LibCols" XMPLAY.INI entry has somehow gotten corrupt: the "Age" column is replaced by another "Rating" column. I'm not sure how that happened, but you can reset things by deleting the "LibCols" line.

Are you able to reproduce the problem, eg. if you recreate the column arrangement that you had? If so, please describe how to do that.

I am not sure whether a reference of months is small enough or weeks will be better (I guess per day' will be too small).

I think even a weekly average would result in too low numbers, except perhaps if a 2nd decimal place is added, which I guess is a possibility given that the "play count" column heading is fairly long (allowing long numbers to fit under it). In my (possibly atypical) case, there are a lot of tracks that are already fractional with a monthly average.

Either period you choose eventually - can the calculation be accurate and only presented roughly in the library? For example if average per months is chosen the calculation would be :

  Average = play count / Age in seconds X 2592000 (seconds in 30 days)

The calculation currently looks like this...

  Average = play count / max(Age in months, 1)

In other words, the play count will only be averaged once a track is at least 1 month (30.4 days) old. Btw, the "Age in months" isn't rounded-down to a whole number, eg. a 45 day old track will be ~1.5 (not 1) months old.

[Dotpitch]

The "LibCols" XMPLAY.INI entry has somehow gotten corrupt: the "Age" column is replaced by another "Rating" column. I'm not sure how that happened, but you can reset things by deleting the "LibCols" line.

Yep, I saved it with two rating columns for you. Using the LibCols line in a vanilla XMPlay produces the same erratic behaviour, so it's probably just corrupt. I've reset it and now it works fine. And the plays per month show up properly now .

Are you able to reproduce the problem, eg. if you recreate the column arrangement that you had? If so, please describe how to do that.

No, I can't reproduce it, unfortunately. I hadn't changed my library columns in ages, so the corruption could've been there a whole lot longer.

[amit]

The calculation currently looks like this...

  Average = play count / max(Age in months, 1)

In other words, the play count will only be averaged once a track is at least 1 month (30.4 days) old. Btw, the "Age in months" isn't rounded-down to a whole number, eg. a 45 day old track will be ~1.5 (not 1) months old.

Why won't you considerate fractions of a month If tracks are less than one month old ?

[Ian @ un4seen]

It's just that it would result in the average being higher than the total.

[Sergey]

In my opinion work in the library more convenient than in the playlist, it has more information about the files.
I propose to add the ability to use the button "Next track" in the library separate from the playlist.

[amit]

Can you add an option to ignore tracks with zero or shorter than x seconds length , both in playlist and library?

[Zarggg]

If a track has zero length, how do you expect it to play?

[amit]

If a track has zero length, how do you expect it to play?

When ripping cds , in order to keep all the original data ,  gap files are sometimes created which seem to be of zero length . I guess they are 0.1 seconds or other small value. I would prefer if these tracks weren't loaded to the playlist and library.

[Zarggg]

If you're ripping a CD properly, You shouldn't have any "gap files", unless the CD had tracks that were actually full of silence.. Even then, the file should still be the same length as the actual track.

[amit]

If you're ripping a CD properly, You shouldn't have any "gap files", unless the CD had tracks that were actually full of silence.. Even then, the file should still be the same length as the actual track.

The rips are properly made. They are not built as one image file though , but as multiple tracks with cue sheet. The original gaps between tracks are appended to the end of each file but the pregap before the first track is left as a separate small silence track.

[klaudyuxxx]

Current track - Remove (delete to recycle bin)

[Dynobot]

I hope you guys really consider making XMPlay a client/server based player.

For sure this is the future in terms of computer audio and there is only 1 player that does it successfully...Music Player Daemon.

Even if you decide not to go with Linux [though I really hope you will] rest assured there are plenty of people waiting for a good client/server music player for any OS.   Esp. if it can be controlled via an iTouch or any wifi based remote.

Its great that you ask your own user base for suggestions but just take some time and have a lot at what is currently available and the features they have.

Windows most "Audiophile" users are using Foobar, XXHighend, cPlay, JRiver....some people have discovered Slysoft's Re-Clock and use KMPlayer.

Mac OS most "Audiophile" users are using PureMusic, Amarra, Play and maybe iTunes [because lack of a better low cost or free player]

Linux most "Audiophile" users are using Music Player Daemon, Amarok and Rhythmbox [probably only because of features]

Granted Windows OS is more difficult to really gain ground in terms of being the best audio player because its already saturated.  But Mac OS for sure NEEDS a good sounding [full featured] player.  Right now there are only a very small handful of Mac players that can handle multiple formats and Internet radio, and Play is not one of them.  In fact maybe only VLC player can do that, even iTunes can't play Flac without an external program and still it won't sort the library correctly.  Which means Mac users are forced to use iTunes with Mac's audio format and if people use Amarra or Pure Music they can't listen to Internet radio and they have to pay more than $100.  And Linux needs another choice besides MPD.

Otherwise XMPlay will remain Just Another Player amongst many for Windows.

Just my .02

[saga]

Otherwise XMPlay will remain Just Another Player amongst many for Windows.

No, it's already the best player you could imagine for module playback. ;P