[FEATURE] Give tracks from previous fingerprint playlist lower weight during generation

[grayhaze]

Is your feature request related to a problem? Please describe.
When playing the generated sonic fingerprint playlist daily, many tracks are repeated each day, rather than the playlist being populated by similar, but different tracks as expected. This makes the playlist feel a little stale and repetitive, especially when the next day's playlist is based on the tracks played in the previous day's.

Describe the solution you'd like
The previous version of the playlist should be used to score the tracks it contains with a lower weight when generating the new playlist, encouraging more variety from day to day.

Describe alternatives you've considered
Alternatively, simply excluding tracks from the previous playlist outright would force variety, but would potentially result in a reduced playlist for smaller libraries.

[grayhaze]

Just following up on this, and I'm finding the current sonic fingerprint functionality to only really be useful for generating a one-off playlist with Jellyfin. Currently I'm playing a lot of music outside of playlists, but every day the fingerprint playlist includes mostly the same selection of tracks, just in a different order. Am I perhaps doing something wrong here, such as some configuration I need to play with, or is this not designed to give a fresh selection each day?

[NeptuneHub]

Hi and thanks for the feedback. Actually the sonic fingerprint is based on the 20 top played song and how recent did you play them.

If you want to better understand the details, is this:

1. it get the 20 most played song and their embbeding vector => each song is a vector of 200 number;
2. to this song it assign a weight that depends from how recent they wat played
3. it do an avaraged weight of all the embbeding of this song to create a single centroid, like an anchor in you library, your fingerprint
4. search for similar song from your fingerprint

How much change depends from you, but is difficult that toally change each day, probably you can have small change each week. This because sonic fingerprint is deterministic and the top played song/last played is not something that totally change each day.

Different is the clustering functionality:

• it sample a percentage of all your song collection randomly;
• from this sample it inizialize a clustering algorithm another time randomly;
• It keep the top (default 8) diverse cluster.

So with clustering at each click of the button you have a totally different collection.
Sonic fingerprint is deterministic, like also similar song functionality.

Song alchemy, for example, introduce the randomness too and you can set how much randomness you want with the sample temperature parameter.

Maybe what you are asking is starting from your fingerprint, that will not change to fast, but from that search from similar song (point 4) adding some randomness?

[grayhaze]

I guess I see limited value in the fingerprint playlist as it currently stands. If I'm playing a particular song repeatedly, it's almost certainly going to be in my favourited songs, which I can already play in random order without the use of AudioMuse-AI. So adding those songs to a randomised playlist each time the sonic fingerprint process is run seems like extra steps to achieve essentially the same goal, especially given plugins already exist for Jellyfin which build and maintain a playlist of favourited songs.

I hoped that this feature would sit somewhere between it's currently functionality and that of the clustering feature, creating a playlist per user which would contain songs similar to those most played over the past day or past few days, allowing for natural discovery without having to specifically choose a playlist for particular genre and/or mood which just includes random songs unrelated to my preferences. Something like Spotify's Daily Mix playlists would be ideal, where each playlist covers a similar grouping to the clustering playlists, but tailored to a user's specific listening habits.

I do accept that this was a fundamental misunderstanding on my part of how AudioMuse-AI worked though, so perhaps adding this functionality would be outside the scope of the project.