Apple Music Profile
YouTube Channel
RSS Feed
Dupin
Join Together
M3Unify
30 Most Recent RSS FeedBug or Feature?
Error at Launch
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.
Applying Artwork in iTunes Corrupts Some MP3 Files
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.]
Metadata Not Sticking to MP3s? Might Be AirPlay and AppleTV
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.
Batch-Change Media Kind Bug
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
try
set media kind of aTrack to audiobook
end try
end repeat
end tell
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.
Album Loved No Longer a Thing?
I was playing around with Album Loved settings in the latest iTunes (12.7.4) and I'd have sworn the Album Loved was displayed as a single heart adjacent to the Album Rating. But not now?
Where's the love?
You can see that "Loved" is chosen in the contextual menu but there is no indication that anything is loved.
And it seems that in some Views, I can batch-set all the tracks to Loved, but not the actual album—or, at least, this is not being displayed.
I'm leaning towards "bug".
UPDATE: Steve MacGuire reminds me that the Album Love heart is still visible in a wide-enough Artwork column in Songs View:
But I rarely use this configuration. So now I'm wondering if I am "mis-remembering" the Album Love heart in Album View?
Bug or Feature: Downloaded Playlist Not AppleScriptable
iTunes 12.7 introduced the "Downloaded" playlist that can be made accessible in the Library section of the Sidebar. Ostensibly, this playlist contains all the tracks you have downloaded in one way or another from the Apple Store, iCloud Music Library and Apple Music.
Unfortunately, the Downloaded playlist is inaccessible to AppleScript. The following script should 1) get a reference to the selected playlist and 2) get a reference to the selected tracks, but it does neither:
Thus, any script that needs this information to work with the Downloaded playlist will fail.
iTunes Folder Missing?
A couple of Correspondents have reported that fresh installations of Sierra do not have a "iTunes" folder in the User Library folder (~/Library/iTunes/). Traditionally, this folder contains the "iTunes Plug-Ins" folder and the "Scripts" folder (see my Download FAQ page for more details). Additionally, some third-party apps may use this folder for caching their own iTunes-related files. However, the "Scripts" folder is not created automatically and needs to be created by the user; and I believe Apple has lately inhibited the use of third-party visualizers such that the "iTunes Plug-Ins" folder may no longer be necessary. Perhaps, therefore, the ~/Library/iTunes/ folder is not created automatically anymore either.
To repeat: this seems to affect clean installs of the latest Sierra and iTunes 12.6 and later. If you already have these folders configured on your machine they will not disappear when you upgrade the operating system—at least, that's been my experience.
iTunes still looks for AppleScript files in this location to make them available in its Script menu, so if your system isn't configured with the ~/Library/iTunes/ folder you will have to create the intermediate "iTunes" folder there and then the "Scripts" folder within it.
AppleScripts can also be installed in the /Library/iTunes/Scripts/ folder—that's the [startup disk]/Library/ folder and putting AppleScripts here makes them available to all Users. Again, the "Scripts" folder may have to be created by the user.
AppleScripts will appear in the system-wide Script menu in the Menu Bar when they are installed in ~/Library/Scripts/Applications/iTunes/ for the single User or /Library/Scripts/Applications/iTunes/ for all Users.
Another Ambiguous Property Value
Not too long ago, a version of the iTunes scripting definition used the new value "music" for the media kind property. Unfortunately, this caused confusion with the similar "Music" value for a playlist's special kind property. This was eventually fixed such that "song" was used instead of "music" for the media kind property. All's well now, right? We'll never see a mistake like that again, right?
Never say never.
It happens that "songs" is an enumerator value for the search command as well as for the new shuffle mode property. And, unfortunately, when "songs" is used as the search command's only value—eg: search somePlaylist for "my search text" only songs, indicating that one wants to search just song titles—some kind of ambiguity issue causes a reversion to the default all value. Thus, every tag is searched for the search term instead of only the song titles and you'll get a lot more search results than expected. For example, in searching my Movies library for "Big", I not only got "The Big Lebowski" and "The Big Chill", but a bunch of other movies that had the word "big" in their description tag.
Ironically, a search of the scripting definition file may have caught this before "songs" was re-purposed for shuffle mode.
This affects at least one script of mine, Search Results to Playlist, which I'm fixing with a silly workaround using hard-coded enumerator codes in a run script handler. Yech.
Artist Photos
Kirk wrote about missing artist photos in iTunes for one of his Macworld columns recently. This is an effect that was introduced in iTunes 12.5 and the iOS 10 Music app. It is disappointing to have so many microphone logos and tiny artist photos in one's library.
Several correspondents have inquired about fixing this with some kind of homebrewed kludge, but I'm afraid not. Artist images are handled internally by Apple and the iTunes/Music apps. There is no "artist image tag" or hook or cache or anything like that such that images can be supplied by the user.
Issue With Work and Movement Tag Text
(This post has been updated, see below.)
A Correspondent emaIed to point out that when text is entered in either the new Work or Movement Name tags and the text contains non-English characters they do not render correctly in Albums and Artists Views. Nor in the Info window:
So, watch out. This may be a display issue but I am not sure if Apple can fix it at their end or an update to iTunes is required.
UPDATE: FWIW, this is how it looks in the XML. Note that the Name tag is fine, but not the Movement tag:
UPDATE ALSO (September 16, 2016): This issue appears to have been resolved today after re-entering Work and Movement text.
UPDATE MORE (September 16, 2016): Spoke to soon. If the track is played then the NULL character returns. (Is that what that diamond-question mark character is called? Been a long time since I've seen it on webpages.)
