Thanks, next release will add support for AudioMuse Jellyfin plugin as Sonic source for smart flows.
This will most probably trigger some support from users on Github.
4 Likes
Great! Please also drop a message here when released!
Also would be great if you can add a link to audiomuse-ai GitHub repo somewhere (even because I suppose that user need to know that they had to install it server side).
Really really thanks for this.
Itās released in the beta version: Version 13.3.0 Beta 1
Iāll give it a try right away!
Edit: Hmm, Iām not on the beta channel anymore xD
Thanks for implementing this. Unfortunately seems like I canāt test it right now as joining beta after the release means I have to wait for the next update to get it. Looking forward to it
It might take a few minutes up to an hour to join the beta on Play Store. Just be patient. No update is needed 
Oh yeah, got it now. It used to install the beta version before if you reinstall the app after joining the programme, maybe play store changed how it works.
Also, tested the sonic based stuff and everything works perfectly. Thanks a lot @Tolriq and @neptunehub
1 Like
@Tolriq could a feature to create filter rules for the now playling list be added? For example filtering out a string like āgame sizeā, to exclude shorter versions of same tracks from getting added when using sonic analysis stuff that returns similar songs?
I agree with @Chandandharana that multiple similar versions of tracks are an issue, in my case itās ā[track]ā and ā[track] (Extended Version)ā, for example.
But Iām not sure if user-defined filters are the best way to handle this. Does Plex filter out such āpseudo-duplicatesā, or have Plex users reported similar issues?
If Plex filters them out then I guess we could try to find an algorithm for AudioMuse that does something similar. @neptunehub is currently working on detecting actual duplicates (which theoretically should be rare, but are more frequent in reality due to user library management issues), so maybe we could extend this to detect possible variations of a track.
Remixes might be another aspect to consider, but I guess those are usually sonically distinct enough to not cause problems.
I think Plex remove them, and with normalized distance we could probably detect them on client side.
Thereās plan to eventually add something to filter but itās a pain as each smart flow could eventually needs different rules or easy switching each time and itās an UX nightmare.
Would be best if Audio muse handled that simple too similar filtering.
PS: I donāt really use those features as Iām 99% of the time an album listener.
Duplicates are quite common if you for example have the album version as well as various compilations, EPs etc. that feature partially overlapping tracks, even in perfectly organized libraries. Then there are also different releases which feature different bonus tracks (Expanded Edition has 5 new songs on CD 2, Deluxe Edition features live recordings on the 2nd disc while CD 1 of both versions is identical).
How strict is the filtering? Iām thinking about jam bands like Grateful Dead, Snarky Puppy, Phish etc. where you can end up with over 100 unique but very similar live versions of the same songs if you collect the live recordings (I have 82 versions of āShofukanā by Snarky Puppy for example).
Yeah, I know there are valid examples of duplicate tracks. Iām just saying itās even more of an issue in practice because sometimes the exact same track is duplicated.
@Tolriq AudioMuse should already expose distances for the /similar_tracks endpoint, is that what youād need? Those are normalized, but relative to the initial track. For the /find_path endpoint it might make sense to include the distance between two successive tracks, and I guess we could also add that distance to the response for /similar_tracks.
One thing I noticed while trying out this feature is that for the āTransition Maestroā smart flow you seem to be using the plain /find_path endpoint (which returns a path of 25 tracks by default), and then you sample the returned tracks to obtain the maximum amount of tracks configured in maestro settings. But the /find_path endpoint actually accepts a max_steps query parameter that you could use directly!
I request more to apply filter like bad rated or marked as skip from mixes and other stuff.
1 Like
I just added it and is :devel right now.
Basically it have a threshold on the distance, where if below of a specific value it is marked as a duplicate and deleted. This in parallel to the already existing filter about exact same Artist and Title.
Just testing today it was able to find the same song with different Artist name::
ā [INFO]-[26-08-2025 16-34-07]-Filtering song (DISTANCE FILTER): āCome deve andareā by āMax Pezzaliā due to direct distance of 0.0000 from āCome deve andareā by ā883ā (Threshold: 0.01). ā
Basically was an Italian singer that first sign in the group 883 and then start signing alone with his name Max Pezzali and I had the title duplicated under two totally different Artist name.
This filter work on both the InstantMix (so similar song) and the path between two song.
now Iām just doing some testing about the correct threshold (that anyway is configurable by ENV variable) with the help of @Chaphasilor
Does it also mark same songs but of different lengths as duplicate? Like the āgame sizeā or āextended releasesā mentioned above.
@Chandandharana that depends on how close they are. Duration isnāt considered at all.
You could open an issue on GitHub (GitHub - NeptuneHub/AudioMuse-AI: AudioMuse AI: Leverages Librosa for sonic analysis and AI-powered clustering to create smart, tempo and mood-based playlists within Jellyfin and Navidrome API) and add a list of tracks that you wouldnāt want to hear in succession, along with their distance. To calculate the distance you can for example use the āPlaylist from Similar Songā page in AudioMuse for one of the tracks and then find the other track and its distance in the list.
Such a list could help us pick a good threshold for the filter
1 Like
Could the mbz recording ids help here? If the same song is carried across various comps and soundtracks, it keeps the same id each time. However, each demo, live, etc version has itās own id.
From my research (but if Iām wrong please help) the id of a song for MusicBrainze is made with the Chromaprint algorithm:
AcoustID - Wikipedia .
Basically it āanalyze the songā and hen match with other song. Because two audio canāt be always exact the same (maybe different version, different recording and so on) they calculate the distance.
What Iām doing is exactly the same. I reppresent the song with a 200 dimesnion embbeding vector and then I calculate the distance. If under some threshold I say āis the sameā.
Calculate the MusicBrainzId on top will only be and additional analysis on all the song, and I think we can simply get by understanding the correct distnace.
Using MusicBrainz/AcousticBrainz ID could be interesting if they would like to host in their database our vector information, but for now I didnāt received any responses in this direction (I wrote them here: AcousticBrainz: Making a hard decision to end the project - #22 by Neptunehub - AcousticBrainz - MetaBrainz Community Discourse and I also opened a tickeet in their Jira).
Do not mix AcousticBrainz and MusicBrainzId. The later are well known uuid that many tools use to references things.
Very interested in this feature. I installed the docker version of Audiomuse-AI on my N100 Mini PC. Itās analysing my 74000 FLAC files as we speak. Will take a few weeks I guess before it completes them all. Letās see how this works once it finished analysingā¦.
1 Like
Nice, feel free to share a feedback when finished!
Also if you like, from version 0.6.6-beta there is the possible integration with a centralized database where you can share your analysis data and get advantages of the analysis of other user. The idea initial idea is a fast analysis and in future (when more songs will be on the database) give song suggestions based on sonic analysis for music that you donāt have, to discover new music.