Whilst browsing around this week, I discovered 'bliss-rs' (https://github.com/Polochon-street/bliss-rs) - which is a new-ish Rust based library for music-similarity. (New-ish as there was a previous, non-Rust, version named bliss). This is used for an MPD app/plugin named blissfy-rs to provide similar functionality to MusicSimilarity - i.e. adding similar tracks to the play queue.
Out of curiosity I created a trivial Rust 'app' (https://github.com/CDrummond/bliss-analyse) so that I could invoke this from MusicSimilarity. Ive added a pre-compiled Linux version of this app to the MusicSimilarity repo. I have tried to compile on Windows, but Rust pulls in ffmpeg and this fails to compile. So, for now, this is Linux only unless someone else can get this to build. This app is only required for analysis, and not to for API usage. Ive updated the MusicSimilarity analysis code to also allow analysing tracks with Bliss. This analysis is very fast, but takes about 2 to 2.5 times longer than Musly. For example I get -close- to 15k tracks/hour. MusicSimilarity can be configured to use Bliss instead of Musly to provide the list of similar tracks. (Ive made this the default setting for Linux). From my, very limited, testing it -appears- to provide (for my library) better results than Musly. It also seems to be currently maintained, so is probably a better long-term solution. (Musly itself has had no updates since Sept 2019) Id be interested in feedback on Bliss usage in MusicSimilarity from other Linux users or even Window users, if MusicSimilarity is used to analyse tracks under WSL. If you do try to use Bliss against a pre-existing MusicSimilarity DB, there is one small caveat. When initially writing MusicSimilarity Id assumed Musly would always be used so the vals column in the database (where Musly analysis is stored) has a not-null constraint. Basically, a track needs to have Musly results. You can fix this by using an SQL editor (e.g. SQLiteBrowser) to edit the tracks and tracks_tmp tables and remove this constrain from the vals column. If you do, then you can analyse track with Bliss only, and leave out Musly. *Material debug:* 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here. ------------------------------------------------------------------------ cpd73's Profile: http://forums.slimdevices.com/member.php?userid=66686 View this thread: http://forums.slimdevices.com/showthread.php?t=115609
_______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
