Bug or Feature?
The other day I dumped a couple of new AppleScript files into [home]/Library/Music/Scripts/ to make sure they ran OK from there and was surprised that the Music app did not recognize them and that they did not display in its Script menu.
Re-launched Music. Nothing.
Restarted the machine. Nothing.
Now, I am using the latest beta of Music on the latest beta of macOS 10.15.4, so maybe it's a beta thing. However, I've seen this behavior in the past and it generally is resolved by restarting Music. But not this time.
Anyway, if you are seeing the same problem, try installing the script files in the local Library location: [startupdisk]/Library/Music/Scripts/. That worked as expected for me. (I haven't tested this with scripts for the TV app.)
I've been unable to update and release several scripts that use the delete command to remove a playlist because it doesn't behave correctly. Here's a video that shows the issue.
I attempt to delete a playlist. After the script is run each time, the selected playlist is, ostensibly, deleted. However, the Sidebar does not refresh correctly. So that the deleted playlist's title is still listed, and when selected, the tracks of an adjacent playlist are listed instead.
Music will ultimately refresh correctly after being restarted.
In case you didn't know, a track entry in Music (and previously, in iTunes) can have more than one artwork image associated with it. In such cases, the first of its artworks is what I call the "display artwork" and the other artwork is what Apple calls...the "Other Artwork":
The "Album Artwork" image on the left is what is displayed throughout Music/iTunes as the artwork for the track. The "Other Artwork" doesn't get displayed anywhere except in the Artwork pane of the Info panel. And "Other Artwork" doesn't always mean other artwork singular; you can really go to town and add thousands if you want (probably; didn't try; crazy idea). Incidentally, I'm pretty sure only one image can be written a track's file metadata and that will be the "Album Artwork" image.
In AppleScript, a track contains artworks and each artwork is accessed by index: artwork 1, artwork 2...artwork 4732. The "display artwork" is always artwork 1.
I am currently preparing an update to the script Re-Apply Downsized Artwork, which, among other things, can insert a new down-scaled image as a track's artwork 1. If the track already has artworks, they are "pushed up" such that the current artwork 1 becomes artwork 2, the current artwork 2 becomes artwork 3, and so on, so that the new image can become the new artwork 1.
Here's the bug-or-feature part of the essay (mostly bug I'm thinking): When you ask for any other existing artwork greater than 1, Music gives up a parameter error. This makes it impossible for AppleScript to access any artwork data other than artwork 1.
I may release the update to Re-Apply Downsized Artwork that side-steps the "insert" feature, but I thought I'd explain why I haven't released it yet at all.
In case you haven't noticed: If you have downloaded a file from the cloud or have had Music provide artwork, the image data does not get written to the track's file, even though you will see artwork for a track throughout Music.
Additionally, there's no way for an AppleScript to access the artworks of these kinds of tracks.
If the files of your tracks had image metadata before updating to Catalina, then you probably don't have any artwork problems with those.
My specific issue is that files on machine A that have custom artwork I applied to them and that sync via Cloud Music Library do not have the custom artwork when I download them to machine B. Instead, they have whatever artwork Apple has assigned for the album.
I had hoped that there might be an AppleScript trick to workaround this, but as I mentioned above, AppleScript wlll error when attempting access the artwork data or raw data properties of these tracks:
tell application "Music"
set theTrack to item 1 of selection
count artworks of theTrack
--> 1 , accurately detects 1 artwork
get raw data of artwork 1 of theTrack
--> error number -1728
--> error "Music got an error: Can’t get raw data."
You can test this yourself, either with the script or by trying to copy the small artwork image displayed in the top left corner of a track's Show Info window and pasting it somewhere. It won't.
[UPDATE 10.29.19: Hey! Apple fixed many of these issues in the macOS 10.15.1 and Music v1.0.1 updates.]
The bug that some users were experiencing with Catalina scripts from this site has been discovered.
The code was not accounting for variation in system menus. Thus, the "invalid parameter" was an incorrect counting of menu items (the "itemArray").
My Mom isn't even going to care about that. What she and everyone else really wants to know is that I will update and re-post the affected scripts within a day.
I ran across this over the Summer and I forgot to file a bug about until today. When an AppleScript performs delete on a playlist, the playlist is seemingly removed from Music but its name is still displayed in the Sidebar. If you click to select this playlist—that was ostensibly deleted—the view from an adjacent playlist is displayed.
This leads me to believe there's some clean-up or reload that fails to occur. If Music is quit and restarted, the Sidebar of playlists will display as expected; that is, the "ghost" playlist that was deleted will not appear.
Some Correspondents have reported a problem when launching scripts for Catalina. The script doesn't launch and shows this error (screenshot from a Correspondent):
This was an issue that was reported several times during the beta period. I have been unable to replicate the problem myself on any Catalina installation. However, several users who reported it later found that—again, for unknown reasons—the issue eventually corrected itself.
It is baffling. The issue appears to occur during launch when the menu bar for the script is being populated. I'm keeping my eye on it, but, unfortunately, all I can recommend at this point is to check the script again after a few computer restarts.
Over the past few months—I want to say since Mojave's release last year—I have gotten a few reports from users of my artwork scripts regarding a bizarre corruption issue when applying artwork to some types of MP3s.
Essentially, when artwork is applied to the MP3, its file "echoes" the last few seconds of audio data which increases the size of the file. Here is a screenshot sent to me by Correspondent Brandon Pfeiffer, showing the phenomenon in an audio editor (I think it's Fission; no matter, really):
Each "echo" represents a single attempt to add artwork. The new size is reflected in the Size and Time for the file in iTunes as well.
I have not been able to replicate this myself so it has been very difficult to figure out what's going on. However, Brandon did some experimenting and discovered some details. First, it's probably not an issue with the AppleScripts, since Brandon was also able to see this issue when he "manually" applied artwork via a track's Info panel.
Some other observations:
- The source of the MP3s did not seem to make a difference (home rips, Amazon downloads, etcetera)
- The image file being applied may be a factor, its size, type, and so on. However, Brandon could not find a consistent factor in this regard.
- Changing the ID3 version in iTunes had no effect.
- Re-converting a corrupted MP3 to MP3 in iTunes restored the file to its un-corrupted length. (Subsequently adding artwork to such a file, however, eventually corrupted it again.)
- The new file encoded by iTunes did not appear to have the issue at first (the song duration did not change); however, closer inspection using an audio editor (or even just playing via QuickLook in Finder) revealed that the duration had in fact changed, but was yet to be reflected in iTunes.
- Re-encoding the corrupted file using FFmpeg produced several of the following errors: “Header missing - Error while decoding stream #0:0: Invalid data found when processing input”
- Re-encoding the original downloaded source MP3 using FFmpeg did not produce any errors.
Sure beats me. I'll have more follow-up as it develops.
[Update: Several Correspondents have emailed to confirm that they have seen this behavior after manually editing artwork; AppleScript was not a factor.]
Over the past few months, probably since the release of Mojave and iTunes 12.9, I've occasionally received queries from Correspondents concerning a problem with changing the tags of MP3 tracks. The changes wouldn't be written to the MP3 files' metadata or would revert back to what they had been before the change. It affects MP3s only, not M4As.
I was not seeing this myself nor was I able to replicate it, but, as I say, I was asked if I knew about it a few times.
This post at Apple Support Communities appears to have discovered a factor involved: AirPlaying to AppleTV. When AirPlay to AppleTV is turned off tags would be written correctly to the associated MP3 files.
I'm wondering if this could be related to another MP3 issue I have heard about recently. And this is weird. Whenever a script of mine is used that applies artwork data to an MP3, the file is mangled in such a way that the last several seconds of audio is copied and added to the end of the audio file (I said it was weird). I could not replicate this either.
Sometimes it's difficult to tell if a bug is really a bug or just a bizarre design decision. What I thought was a fixed bug might be the latter. The gist of this particular situation is that while you can select an individual Music track and change the Media Kind in its Show Info > Options panel to Music, Podcast, Audiobook or Voice Memo, you cannot select anything but Music on a batch selection. This post at Apple Discussions illustrates the issue with screenshots.
It is frequently desirable to change the Media Kind of Music tracks to Audiobook because these kinds of files are often imported as Music tracks. But unless you want to change each one individually there's only a complicated workaround that apparently requires deleting and re-adding.
I did not try this workaround. Instead I wrote this AppleScript that changes the Media Kind of the selected tracks to Audiobook:
tell application "iTunes"
repeat with aTrack in selection
set media kind of aTrack to audiobook
A Correspondent alerted me to the issue and he tested this script out on a few batches of tracks without a problem (thanks again, Stephen).
To use the script: Open it in Script Editor by clicking the little script icon above. Save it named whatever you like with the Format "Script" (.scpt) in your ~/Library/iTunes/Scripts/ folder so that it will be listed in the iTunes Script menu. As usual with little scripts like this its often expedient to add a keyboard shortcut.