The various SORT tags will show in Extended tags if there is content in those tags. If those tag fields are empty, then the tag fields won't display in Extended Tags, to my knowledge. You can choose to add the fields in the Extended Tags interface and you can add them to entire groups of files at once, just as you can modify groups of tags at once in multiple files.
Music.app does not embed all tagging info or artwork as it has a separate database (library) file that it uses to store a lot of that information, but it will read tags that are already embedded in the files when the files are first imported. If you embed content later, you should delete the files from Music.app and import them into Music.app again, which will cause Music to read the tags. You can embed the artwork and I recommend that approach as the Music.app is notoriously bad at searching for and populating the artwork in the library database. Sometimes artwork will even just disappear, for example. If it is embedded in the files, you only need to delete the files and import them again to (generally) get Music to populate the artwork correctly again.
As for modifying the web source, you can open it in a text editor and start experimenting. There is another section of this forum for the development process of web sources and more experienced web source developers can likely assist you there with specific questions about building or modifying a source script.
Yes, you're right--I had forgotten that iTunes/Music.app keeps its own metadata database. The files I checked the tags on were actually originally purchased from the iTunes store (prior to the advent of Apple Music), but of course show up in my Apple Music library with everything else. I just downloaded a fresh copy of a few of those m4a's via Music.app and took a look at them in mp3tag. I do not see any of the SORT fields in the extended tags window.
I can't compare this with anything I've downloaded from the Apple Music catalog since those are all encrypted m4p files. But my general sense is that I don't think Apple populates those SORT fields with anything. So is this script just copying the provided ARTIST, ALBUM and TITLE data to both those and the associated SORT tags? Or does Apple ever provide specific data for the SORT tags that differs from the regular ones? Anyone know for certain?
EDIT: I know that artist names that begin with an article (a/an/the) get sorted by the word following that article, but that logic is handled automatically on the client side, not by a separate tag.
RE: embedded artwork - I was hoping Music.app's ability to populate album art would be much more reliable since all the metadata (including the presence of the underlying ITUNESALBUMID, ITUNESARTISTID, ITUNESCATALOGID and iTUNESCOUNTRYID tags) would match Apple's database precisely. Have you tested that scenario and still found Music.app to fail finding covers? If that is the case then yes I should probably go ahead and embed them.
I will check that other forum and delve into the script and see what I can figure out. Meanwhile if anyone has noticed any other differences between the results produced by this script and Apple Music/iTunes-sourced files, please let me know. I might be the only one who cares about this, but maybe there are others that share this particular flavor of OCD
There are no empty tag fields. If there is no content they don't exist and are not shown in the Extended Tags interface. The Extended Tag Interface is not configurable. It just shows all existing tag fields in the file.
The Tag Pnel instead can be configured and you can add input fields for tags there. They are visible there even if these tag fields do not exist in the file.
Right. I guess I could have worded that differently, but that's what I meant. I also meant that you can add, remove, and edit tags from the Extended Tags window. So yes, you aren't adding the fields because an empty field is non-existent tag, but my point is that you can add and edit tags with custom or standard fields for items like TITLESORT and such that won't display in the default tag panel. And in case there is some confusion I am discussing the Mac version of Mp3tag specifically and here is an example from the Mac version of what I am referencing:
Actually I found a way to accomplish this without a separate action...sort of.
I'm very very novice at this, so please take this as just a PROOF OF CONCEPT that it can be done by more talented people here.
What i did potentially breaks other tags...I didn't do a thorough comb through and test.... so if u want to use this unpolished inc, do so at YOUR OWN RISK. but I dug through the json and found two useful elements:
artistName = "Artist1, Artist2 & Artist3"
containerArtistName = the exact same thing but for AlbumArtist.
What I did:
For the first section where you choose which album/song. In the three locations it says:
#%Artist
json_select_many "subtitleLinks" "title" ", "
I added a line underneath:
RegexReplace "(.),(.)" "$1 &$2"
which replaces the last comma with a &.
Then in the next section that handles the actual tags, I commented out most of the existing code that handles Artist & AlbumArtist.
Finally lower in the script near COMPOSER I added:
OutputTo ARTIST
json_select artistName
SayRest
Say "|"
OutputTo ALBUMARTIST
json_select containerArtistName
SayRest
Say "|"
as well as one for ALBUMARTISTSORT that also uses containerArtistName.
So far this seems to work well for me, but I recognize it's probably not the best way to do this. But here is the modified .inc file. I just hope someone uses this information as a jumping off point to PROPERLY incorporate this, as again I don't really have much of a clue as to what I'm doing.
It is an interesting observation. I have checked a bit, and it seem like the web search now expects to originate from Apple Music web page on some search results with the same language tag. But it varies, and maybe also dependent on which store and country you are in. I am curious if there is a pattern here. I may have to use other methods for searching.
Now I see. It seem to be a bug in MP3Tag in that it does not respect the [WordSeparator] tag it is supposed to add %20 but does only add +, @Florian can you investigate?
But also quite right Apple has changed the behavior for the language tag in the search, now it removes it if it is not a supported language, or the store default language, thus triggering a redirect, and then adding %2B instead of %20. It does however support + as separator as long as it does not redirect.
Are you using the macOS version of Mp3tag? I couldn't reproduce it with the Windows version, but I've used a more general approach at encoding the search query with the macOS version.
I have discuss about this problem with @AreDigg in last few post, but I can assure this error which discovered from Apple Music Web (AMW) earlier this week and nothing we can do with whitespace because AMW encode url tag
%20 into whitespace.
whitespace into +
+ into %2B
These combined with redacted url language tag l=en which trigger redirect cause inaccurate search query. Search term such as Adele 21 turn into Adele+21. Short/popular term will return near perfect result (desired result as top most/1st search result), but longer/less popular term will either
Desired result not in top most/1st in list of search result
Simple queries produce good results, but when they get longer or contains special characters, the results becomes poorer.
I used the example that was mentioned above (Childish Gambino "Awaken, My Love!") in my script querying in USA English. I am using MP3Tag 1.8.1 on Mac.
Many thanks for the details on the issue and the example queries — those helped me to reproduce the issue locally (with the German version of the WS).
I've changed the composition of URLs in Web Sources Framework to use the Encoding and WordSeparator values from Tag Source definition with Mp3tag for Mac v1.8.2.
Please let me know if this solves the issue you've reported.
