Bug or Feature?
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.
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?
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.
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.
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.
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.
(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.)
I've been going crazy trying to track down a problem using AppleScript to convert a file and then duplicate the newly converted file's track entry to a playlist. No matter what I tried, the original pre-converted track is copied to the playlist and not the new converted file. Here's a stripped-down example:
tell application "iTunes"
set oldTrack to item 1 of selection
-- convert oldTrack and get a ref to the newTrack
set newTrack to item 1 of (convert oldTrack)
duplicate newTrack to somePlaylist
-- ...but oldTrack gets copied
Come to find out, iTunes 12.4.1 gets fussy about converted files when iCloud Music Library is active. As soon as the new converted file is created (again, via AppleScript) and added to the library, iTunes goes into its "Waiting..." mode—waiting to upload the file to the cloud. This apparently prevents AppleScript from doing anything with the new track entry.
This reminded me of how iTunes will warn you about editing a track (that is, about using Get Info) while it is waiting to be uploaded:
Strangely, all the properties for the new track are available. So, I tried adding it to the playlist using its location (file path); I tried persistent ID'ing it from library playlist 1 to get a reference to it; neither worked.
It wasn't until I shut iCloud Music Library off in iTunes > Preferences... > General that a newly converted track entry could be copied to a playlist. After some more experimentation with iCloud Music Library turned back on, I tried setting up a loop that waited for the cloud status of the new track to change to uploaded. But, since it can take several minutes for this process to be initiated, I abandoned this.
Primarily this will be a problem for Quick Convert, which has an option to copy converted tracks to a new/selected playlist (and, I suppose, any other script that works similarly):
If iCloud Music Library is ON, the "Copy new tracks to playlist:" option is ineffective.