[WS] iTunes source script with multiple search criteria

[rboss]

@poster

Would it be possible to have a multiple-choice-selection in the search-by-box for country and language?

Short answer: No.
Long answer: After the introduction of the settings schema I immediately tried to incorporate it into my script. And yes, I can add a selection field with country codes -or even country names- into the 'Settings' menu. Unfortunately, due to the inner workings of the Web Source Framework, any value defined in Settings can only be called to modify the results of the initial query, at the earliest; and not the query string itself.

Simply put, there are 3 steps performed for any album search: initial query, parsing of query results, and parsing of album selection. They are displayed in the 'Search by', 'List of search results...' and 'Adjust tag information' windows.
For a country/language value to be applied effectively, it would need to be applied at the initial query stage, which is (currently) outside the reach of Settings' values.

During development I tried several solutions to get around this limitation; in fact I had been able to call country/language values preset on a test 'Settings' file to be applied when parsing album selection. But this meant that the initial query would still need the input fields already present; or alternatively to "lock" the initial query to one country and applying the Settings' values later. But having a limited initial query would go against the design and intent of my script - to get tags from iTunes/Apple in any (supported) country.

Ultimately I came to the conclusion that the current method (of dedicated input fields for country code and language) is still what works best. And due to the evolving nature of supported localization of Apple Music / iTunes services, not having hard-coded values also means that there is no need for releasing/installing a new script every time that a country is added/removed by Apple.

The best way I can answer your question is: I would like to have country/language available as settings, but currently it is not possible. To find out the country code of a particular localized album, my suggestion is to find that release's Apple Music page in your browser and get the 2-letter code form the URL. In this example https://music.apple.com/us/album[...]/123456789 "US" would be the value you're after.

---

EDIT: as for your request of a drop-down menu with a list of country values on the 'Search by' window, the initial query stage only allows (up to 3) search boxes; and besides, that list would need to be updated regularly (as mentioned before). As I am not the developer of Mp3Tag, this request would be better directed to @Florian.

---

Hope this helps.

[poster]

@rboss

As most players normally only recognize one field to represent the total amount of tracks in a 'set' (regardless of the constitution of that set), I decided to have the TOTALTRACKS tag field (native to Apple) reflect the total tracks of Disc. The total number of tracks of the collection (of tracks) is produced in a custom TOTALCOLLECTIONTRACKS tag field

That suits me very well, as I've been doing exactly that up until now, except for the fact that the TOTALCOLLECTIONTRACKS field has a different name for me, which of course isn't a problem. Up until now I've always had to enter the tracks in the collection manually.

However, I've noticed that in the case of an album with just one disc, TOTALCOLLECTIONTRACKS is also filled with the same value as TOTALTRACKS.
Is that done on purpose? I think it's more appropriate to leave TOTALCOLLECTIONTRACKS empty in this case, and that's what I've been doing up until now.

[rboss]

@poster

However, I've noticed that in the case of an album with just one disc, TOTALCOLLECTIONTRACKS is also filled with the same value as TOTALTRACKS.
Is that done on purpose?

Yes.

While I do understand your point of the redundancy of having TOTALCOLLECTIONTRACKS and TOTALTRACKS values duplicated in the instances of a single disc per collection; I'm fairly sure that someone else could argue that, for the sake of tag consistency across a collection, TOTALCOLLECTIONTRACKS should always be present regardless of the number of discs.

I came across several of these dilemmas when redesigning the Settings menu; and if I were to add options to consider every eventuality, I would end up with a very complicated menu and/or a very slow script. This meant I needed to make some compromises.
So I set myself some guidelines to manage my development process; one of them was "to have the script give as much information as I could from the database, as consistently as I could. Give the end user the choice of how (not) to use it".

In this case, TOTALCOLLECTIONTRACKS was possible, so I made it available. In the case of single disc releases, where TOTALCOLLECTIONTRACKS = TOTALTRACKS, that tag may be unnecessary (according to user preference), but it *IS* correct.

Another example is the YEAR tag, which in Apple Music mode is formatted as YYYY-MM-DDTHH:MM:SS.mmmZ
and in iTunes mode is formatted as YYYY-MM-DDTHH:MM:SSZ. It would be very easy to remove the miliseconds part in the script and have matching formats from both sources in results, but in order to be consistent with the source, the values must be shown as they come. Even I don't like it; but it is what it is.

In this case, the compromise was to make the possibility of toggling on/off that tag in the results; so that

@rboss

If you have no need for a TOTALCOLLECTIONTRACKS tag, simply keep this option unchecked

But I will consider adding your suggestion on a later release.

As a workaround (and you probably already do this), either remember to check/uncheck the option (or the tag checkbox in results) when working on single disc/multiple disc releases, or tag everything with both TOTALCOLLECTIONTRACKS and TOTALTRACKS, apply a filter like

"$if($eql(%totaltracks%,$meta(totalcollectiontracks)),1,0)" IS 1

and remove the unwanted TOTALCOLLECTIONTRACKS tag in one go.

Hope this helps.

[rboss]

Greetings to all;

Here is a maintenance update to my iTunes script with multiple search criteria; version 3.62.

Here's what's new:

Changes from v3.60:

• FIXED: fixed compatibility issues in macOS systems, which could cause incorrect results
  Because I do not own a Mac system, it's impossible to properly test my script in that OS. So I rely on the community for reporting issues on macOS, which was this case. To the anonymous poster that contacted and helped me troubleshoot this bug; you know who you are, and I thank you.

• FIXED: country code preset changed to "US"
  If you use v3.60, and read its release post, you may have noticed that

@rboss

The script is pre-filled for country= United States [US] and language= English [en-us], so change these values according to your needs.

when in fact the country input field was empty. This is now now fixed (and is as was intended for v3.60).

• ADDED: added [MinAppVersionMac] for macOS systems
  While fixing the compatibility issue in macOS, I also added the minimum Mp3Tag version requirement for this script.
  Please ensure that you have Mp3Tag 3.25a+ on Windows and/or Mp3Tag 1.8.22+ on macOS, or this script will return a version error.

• ADDED: 'Source' column added to query results
  With the previous version's introduction of dual tag source selection, I had also added the #_SOURCE tag to identify what tag source was being used on the 'Adjust tag information' window. The same information is now displayed in the last column of the 'List of search results...' window.
  Because the values shown here are never written to files, this column is permanent (the 'Show "#_SOURCE" tag' checkbox in the Settings file has no effect on this column).

• CHANGED: renamed all instances '"Apple Music" / "iTunes"' to the more comprehensive "Apple Media Tag Source"
  Again, Mp3Tag web source scripts were never intended to be working with 2 sources; and the [Name] field was intended for the title of a single source.
  The effect of this change is merely cosmetic, but I think it now better suits the behavior and dual-sourced nature of this script.

• CHANGED: minor code changes for script efficiency improvement
  The compatibility fix added a few lines of code; so I tried to offset this with minor improvements here and there.
  Version 3.62 technically has more code the previous version overall, but the impact on performance should be non-measurable.
  And while the main reason for this release was the macOS compatibility issue (and therefore Windows users have no real change from the update), I do not plan on splitting this project into separate OS forks, so further versions will probably be built upon v3.62.

Now then, here is the script version 3.62. Since the source settings' file was not changed with this update, the existing v3.60 .settings file remains the current version.

Use the link below or in the sticky (first post).

iTunes WS#362.zip (5.0 KB)

And enjoy your tagging.

[rboss]

It has come to my attention that the 'Apple Music' mode is no longer working.

I've looked into this; apparently the source data (from the album page) has changed formatting, so the current script can no longer find information where it was supposed to.

Since I don't know if this change in Apple Music page layout is temporary or not, I also can't predict if the issue will sort itself out or if a new script version will be necessary.

'iTunes API' mode appears to be working normally.

I'll keep looking into this.

[thick.crew]

Thanks for checking and keeping an eye on it! Your script was the reason I purchased Mp3Tag last month.

The iTunes one seems to have a bug where an album has a number of tracks, and then seems to not show the last track in the left column.

Example: My album has 16 tracks, the iTunes version finds that same album with 16 tracks, but the left list stops at 15. This is with every album I try.

Alt: Tag Sources window, left column 15 tracks, right column 16 tracks.

[rboss]

Hello @thick.crew, and Thank You for your report and support.

From your screenshot, I deduce that you're referring to this album; and that you're on a macOS system.

I'm assuming that you're using the latest (v3.62) version of my script and the latest stable version of Mp3Tag; on my (Windows) system I'm getting this result for the same(?) search, on the same versions (Windows app + script):

To rule out compatibility issues between OS versions, please check your app + script versions.
If all are up-to-date and the issue persists, this may be an OS issue.

I'll only be able to check this (from the Windows standpoint) over the weekend; in the meantime:
@Florian may I trouble you (yet again ) to validate @thick.crew's results and check if there are compatibility issues in macOS?

[Florian]

Yes, I can confirm this and I think it's related to a missing | at the end of the fields in the iTunes variant of the tag source. I haven't looked in the code (yet), but it looks like one of the issues we had before.

I'm not sure if we talked about that before, but each of the multi-value fields where values are separated by the pipe symbol | need to have a trailing |. Say "|" after filling each of those fields should serve as an easy fix.

[rboss]

@Florian

I'm not sure if we talked about that before, but each of the multi-value fields where values are separated by the pipe symbol | need to have a trailing |. Say "|" after filling each of those fields should serve as an easy fix.

I do recall a previous topic (of mine) where a missing trailing pipe symbol was causing issues. At the time, the solution was provided by you:

@Florian

I've analyzed the issue and it's related to a certain — until now undocumented — requirement by Mp3tag's internal tokenizer which splits a string using | as delimiters into its separate parts. It always expects a trailing delimiter character and if not present, adds it by itself.

Is this what you meant? If so, I was under the impression that the "|" character was only 'necessary' in cases where a multi-value field was missing the last entry of its set, and a Say "|" command would provide the final pipe as to not cause the internal tokenizer to behave unexpectedly. In fully loaded multi-value fields the issue would not occur, and the command for the final pipe was merely optional.

I had already fixed that in my script version 350,

@rboss

Thanks to Florian for his revised documentation of JSON tools, the previous patch has now been worked into a permanent fix. In the rare event that a censored dataset is incomplete, the script will now try to fill any gaps with uncensored data, or return an empty tag if none is found, preventing the propagation of incorrect results.

and without any feedback of issues under macOS, was assuming everything was working fine in that front. And under Windows it is as my screenshot showed -all tracks correctly parsed.

I'm aware that the performance impact is virtually zero, but as I keep trying to make my script(s) as efficient as I am able to, if a trailing "|" is not 'necessary' for normal operation I prefer to avoid using it. At the time, because the iTunes' advisory tag was prone to have missing values, the Say "|" was added (and is still present in v362). Since the other tags were completely filled, I considered a trailing pipe as non-essential and didn't add it.

Of course, if this is a macOS-only requirement then I will happily oblige, for the sake of compatibility (and keep it in mind form here on out).

@thick.crew Apologies for the delay. As you can guess from this exchange between myself and the developer, I don't own a macOS system, and thus am unable to test \ validate my script to work in it. So I have to rely on kind community members to run those tests, and it's not the first time I've had to play a game of 'telephone' with @Florian, where he instructs me what is wrong, I (try to) make the necessary fixes, and reply with a new (hopefully correct) revision that works under macOS. I do try to make changes that work in both OS's, but for Mac, I'm literally guessing and hoping for the best.

In this instance, as @Florian described, the 'quick patch' to restore iTunes API functionality is to add the aforementioned command where necessary. Which should be done in this beta:

iTunes WS#364_[US] - [English]_beta.src (14.7 KB)

As for Apple Music mode, some reworking of that part of the script will be required, and will take some time (plus some new planned features for the script). I prefer to release a half-working beta script now, than a fully working script, but not knowing when it would be finished.

So, please give this beta a try, and see if 'iTunes API' mode is working normally. Because the issue you reported didn't manifest under Windows, the fix also doesn't show any difference in results on my system.

@Florian if the pipe symbol requirement for Mac was mentioned elsewhere, could you direct me to that topic please? Given its importance, I'd like to get as much information about it as I can. And if @thick.crew, yourself, or anyone else in the community could provide feedback on this beta, I would appreciate it, and update the first post with this version.

And Thank You

[Florian]

@Florian

Mp3tag's internal tokenizer which splits a string using | as delimiters into its separate parts. It always expects a trailing delimiter character and if not present, adds it by itself.

This was related to the Windows version and applies to the Mac version as well — except that the latter doesn't add it by itself. So it's a requirement also for multi-value fields that don't miss the last entry and I'll try to document it on a more prominent place.

@rboss

to restore iTunes API functionality is to add the aforementioned command where necessary. Which should be done in this beta:

Thanks, this fixes the issue!

Please remove the calls to Debug and DebugWriteInput (the latter is not implemented on macOS, and those shouldn't be enabled on published scripts).

[rboss]

@Florian

Please remove the calls to Debug and DebugWriteInput (the latter is not implemented on macOS, and those shouldn't be enabled on published scripts).

Apologies -my mistake
Fixed in 3.6.4.

@Florian

I'll try to document it on a more prominent place.

Suggestion: a topic on the community -or maybe even a dedicated page in the Mp3Tag documentation, under 'Tag Sources'- with a side-by-side comparison of commands for both OS's and a list of do's and don't's. Given the nature of my script, I'm particularly sensitive to this theme and a centralized source of information would be helpful.

[rboss]

Greetings to all;

Here is a maintenance update to my iTunes script with multiple search criteria; version 3.66.
This revision addresses the (unexpected) change to Apple Music album pages' data structure which disabled normal script operation in 'Apple Music' mode.

Here's what's changed:

Changes from v3.62:

• FIXED: fixed compatibility issues in macOS systems, which were generating incorrect results in 'iTunes API' mode
  Many thanks to @thick.crew for their report; this was due to a difference in script operation between Window and Mac systems, and was already fixed in v3.63.

• FIXED: 'Apple Music' mode restored after changes in the source data
  Self-explanatory; Apple Music album pages have change the type and format of data provided, and that portion of the script had to be rewritten to work in the new environment. This job is not complete: there is some leftover (disabled) code; but with the time I have, I chose to prioritize patching my script to normal, and call it a beta, than to have a broken script for (possibly) several weeks. This version will be released as a beta, until the time I'm able to be confident no issues will arise.

• REMOVED: 'Apple Music' mode's tags for ITUNESADVISORY, ITUNESCOMPOSERID, ISRC
  These tags are no longer provided, since they are missing / incomplete from the source data. Regarding ITUNESADVISORY, its value is still somewhat provided as a binary 'Explicit /Non-explicit' flag; because this is different from the notExplicit (0) / explícit (1) / cleaned (2) rating of 'iTunes API' mode's source data, I decided to remove that tag as well (but it's still available in 'iTunes API' mode).

• CHANGED: 'Apple Music' mode's tag forYEAR now in YYYY-MM-DD format
  Again, this is due to the changes in the source data. If you prefer tagging in another date format, this tag can be edited in Mp3Tag to suit your needs.

I was planning to add new features, but circumstances force me to release a patch instead of a new stable version; for this, I'm releasing v3.66 as a beta. I'm working on improvements, but that will take time.

Now then, here is the script version 3.66. Since the source settings' file was not changed with this update, the existing v3.60 .settings file remains the current version.

Use the link below or in the first post.

iTunes WS#366_[US] - [English]_beta.src (14.6 KB)

And enjoy your tagging.

[thick.crew]

I am so so so sincerely sorry for not commenting, and commenting so late.

Thank you so much for the work you put into this! With 3.66 beta, I can confirm it works just like it always has!

[rboss]

Greetings to all;

Here is a feature update to my iTunes script with multiple search criteria; version 3.70-stable

This release follows v3.62-stable, and includes all the changes from the beta releases in-between. I'm also rolling out new features\improvements, centered on a better workflow for switching between tag sources.

v366b > v370 change log:

Fixed \ Changed:

• 'Apple Music' mode [_COLLECTIONADVISORY] tag partially restored

With the recent change to the Apple Music webpage source layout, the data used to fill the ITUNESADVISORY tag is no longer provided; the custom _COLLECTIONADVISORY tag was also constructed from the same data, but I've managed to restore partial functionality from an explicitness flag still present in the raw data. The reworked tag will now show in Album results as ['Explicit' | -absent-], when the previous version had ['Explicit' | 'Clean' | -absent-] values (as 'iTunes mode' does). It does still fulfill its intended purpose, which is to clearly identify when a collection contains one or more explicit tracks.

New:

• Added 4th search box for capping query results per tag source

On some occasions it's useful to have a high number of query results (usually when searching a generic term); whereas on long tagging sessions, having a lower results count is more desirable.
With the addition of the 4th search box, both scenarios are now possible, without having to resort to script modding. iTunes API allows defining a search limit in the [1-200] integer range; I've set the query field's default value to [50] to match the API's, so in most use cases there will be little need to change this (but now you can). Integers outside this range (and other invalid values) are considered invalid by the API, and normally ignored.

• Added current language code to 'Source' column and #_SOURCE

The language setting used in the initial search is now displayed both in the 'Source' column in Query results, and in the custom #_SOURCE tag in Album results, as an appended '| en' or '| ja' string to the current tag source. I have yet to find an example to test the 'ja_jp' language code, but it should display as well as with 'en_us'.

• Added custom tag LABEL to 'Apple Music' mode

Some Apple Music album pages have 'Record Label' information added (usually below 'Copyright'). If provided in the source data, that information will now be displayed in a custom tag in Album results. I've found during research that, while the ID3 standard has the PUBLISHER tag (and many times a Publisher and Record Label companies share the same name), PUBLISHER and LABEL are not the same, and therefore a custom label was the solution found to display this data while being ID3 safe (or trying to ).

• Added new setting option: 'Tag data source' -> < multiple >

The main new feature of this release. Previous selection of a tag source -between Apple Music and iTunes- so that one or the other data sources can be searched from a single script was already possible as a setting; but for quite some time I had been researching for a way to change sources during a search process, i.e. being able to swap between iTunes API mode and Apple Music Web mode without having to finalize a search (by submitting\cancelling), going to script Settings, changing the option, and starting a new search. Originally this was to serve my own troubleshooting purposes, because I needed a more direct way to compare results between modes, only to realize that others could also find themselves in a similar situation. It may seem simple, but fulfilling this took many development roads, and several builds to get to the current version.

As with the other values for this option, toggling 'Tag data source' to <multiple> will change how initial query results are returned; in this mode, results for 'iTunes API' mode and 'Apple Music Web' mode will both be made available as a 'set' for each album entry returned from iTunes query source: the first parsed line of each set will always be the 'iTunes API' one, followed by the 'Apple Music Web' one. When in Album properties, getting to the results of the other source of the same set is now as simple as going back once and selecting it.

I had mentioned before on a previous post, but Mp3Tag was never designed to handle a multiple source script; so in order to help tell apart which line refers to which mode, the 'Source' column in Query results will display the tag source name (it already did, and maybe it was originally added with this eventual purpose in mind ); also, 'Apple Music Web' lines will never show thumbnails in this mode (with preview thumbnails enabled).
This serves a few purposes: with thumbnails on, there will be half as many images for Mp3Tag to process (which would be duplicates anyway, and therefore redundant), meaning faster results and a less cluttered query list; and using the "iTunes w/ image | Apple w/o image*" rule of thumb, the desired source can be picked from the list at a glance (which is helpful on a large query results' list).

With thumbnails disabled, you can still tell each set apart by the contents of the 'Album' column and/or the unique number of the 'Catalog ID' column for each set (which also maybe was originally added for this eventual purpose ). The 'Source' column -again- tells each entry of a set apart; and when sorting, these 2-3 columns can be used to change the order of entries in each set (while maintaining the sequence of sets), and\or restore the list to a proper order in case of a misclick, so the results' list can be arranged in the order that best suits your current need.

This operation mode has the downside of not being able to have Album results directly shown when using a Catalog ID as a search term (because any query result will always generate twice the query list entries), which is why the 'Tag mode' in Settings keeps previous 'iTunes API' and 'Apple Music Web' options, which enable direct Album results.
I'm keeping support for these options for now, but I'm also considering removing them in the future, as having multiple tag source query results seems the best path to steer future development of my script.

---

After the review of the [ParserScriptIndex] script (responsible for query processing) to accommodate the new feature(s), I made additional tweaks to improve overall efficiency. The revised script only has an additional 3 lines from the previous stable version (including whitespaces \ disabled code) and, due to a new parsing workflow, generates a debug file ~40% smaller (in <multiple> mode) when compared with v3.62. Which is good news when considering now there are twice as many list entries for the same query results (I use debug file size to scale how efficiently my scripts run, where -while not accurate- smaller size usually means better/faster script).

With this new release comes a new .settings file (with the above-mentioned new tag source option). As each main version of my script is built upon the previous, older .src and .settings files should -unless stated otherwise- be removed.
This is of particular importance for .settings files, because -for example- if the scripts for both v3.62 and v3.70 were in the same \sources folder, modifying a setting for v3.62 will also modify its counterpart in v3.70, and vice-versa.
From what I've learned, modified script settings are saved as key-value pairs, and while a .settings file is linked to a .src file to prevent contamination, keys are not; so if a .settings file shares keys with another, and the 2nd file is linked to a script, changing a setting in the 1st file can modify that script, even if not directly linked to it.
The best advice I can give to prevent this is to remove older and unnecessary files from the 'sources' folder, and only keep the most up-to-date versions.

---

So then, here is the new iTunes WS script with multiple search criteria, version 3.70 -stable.

Please use the link below; and I'll update the first post with this version after a kind macOS user validates it for that system.

iTunes WS#370.zip (5.1 KB)

And as always, enjoy your tagging.

---

[rboss]

@poster

Hi,

Thank you for the continuous maintenance of your web source script.

I've occasionally noticed inconsistencies regarding TOTALCOLLECTIONTRACKS in some outputs between the Apple and iTunes sources.
Normally, the values ​​for TOTALTRACKS and TOTALCOLLECTIONTRACKS are identical for just one disc. However, sometimes they differ for the Apple source.
Example Catalog ID: 858492013

Greetings
poster

(...)

@poster

Example Catalog ID: 858492013

Live At Rockpalast (Live in Cologne 14. 05. 2009) by ...And You Will Know Us...

The IDs don't match - that's why I couldn't find this album. If you got the ID from your personal collection, be warned that source data IDs get changed over time, so an update might be useful.

As for the issue with TOTALCOLLECTIONTRACKS, the error is in the source data:

I could ignore this and have the script count the number of track entries, but on multi-disc releases a "$sum()" command of some kind would be necessary to keep adding the total tracks count of each disc, and none is available.

My script is working perfectly..... parsing incorrect data form the source :\
And since there's no reference to validate if the data provided is correct, there's not much I can do.

In this case, Apple Music posted incorrect data for this album (from experience this is not a rare event).
You'll have to manually correct your tag, or use iTunes mode (in this case, TOTALCOLLECTIONTRACKS is correct there).

Hope this helps.

PS: If you don't mind, I'll be moving this exchange to the main topic, as your question could be useful to others.

[rboss]

Greetings to all;

Here is a maintenance update to my iTunes script with multiple search criteria; version 3.71-stable.

v370 > v371 change log:

Fixed \ Changed:

• Updated [MinAppVersionMac] to 1.9.5

From the macOS v1.9.5 release notes:

@Florian

If the search string used for Tag-Sources function FindInLine was not found, the internal index was at the last character of the line instead of past the last character of the line.

Since this script uses FindInLine in such manner, an update was in order to prevent earlier Mp3Tag for Mac releases from eventually triggering this issue (I'm unable to test my script(s) in Mac environment).

The script itself is unchanged; for Windows users [MinAppVersionWin] remains 3.25a, so this update is optional.

Script settings are not affected, so iTunes WS#370#settings.settings remains the current version, and is (still) bundled in this release.

---

Here is the iTunes WS script with multiple search criteria, version 3.71 -stable.

Please use the link below; or the one in the first post.

iTunes WS#371.zip (5.1 KB)

And as always, enjoy your tagging.

[bookmark]

i had a tiny problem about apple music, it seems include have "LABEL" "UPC"
in "APPLE MUSC WEB" seems like "ISBC" cant be display.
It would be support display in future?

P.S and I see "UNSYNCEDLYRICS" it seems need a sub?

[rboss]

Welcome @bookmark.
English is not my native language (and I think it's not yours as well), so it's a bit difficult to understand your question.

From what I could read, you want to know why your music, in the Apple Music application, has tags like "LABEL", "UPC", "ISBC", and "UNSYNCEDLYRICS", and those are not available in the results of this script; if they will be supported in the future; and/or if they would be available with an Apple Music subscription.

My script, either in iTunes mode or Apple Music mode, only gets results from public databases maintained by Apple, which don't require any credentials to access.

The tags you mentioned are either not available or not provided for every release:

• "LABEL" is supported, but it's not always present in every release (for example, you can find it here but not here);
• "UPC" is not provided;
• "ISRC" was provided until recently, but Apple removed that information;
• "UNSYNCEDLYRICS" is not provided.

If this is not the answer to your question, please try to provide more details of what you would like to know.

[bookmark]

Thank you so much for your kind help! I realized that I do need an Apple Music subscription to access those extra tag details.

There's another WS (AM 4.0 Beta) shared in the forum — it uses a signed certificate and a proxy-based Python script, which works for my needs. However, it does come with some country restrictions, and a few minor issues like genre delimiters and album year inconsistencies. Still, it basically does the job.

That said, I was really impressed by the simplicity and efficiency of your WS — it's incredibly useful and has solved many of my data access challenges. I actually use both yours and the other script together as a hybrid solution. (I especially appreciate your setting for cover image size — being able to get 2000x2000 artwork is amazing!)

P.S. I'm not from an English-speaking country, and I'm aware that my spelling and grammar might not be perfect — I had AI help me refine this message to better express my thoughts. Thanks again for bringing your WS back to the forum. You’ve done a great job!

[rboss]

Thank you so much for the kind words! It feels very good to see my work being used & valued.

@bookmark

There's another WS (AM 4.0 Beta) shared in the forum

Yes, I know of @AreDigg's scripts for iTunes and Apple Music (and use them also). I consider having more than one author working on the same source(s) a 'good thing', because that leads to multiple projects that users can choose from. And seeing a different perspective in another creator's work helps improve my own.

@bookmark

I especially appreciate your setting for cover image size

That feature took a lot of development and help from the community (including @AreDigg) to implement, so it's always good to see it being appreciated.