I have an idea for implementing manual song ratings on the player, similar to some of the ideas in this thread. Here's how my approach would work (thanks to tman for some help in fleshing out the details):

1. A user app (emphatic, of course) provides a simple UI for the user to select their rating of a song (on a 1-5 or 1-10 scale.)
2. The app writes this numerical rating to that FID's "Plays" count on the dynamic data partition.
3. The player's attempts to write the real "Plays" count are blocked (no-op'ed) by Hijack.

With these mechanisms in place, a custom shuffle mode which uses the PLAYS variable could now be effectively used as a "play my favorite (highest-rated) songs" feature. So you don't get the same sequence each time, a RANDOM coefficient could be added to scatter them around a bit once they're sorted by rating.

The principal advantages of my proposed implementation over the comment field approach would be:
1. Song ratings would be done on-the-fly while listening in your car, instead of having to pre-rate them before you load them on your player.
2. No need to bastardize the comment field with numerical ratings (I keep other stuff in my comment field.)
3. No need to have an even distribution of song ratings or play with coefficients of shuffle modes.

The biggest drawback I can think of for my approach is that ratings would be stored on the dynamic data partition and not in the music file itself. Because of this, losing your dynamic data partition (resyncing your music collection, etc.) would lose this data as well. To avoid this, I could provide a utility to read/write ratings between the dynamic data partition and an ID3v2 field.

The other drawback (minor IMHO) is that, because the plays count is used to hold the rating, shuffle modes like "Least Often Played" would no longer work. I never use this mode, so that doesn't bother me.

There are a couple safeguards that would have to be in place for this to work. For one, emphatic would have to check the player software version before it decides to do any writing to the dynamic data partition. Hijack would also need to only block the plays count from being written on versions of the player software it knows about (so it doesn't Do The Wrong Thing if the dynamic data partition layout changes.)

Already, I've proven that steps 1 and 2 of my theory work. I have a test program that can replace the Plays count with a value of my choosing, and I have a shuffle mode that uses these plays counts to sort my tunes into order by rating, with a little randomness thrown in:

shuffle1=Favorites,PLAYS=-32000,RANDOM=16000

.

There are still a couple things I need to work on, the main one being that with this shuffle mode, songs that haven't been played yet will have a zero stored in the Plays count, thus won't get played until the very end. To fix this, I might be able to invert the scale (and the shuffle mode coefficients), such that a rating of 0 means "my favorite song" and new songs are assumed to be rated highest until you rate them manually. I'll have to try this out.

Anyway, I'd like to hear if anyone has any interest in this. Would anyone other than me actually take the time to subjectively rate their songs when they're playing? Is anyone using the comment field approach to do this? I think this idea has a lot of potential, especially considering 99% of the time I'm listening to my whole collection shuffled. If you think this is a good idea, or think you have a better idea, I'm all ears.

I think An Empeg Guy mentioned that custom shuffles can be definied on any arbitrary database field, such that we could implement some sort of x-rating field and shuffle on that. I suppose that would then require rewriting the database field while in the car, which would be a bad idea.

Matthew

I think An Empeg Guy mentioned that custom shuffles can be definied on any arbitrary database field

Hm, I don't know about that. Based on some poking at the jEmplode code (which has a feature where it can generate the database for you) I don't think we can add our own fields to it. Having the player's custom shuffle functionality understand those fields (and address them by name) also seems unlikely. If you can dig up a post where this was advertised, I'd love to read about it, but I remember it being phrased more as "any numerical database field" and it had to be an attribute the player already knew about (Year and CTIME were mentioned, methinks.) In your example, how would the player know about the existence of the "x-rating" attribute?

Another thing that occurred to me last night is that this same strategy of taking over the writing of a fid's dynamic data may also give us the ability to implement a mechanism for marking tracks with different flags (which has been asked for.) There are 30 or so bits marked as "unused" in the dynamic data partition, right next to the "marked" bit. It esems to me that if a user app took control of the process of setting/clearing mark flags (including the existing one) this could be interesting. Of course, for this to be useful, jEmplode would need to be rewritten to understand these. I *believe* the whole dynamic data structure (including the unused bits) travels over to jEmplode, so it may actually work. Still need to prove this one out a little more, though.

In your example, how would the player know about the existence of the "x-rating" attribute?

If it's in the *1 files, it goes into the database. If even one of your files has an "x-rating" tag, then that becomes a database field and can be referenced in custom shuffles.

By contrast, there's no way to shuffle based on contents of the dynamic data other than contents the player already knows about. But if you don't want to lose the play_count stuff, you could instead suborn the "skipped_count" field, which is never filled in by the player. This has the advantage over "x-rating" that it can be changed with the music partitions read-only (in Hijack; there's no player UI to do so).

Peter

you could instead suborn the "skipped_count" field, which is never filled in by the player.

Hmm, good point. I'll use that instead of the plays count.

This has the advantage over "x-rating" that it can be changed with the music partitions read-only (in Hijack; there's no player UI to do so).

Yeah, I don't want to get involved in writing to the music partition. skipped_count seems to be the best field to use for this purpose. The problem is the player writes the entire DynamicData structure (including an empty skipped_count) on track changes, so I'll probably have to wait until the player's done its thing before I write ratings out.

My original idea (filtering the player's disk write at the kernel) level seems difficult on second thought, as the kernel would have to calculate a new CRC16 for the dynamic data structure, since the player's idea of what's there is going to be different than what's actually written to disk. Probably best to avoid that whole mess and detect the plays_count of the last track changing before writing the numerical rating out the skipped_count field.

> I'd like to hear if anyone has any interest in this.
Very much so. I've been thinking of doing something very like this myself for a long time. Just never got round to it. I would help out with this if I can.

Cheers,
Sue

The kernel already has (at least) one fast CRC16 implementation, in the IRDA drivers. This can be called from whereever, saving the need to do it again.

Cheers

The kernel already has (at least) one fast CRC16 implementation, in the IRDA drivers. This can be called from whereever, saving the need to do it again.

Cool. So I guess this is your way of saying you'd be happy to do the kernel portions of this, right?

In reply to:

---

There are still a couple things I need to work on, the main one being that with this shuffle mode, songs that haven't been played yet will have a zero stored in the Plays count, thus won't get played until the very end. To fix this, I might be able to invert the scale (and the shuffle mode coefficients), such that a rating of 0 means "my favorite song" and new songs are assumed to be rated highest until you rate them manually. I'll have to try this out.

---

It's a signed integer value, right? So there's no reason (apart from hand-editing in JEmplode) to have exactly the same scale in the skipped_count field as is read from the user. We could map (0...10) to, say, (-500...+500) internally, to give untouched tunes a mid-point score (5 in the user domain).

Hm, good points. It turns out play_count is specified as an unsigned short, and skipped_count is specified as an unsigned int. If this was implemented such that the player's attempts to write to this field were blocked, neither it nor emplode should care about what's there, and emphatic (and jEmplode, eventually) could interpret it as signed. Only experimentation will prove this out. I'll give the +/- approach a shot and see where it gets me.

Odd. Apparently, we're expected to be skipping tracks more than listening to them.

Apparently, we're expected to be skipping tracks more than listening to them.

Sounds fair to me. That's how I use my player.

Odd. Apparently, we're expected to be skipping tracks more than listening to them.

Yeah, and that's why I want this manual rating / weighted shuffle functionality so much. When I'm skipping a song, it doesn't mean I don't like that song, it just means I don't want to hear it at that particular time, or as often as I want to hear another song. A shuffle that favors my favorite songs will (probably) require less skipping. As long as there's enough of a random factor thrown in, I don't think it'll overplay favorite tunes, either. It's all about increasing the chances that a track suits my mood at that time, thus decreasing wear and tear on my player's right front panel button.

Just to chime in, very cool idea. I'd use it for sure if you got it working.

Odd. Apparently, we're expected to be skipping tracks more than listening to them.
....
Yeah, and that's why I want this manual rating / weighted shuffle functionality so much

Ditto. I'd LOVE to have this since i listen in full shuffle most of the time and end up skipping a majority of the songs. This would really be a valuable addition to the player funtionality IMHO. I'd use the hell out of it.