Just one thing: After a long deliberation, I've changed tag name from METAL ARCHIVES VERSION to METAL ARCHIVES EDITION (er... I tend to be "somewhat", ahem, pedantic regarding naming conventions - sorry).
In any case, script seems to be working fine on all previously mentioned cases (yours and mine), but I would like to have some confirmation before doing final merge.
Well, that was quick haha
The script seems to be in order, I've tested with a few examples (listed in here) among others that i've found as well. The data returned is ok, no issue has been discovered. As always, I'll keeping the testing in case of.
Again, great work! You really know about this.
PS: oh, I've been thinkin' maybe in a new feature: when an album has multiple versions, maybe look for a query that lists all the coincidences to choose the needed/right one. Maybe including it in the "search by artist + album" script. I think it will be useful, considering after MA updated his UI and allowed to add "versions" of the same album, the script always retrieves the first coincidence. But, well, my knowledge scripting is very limited, so i don't know if it's possible doing it with only a script.
Kind regards, and once again, good job! Cheers for that
Haha yeah, but I had a chance this afternoon (CST time), and wanted to have it done as I'll be offline 'till Monday.
Awesome! That's what I wanted to hear
I think that you'll like what I'll upload on today's release (well, in the next couple of hours)... I think that is what you're looking for, or at least something very similar (to some extent, I think).
A new update has been released (v20250418), and is available on Github repository.
Added
New tags to include album Edition/Version details, and a flag to indicate if a track is instrumental or not (see previous discussions on this thread for more details).
New "Advanced" scripts (Experimental - Please check README file on Github before using).
INC file to improve scripts maintenance.
Fixed
Issue with random empty spaces when parsing track titles on some split albums.
Changed
Reorganization of script code to improve scripts maintenance.
Updated README content.
Thank you @Jaeger1349 for all feedback, and also thank you @MilesMetal for the initial idea of using MA's Advanced Search - and apologies for the very late reply.
Disclaimer: This is most probably the most "aggressive" set of changes made so far (mainly due to INC file), so please let me know if there are any unexpected issues that could have been overlooked during testing.
Also, be sure to make a backup of your current scripts present on your system before applying new scripts on this update. This to be able to to go back to a functional state in case that something goes wrong.
Been a while since I've replied. I'm subscribed to the thread so have been seeing all the replies.
Thanks for your continued work on the script.
A couple of months ago I managed to edit the script using AI (yeah, I know) and got a very basic (and very janky) version of the advanced search working. I'll try this new version of out as I'm sure it will be far better than what I was using before.
(P.S. I decided against sharing that script out of respect and at the time all that cloudflare blocking stuff was happening too. It wasn't my own original work either so didn't feel comfortable sharing something when I didn't really know what it was doing.)
I hope that newest scripts are useful for your use case. Don't know if it can compete against what you already using (basic or not), but if something's missing please let me know as we'll see what can be done.
Out of curiosity, how the process to do that was? Call me "old timer" (and/or stubborn) but I am very, er, hesitant about AI stuff but I got curious about that as (I guess?) MP3Tag scripting language isn't that popular as other programming/scripting languages, and it won't hurt learning about it.
I completely understand the sentiment and I am also quite wary of what the future of AI will do. At least in this brief period where it's not yet completely taken over the world and ruined humanity we get to mess about with it and even in the somewhat basic things I've been using it for compared to some people, I've had some really great results.
Basically, what I did was upload the script to the AI and asked it to adjust it in certain ways. It took a bit of back and forth where I had to look at the script myself and sort of try and figure out what it should probably be doing vs what it looked like the AI was doing and basically be like "How about trying the URL with this format?". It would then provide an updated version of the script, I'd test it and keep iterating upon it until I had it working how I needed.
I've sent you a private message with the file it generated. You'll notice it uses hard-coded values as that's all I needed.
The script does appear to be working today, though I did not thoroughly test it at the time.
Your comment about the scripting language not being that popular is interesting. I had a similar thought when I was building it so I basically tried finding links to online documentation as Grok (the AI I used for this script) and Google Gemini can both access URLs and read information on webpages. I've often sent it Github links and it will review the code and use it.
The most recent thing I did was have it create a Python script to create a FIR WAV files that I want to use in Equalizer APO... granted the resulting file was a bit wrong but it was still able to read the Github page for AutoEq and adjust it's Python script.
Again, I am concerned about where AI might take us but it's been able to let me finish some projects I've wanted to try for years but just didn't have the knowledge or time to learn how.
I will say that AI for coding tasks is absolutely better suited to people who actually know how to read and write the code they're asking the AI to generate because it allows for much easier troubleshooting. There are some things I've bashed my head against the wall trying to make work but it may just be that the thing I wanted to do wasn't possible with the tools the AI was using.
If you want to use it yourself then the ones I've been using are:
Google Gemini
Can access online resources
Is good for code generation
The best current model (2.5) has the strictest limits of all the LLM's I've tried.
Grok
Can access online resources
Good for code generation but not as good as Gemini
Has less strict limits vs Gemini.
Claude
Probably the best option for code generation that I've tried.
Can't access online resources.
Has limits based on conversation length meaning you have to start a new chat every so often and explain in the new chat where you previously left off.
P.S. Grok is Musk's AI. Do with that information what you will.
As right now, everything's looking fine. I had an issue with one of the scripts (search by URL) and only with this one, it was giving me an error conection (if I recall it correctly, "URI must contains a hostname") but for some reason it dissapeared suddenly. I guess, idk for sure, it was a CloudFlare related thing or something with my own internet conection, but anyway, now it works normal.
And BTW, the new added features involving the advanced search are great! Basically you read my mind hahaha
I tried with greek, cyrilic, hebrew, chinese and japanese characters, but I'm gonna assume that others languages provoke the same error (thai, georgian, hindi, etc.)
EDIT: I have to include accentuated characters like ü ë ö á é, etc., etc...
Using the "Search by album" script, using greek and georgian characters for the search it returns not data:
A new update has been released (v2025.04.20), and is available on Github repository.
Fixed:
Encoding issues when dealing with UNICODE/non-ASCII on either Band Names, Album Titles, or both.
Parsing issues when dealing with albums that have UNICODE/non-ASCII characters on title.
Notes:
Due to nature of changes, this update is somewhat optional as it fixes issues present on Bands/Albums that are in non-ASCII/Latin scripts (e.g., Kanji, Greek, Cyrillic, Arabic). If you are not working with bands/albums that uses any of those (or other) scripts, this update could be skipped - nonetheless, future updates will contain changes included in this version.
Encoding changes applies to all scripts, including Band Info (which, honestly has been somewhat stable since inception).
Although issue with album title parsing issue seems to be fixed, please note that there's a chance that there could be another instances where scripts won't be able to retrieve album information and issue will occur again as it seems that MA have different ways to show same information based on language used on certain data (e.g. album title). If that's the case, please let me know on this thread comments, or raise an issue on Github repository.
My man, it's necessary make a correction to the files uploaded in the repository:
Only the "band info" script has this line:
[Encoding]=url-utf-8
All of the others have
[Encoding]=utf-8
So this causes the rest of the scripts to not work (the parsing error). I corrected by myself all the files and all are working as fine as can be, no issues detected with non-ASCII characters. That's for the moment. Cheers!
EDIT: I tried the "search by url" script, and it giving this error when non-ASCII characters are present by some reason that i can't figure it out:
If you reverse the changes, retrieves all the queries only if non-ASCII characters are present.
EDIT 2:
All scripts are working (except for the URL one, with the issue that I pointed out), but the issue with greek characters persists. I tried chinese, japanese, cyrilic and hebrew characters, and no problem was detected.
However, I would like to have more details about issues on "search by URL" as currently (with utf-8) it is working as expected on my end for both full UNICODE releases (using Cyrillic, Russian) as well mixed scripts (Greek + Latin, English) therefore I cannot reproduce the issue.
Other scripts have been fixed accordingly, and tested using same scripts/languages mentioned above.
Hi! I made a deeper research and testing using as base, the last version of the scripts without modifications (i mention this because for my tagging I modifiy a few names in the scripts for output and workflow reasons, mantaining all the source code integrity/structure):
It seems to be that the error is triggered ONLY (based in my tests) when the ARTIST field is in greek. When it's mixed with other languages, there's no problem.
I used all the scripts:
Band info script: returns data correctly with Greek characters.
Search by Album script: when the ARTIST has Greek characters, it doesn't retrieves data from the query.
Search by Band script: returns data normally listing the albums, if you enter in any, it doesn't retrieves data.
Search by Band + Album script: when the ARTIST has Greek characters, it doesn't retrieves data from the query.
Search by Band + Album (both advanced and advanced by format) scripts: when the ARTIST has Greek characters, it doesn't retrieves data from the query.
Search by URL script: using the script w/o modifications, these are my remarks:
These are the lines present now:
[Encoding]=utf-8
[UserAgent]=1
The script works fine as long as non-ASCII characters are absent. I proved with all the examples listed above, it gives an error like this in all these events:
With this case in particular, it retrieves no data, despite you can access the album using the "Search by band" script (we could consider this case like a "exceptional" one)
Based on this I'm curious about something... Can you please share a screenshot of your "Search by..." dialog box with URL pasted on it? Something similar to this:
Literally, it appears just like the link, without the conversion, and I made a quick check and all the link are copied in my dialog box without the conversion. Maybe that's the reason. Is it useful if i mention that i use win10 and a chromium-based browser for my daily use?
A new update has been released (v2025.04.23), and is available on Github repository.
Fixed:
Parsing issues when dealing with artists/bands that have UNICODE/non-ASCII characters on their name.
Notes:
I don't really know how widespread the issue described by @Jaeger1349 is (using non-latin names/titles/URLs), specially regarding URLs as it seems (based on my research, of course) that nowadays web browsers that doesn't encode UNICODE characters when copying URLs are not that common.
But in case that anyone else is having same issue with "non-encoded" URLs, I found this site (https://www.onlinewebtoolkit.com/url-encode-decode) that can convert URLs from their original form into a "valid" form. Just be sure to use "Encode URI" option.
Please let me know if there are any additional issues and/or comments.
. If not, not problem, at all.
