Museexmatch - Musixmatch for MusicBee [+ synced]

[aktor]

Works better but still skips some songs.
I will use this web link https://lrclib.net/search/<Album Artist> <Album> <Title> for missing lyrics.
Thanks.

[slonopot]

Well, as far as I can see lrclib.net has nothing to do with musixmatch. In your log there is, for example, "Hit The Lights" which is available under this title at lrclib.net but not on musixmatch. On musixmatch there are "Hit The Lights - Live", "Hit The Lights - Rough Mix", "Hit The Lights - Remastered", "Hit the Lights - Live at Rasputin Music, Berkeley, CA - April 16th, 2016", "Hit The Lights - Live At The Keystone, Palo Alto, CA / October 31st, 1983" and "Hit The Lights - Live At The Espace Balard, Paris, France / February 9th, 1984". Cleaning up is not a part of the plugin, the closest you can get to the Live entry is by adjusting the distance in the config file to 7 (" - Live" would be the difference in this case).

lrclib.net, however, has very simple API and maybe I'll make a plugin one day if someone's interested (I'm not).

[aktor]

Well it works well now. lrclib.net, as a second provider would be perfect.
Thanks for your effort.

[slonopot]

Thanks for testing, I made this version available on Github.

Here it is.

[sveakul]

FWIW, I have had absolutely no problems at all with lyrics retrieval using 1.04 since its release.  I do have both "prefer synced" and "only synced" set to false.  I hesitate to update to 1.06 because of that. Slonopot, can you confirm that 1.06 is targeted at fixing general issues observed by you, or at the user-specific issues from aktor?

I am wondering if some of aktor's search problems are/were due to geo restrictions.  If you google "russia blocked by musixmatch" you can see what I mean.  I don't know if aktor lives in Russia, just offering the information.  It is a fact that the entire Metallum/Metal Archives website is blocked by Russia's Internet authorities due to a dispute over its lyric content (ref: https://forum.metal-archives.com/viewtopic.php?f=3&t=131317).

[slonopot]

I hesitate to update to 1.06 because of that. Slonopot, can you confirm that 1.06 is targeted at fixing general issues observed by you, or at the user-specific issues from aktor?

We all have different music preferences and different libraries and because of that I specifically ask for those tracks that are failing to see what's going on. When I was checking out your yesterday's report, I noticed that the format for the artist aliases has changed from a simple list

Code

["a", "b", "c"]

to a list of objects

Code

[{"artist_name": "a"}, {"artist_name": "b"}]

Nobody does that. I clearly specify "app" version in requests and the service should provide compatible responses to ensure that even older versions of the application would function properly. I tested it against some of my tracks, it worked, I pushed an update and we're all set for another couple of years (hopefully).

After aktor's report it turned out that it wasn't the only change. I don't use synced lyrics, aktor does. In this scenario, when the plugin only works with synced lyrics, there were no results at all. When the previous version of the plugin was developed, musixmatch were using their own format for synced lyrics called richsync that I had to convert to LRC during lookup. Now richsync is gone, but the API reports that it exists and the plugin expects some data to be present in the corresponding fields, but there's none. Instead of richsync the app now uses "subtitles" which is straight up LRC, fixed this in 1.0.5 (and left synced lyrics only mode forced by mistake) and thought that now we're good.

Nope, not today. Turns out a paid (and a hella expensive) service is unable to configure their search properly. When the app is looking for something, it makes an undocumented "macro.search" API call and sends a query as a user would enter it in the textbox. And it's not working. For example, I took "Metallica -- Frantic" from aktor's report. I've looked it up here and didn't find it. Alright, I can find it here directly, but it's not available in search. When I do mine, this one exactly, my result is in the end somewhere and the plugin would return a result. Like, wtf is wrong with Metallica then? We have to work this out somehow since this trash behaviour directly affects the user experience. Turns out that there's a more granular search API. It's a part of a documentation for the paid users, but we will be using it for educational purposes only. We were educated by this API that proper search results are achievable. I believe that aktor tested the later build and confirmed that more of his tracks were covered by musixmatch.

My bet is that it was broken for a while, it was just never visible. The latest version should now get better search results and fix synced lyrics for those who use them. I personally made sure that I can get ordinary and synced lyrics for some of my tracks, the rest is up for others to check and report.

If you google "russia blocked by musixmatch" you can see what I mean

That's how we play. It's very rare when the private APIs are blocking something. Backend usually does not care who you are, middlewares (cloudflare, government, website frontend with server-side rendering) do. If the troubleshooting would lead me to think there's an obstacle on the user's side, I'll give some links to check that as well.

[sveakul]

Thanks for the very detailed explanation of the hows and whys of the updating from 1.04 to 1.05 to 1.06--INTERESTING, and I mean it.  Now I have the courage to update from 1.04 to 1.06 and not feel that the "If it ain't broke don't fix it" adage is going to bite my behind in some less-than-obvious way.

[sveakul]

Ever hear the expression "Even paranoids have real enemies"?  Well, this is a case in point.

After updating to 1.06, Museexmatch failed to return existing lyrics on the very first go from a streaming song verified to be there.  From the log, it was inserting the radio station name as the album name:

2024/06/03 20:31:26.777 | Info | Museexmatch.MusixmatchClient..ctor | Configuration file was used: allowedDistance=5, delimiters="&", ";", ",", verifyAlbum=true, addLyricsSource=true, trimTitle=true, preferSyncedLyrics=false, onlySyncedLyrics=false
2024/06/03 20:31:32.631 | Debug | MusicBeePlugin.Plugin.RetrieveLyrics | source="http://ice1.somafm.com/indiepop-128-aac", artist="Real Estate", title="The Bend", album="Indie Pop Rocks! [SomaFM]", preferSynced=true, providerName="Musixmatch via Museexmatch"
2024/06/03 20:31:32.631 | Info | Museexmatch.MusixmatchClient.getLyrics | Attempting to search for "Real Estate" - "The Bend" ("Indie Pop Rocks! [SomaFM]")
2024/06/03 20:31:32.631 | Debug | Museexmatch.MusixmatchClient.search | artist="Real Estate", title="The Bend", album="Indie Pop Rocks! [SomaFM]"
2024/06/03 20:31:32.855 | Info | Museexmatch.MusixmatchClient.search | No results for this search
2024/06/03 20:31:32.855 | Info | Museexmatch.MusixmatchClient.getLyrics | Nothing found at all

After rolling back to 1.04 and doing the same radio stream, different song (also verified to be there), though the search also included the station name as an album name, it did indeed find the song and return results:

2024/06/03 20:54:51.922 | Info | Museexmatch.MusixmatchClient..ctor | Configuration file was used: allowedDistance=5, delimiters="&", ";", ",", verifyAlbum=false, addLyricsSource=true, trimTitle=true, preferSyncedLyrics=false, onlySyncedLyrics=false
2024/06/03 20:54:57.496 | Debug | MusicBeePlugin.Plugin.RetrieveLyrics | source="http://ice1.somafm.com/indiepop-128-aac", artist="Andrew Bird", title="Make A Picture", album="Indie Pop Rocks! [SomaFM]", preferSynced=true, providerName="Musixmatch via Museexmatch"
2024/06/03 20:54:57.496 | Info | Museexmatch.MusixmatchClient.getLyrics | Attempting to search for "Andrew Bird" - "Make A Picture" ("Indie Pop Rocks! [SomaFM]")
2024/06/03 20:54:57.506 | Debug | Museexmatch.MusixmatchClient.search | artist="Andrew Bird", title="Make A Picture", album="Indie Pop Rocks! [SomaFM]"
2024/06/03 20:54:58.360 | Info | Museexmatch.MusixmatchClient.getLyrics | Got a hit

Apparently 1.04 is stream-aware and knows to not "deal with" album name (stream metadata almost never includes an actual album name)??  Anyway, BACK TO 1.04!

[slonopot]

You have verifyAlbum=true in 1.0.6 and verifyAlbum=false in 1.0.4. Are you sure you need albums verified? Plugin matches albums one to one and does not apply any edits, 99% of the times you don't need it.

Anyway, I only figured this after I built another version that will use both APIs in case better one somehow misses it and worse one somehow does not. Here it is, but it's not really necessary to use it at the moment since 1.0.6 can handle Real Estate - The Bend if you alter your configuration.

[Jafigg]

For MusicBee Portable users--maybe this explains it better

Thanks for your clear step-by-step... Works fine !

[sveakul]

You have verifyAlbum=true in 1.0.6 and verifyAlbum=false in 1.0.4. Are you sure you need albums verified? Plugin matches albums one to one and does not apply any edits, 99% of the times you don't need it.

Anyway, I only figured this after I built another version that will use both APIs in case better one somehow misses it and worse one somehow does not. Here it is, but it's not really necessary to use it at the moment since 1.0.6 can handle Real Estate - The Bend if you alter your configuration.

First of all, my apologies for not noticing I had set up 1.06 to verify album and that was what was causing the problem with streams--I really put my foot into that one.  I'm back to 1.06 using the correct conf options and all is working beautifully!

Not sure what you mean by "built another version"--is the linked one at pixeldrain a new "1.07" version?  If so, is it better to wait until you officially release it on github as 1.07?  Would also appreciate if you could clarify on "uses both APIs."

Finally, I noticed lately a new entry in the MusicBee "Lyrics Providers" list in Tags(2)--"lyricsovh.com"--that seemed to appear when you released 1.04.  Did that come from Museexmatch, and if so what does it do?  Is it the second API you referred to above?

BTW would appreciate it if you could add version numbers to the internal properties on your plugin's DLL, would help keeping them straight.  Thanks!

[slonopot]

Not sure what you mean by "built another version"--is the linked one at pixeldrain a new "1.07" version?  If so, is it better to wait until you officially release it on github as 1.07?  Would also appreciate if you could clarify on "uses both APIs."

When I first read your latest report I had an idea that the search is not really that messed up after all (since 1.0.4 is good for you) and the new API method that we use for educational purposes is broken as well (since 1.0.6 is bad for you). I was like damn, alright, let's mix all the available flavors and finally forget about this thread for another half a year or whatever. I made a build that is now uploaded on pixeldrain that will first try to search using a good lookup API, if it fails to return any results the plugin will use the [currently] broken ordinary search that was the main one in versions <=1.0.4. If even this fails, then the track is 100% not available on musixmatch. Then I went to test this stuff with your queries and finally figured out what was going on with your album validation. This rendered my previous efforts unnecessary and thus I figured I'll just drop the dll here since it's already done. I don't know at the moment if I need to make 1.0.7 from this build since it's another lookup for each nonexistent entry, on the other hand it's bulletproof. If someone here feels that it's better this way, I'll make one (hopefully) last update.

Finally, I noticed lately a new entry in the MusicBee "Lyrics Providers" list in Tags(2)--"lyricsovh.com"--that seemed to appear when you released 1.04.  Did that come from Museexmatch, and if so what does it do?  Is it the second API you referred to above?

Not mine, I don't have it and I only use my own plugins.

BTW would appreciate it if you could add version numbers to the internal properties on your plugin's DLL, would help keeping them straight.  Thanks!

I actually have them set in the plugin configuration, maybe I have to implement some other function from the musicbee API to make it appear in the settings. Maybe I will do it one day, maybe I won't, it's not that it's all documented well and is easily debuggable, that's the main reason there's just a configuration file.

[sveakul]

slonopot:  Thanks for the details on the pixeldrain DLL!  Sorry to make you have to go through all that extra work due to my own lack of attention     On the otherhand, it's cool to have the "bulletproof" method available too and I am definitely going to keep that one around!

Strange indeed then on that "lyricsovh.com" entry in the MB list--so you know I'm not hallucinating:


I went through the LyricsReloaded directory of YML files and it definitely is not there.  I then figured it was an unmentioned build-in to that plugin but Mayibongwe said it was not.  So a real mystery--unless it could be coming from MusicBee 3.6 itself, which I also just updated to from 3.5...  Steven had some built-in to the old MB versions, chartlyrics.com I believe is one.

As far as your file versions for the plugin I'm talking about the actual Windows Properties/Details tab;  here is what is shown for mb_museexmatch.dll 1.06:

[slonopot]

I'm too lazy to edit these for the properties, but I try to not forget to update versions that are reported inside musicbee, Plugin.cs lines 33-35. I'll just append these to description with the next update sometime.

[boroda]

I'm too lazy to edit these for the properties, but I try to not forget to update versions that are reported inside musicbee, Plugin.cs lines 33-35. I'll just append these to description with the next update sometime.

@slonopot, you could try this VS extension (free):
https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.PrecisionInfinityAutomaticVersions3

it's very powerful, but i'm currently using it only to keep "assembly version" (internal plugin version) and "file version" (which is shown in Windows Explorer) in sync.