Apple Music Profile
YouTube Channel
RSS Feed
Dupin
Join Together
M3Unify
30 Most Recent RSS FeedAirplay
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.
Updated Mono-Stereo Toggling
Apple changed a few things in System Preferences under Mojave which broke this script to toggle between Mono and Stereo output.
Here is the fix. You will note that it is a simple change to the line targeting the System Preferences' Accessibility window.
tell application "System Preferences"
reveal anchor "Hearing" of pane id "com.apple.preference.universalaccess"
end tell
tell application "System Events"
tell application process "System Preferences"
set frontmost to true
tell group 1 of window "Accessibility"
# pre-Mojave - replace the line above with the one below
# tell window "Accessibility"
set monoStereoCheckbox to checkbox "Play stereo audio as mono"
if (get value of monoStereoCheckbox) as boolean is true then
set ddMessage to "Switch to STEREO output?"
else
set ddMessage to "Switch to MONO output?"
end if
if button returned of (display dialog ddMessage buttons {"No", "Yes"} default button 2) is "Yes" then
tell monoStereoCheckbox to click
end if
end tell
end tell
end tell
if application "System Preferences" is running then
tell application "System Preferences" to quit
end if
For more details, read the original post.
Shortcuts and SSHing to Snow Leopard
Like you-wouldn't-believe-how-many other people, I still run an old Mac Mini with Snow Leopard on it. It's been pretty reliable as an occasional music server and we still use it to play iTunes internet radio on AirPlay devices around the house. It also manages some backup tasks on my network. It runs headless and I access it through Screen Sharing when necessary.
It is more difficult then it used to be to remotely control Snow Leopard with AppleScript from newer operating systems. At one time, you could just address the machine and run commands with a username and password. Now you need to set up SSH. I haven't done that and just use Screen Sharing.
But, believe it or not, the Run Script Over SSH action I described earlier works with Snow Leopard out-of-the-box. I will now set about creating a batch of Shortcuts to be able to quickly manage stuff on the Mac Mini with AppleScript, like playing a parrticular radio station in iTunes, shutting music down, changing AirPlay devices and so on, which I can call from my iPhone. Pretty cool.
Scripting to a Mac with iOS Shortcuts
I'm not particularly bowled over by Shortcuts on iOS. I just don't use my iPhone and iPads rigorously enough that I'm inspired to automate many tasks. But I get that it's a thing.
What I find very interesting however is that you can use Shortcuts to launch AppleScripts on a targeted Mac. So, while the "Music" actions on iOS are somewhat limited, there's actually some potential usefulness in calling scripts (via Siri, even) from your iOS device to control iTunes on a Mac.
A nice basic tutorial by the great folks at Late Night Software explains how set this up. Essentially, you use the Run Script over SSH action to enter an osascript command to launch a script on a specified Mac. If you've ever done anything with launchd then you will recognize some similarities.
There are some limitations. First, AppleScript does not run on iOS. So anything you want to do with this technique will necessarily be on one particular Mac. (While I can imagine that it is possible to run other SSH commands from that Mac to other Macs, making all of that swing is beyond the scope of this article.)
Second, I am working strictly with scripting iTunes on a Mac. Many other apps on your Mac can be controlled with AppleScript, too.
Third, there is limited opportunity for user-interaction and feedback. (Depending on the use case, it is possible to manage some simple back-and-forth user-interaction in Shortcuts. But, again: beyond, scope, article.)
So, considering those parameters, there aren't many iTunes track and playlist management things I'd want to do remotely; I'd prefer to be operating on track info while sitting in front of iTunes. But we can still use Shortcuts to perform some serviceable tasks with iTunes remotely, things that can't be done conveniently with the Remote app on iOS.
Below, I describe how to create some Shortcuts that can launch scripts on your Mac. One will save the currently playing track to a "Favorites" playlist, another to change the AirPlay configuration and, lastly, one that pauses iTunes for five minutes. These may give you ideas for your own Shortcuts.
Airport Express Firmware Update
I use three Airport Express base stations each hooked up to class-D amp/speakers so we can have music around the house. And this past week Apple—surprisingly—released a firmware update for these discontinued devices that gives them support for AirPlay 2. AirPlay 2 eliminates any audio latency between devices that may be playing simultaneiously (such as a pair of HomePods used in stereo). While this wasn't much of a problem at my house before the update—minimal latency was detectable occasionally and wasn't too distracting—I can attest that there is zero detectable latency now.
The Airport Express is a great option for creating an AirPlay audio network and you can still find them being sold as refurbs, used on eBay and elsewhere. They aren't exactly using modern WiFi or security protocols, but if this isn't an issue at your house it may be an inexpensive way to wirelessly extend your audio system.
The "Kitchen Express" on top of our refrigerator.
iTunes 12.7.3 Available
Apple has released iTunes 12.7.3 with support for HomePod and improved AirPlay interface. (Update: I'm not sure I am able to detect the "improved AirPlay menu".) More as it develops.
EPPC and AirPlay Bug?
A Correspondent alerted me to an issue he is seeing, and that I can verify, using the EPPC protocol to access the AirPlay device property via iTunes on a remote machine. For example, with Remote Apple Events enabled on a remote machine, a script like this—that up until recently worked—will fail:
tell application "iTunes" of machine "eppc://user:password@Remote-Machine.local"
set apDevices to (get name of every AirPlay device)
end tell
In this example, you would expect to get a list of the names of the AirPlay devices available on the remote machine. But instead, the script trips up on the word "AirPlay" with the error "Expected class name but found identifier". "AirPlay device" is a class name. Other conventional iTunes/Remote Apple Events routines work as expected.
Our Correspondent reports that this sort of script worked happily in the past; sounds like he uses it to control iTunes like a server on the remote machine. There have been EPPC-related bugs in the past that were introduced with Security Updates so I'm hoping this is one of those sorts of things and not a deliberate "security feature". File a bug if you can.
AirPlay Scripting Workaround
As previously noted, you can't do this without getting -1728 errors:
tell application "iTunes"
set apDevices to (get AirPlay devices)
end tell
But you can do this:
tell application "iTunes"
set apDevices to (get a reference to AirPlay devices)
-- see?
log (get name of apDevices)
-- or
repeat with aDevice in apDevices
log (get aDevice's name)
end repeat
-- or
repeat with aDevice in AirPlay devices
log (get aDevice's name)
end repeat
end tell
That's if you need to do that.
iTunes 11.1 Breaks Some Airplay scripting
[UPDATE: iTunes 11.1.2 addresses and fixes this issue.]
The latest version of iTunes breaks some scripts I posted when Airplay scripting was introduced back in the Spring.
Specifically, an error will be generated doing something as simple as this:
tell application "iTunes"
set apDevices to (get AirPlay devices)
end tell
Come on. It's gotta be a bug, right? You can still get properties of AirPlay devices and set the current AirPlay devices property by device name:
tell application "iTunes"
set apDevices to (get name of AirPlay devices)
--> {"Computer", "Doug's AirPort Express"}
set current AirPlay devices to AirPlay device "Computer"
end tell
Waiting to see how this evolves.
Toggle Stereo/Mono Audio Output
Correspondent Simon Crosbie has set up an amp and pair of speakers in his workshop which is connected to an Airport Express. Unfortunately, the speakers are some distance apart, so that he may be near one speaker or another at any time, and will only hear that channel's output. Simon wanted to know if there's a way to toggle between stereo and mono output so he can hear more than just half of a stereo recording.
Yes, there is a way. Go to System Preferences > Accessibility. Choose "Audio" in the left-hand list and in the panel that appears click the checkbox next to "Play stereo audio as mono".
Goodnight everybody!
Wait a minute. I almost forgot I wrote this script to do it:
tell application "System Preferences"
reveal anchor "Hearing" of pane id "com.apple.preference.universalaccess"
end tell
tell application "System Events"
tell application process "System Preferences"
set frontmost to true
tell window "Accessibility"
##--> pre 10.9 set monoStereoCheckbox to checkbox 2 of group 1
set monoStereoCheckbox to checkbox "Play stereo audio as mono"
if (get value of monoStereoCheckbox) as boolean is true then
set ddMessage to "Switch to STEREO output?"
else
set ddMessage to "Switch to MONO output?"
end if
if button returned of (display dialog ddMessage buttons {"No", "Yes"} default button 2) is "Yes" then
tell monoStereoCheckbox to click
end if
end tell
end tell
end tell
if application "System Preferences" is running then
tell application "System Preferences" to quit
end if
[UPDATE November 13, 2013: The original script has been updated for Mavericks. Note the commented line for pre-10.9 systems and the line that follows it. Set the monoStereoCheckbox variable using one or the other depending on the OS.]
[UPDATE October 17, 2014: Another change for compatibility with Yosemite. The line "set frontmost to true" is inserted right after the first tell application process "System Preferences" line near the beginning.]
I would save this script in the system wide Scripts menu (install it in ~/Library/Scripts/). Because the script uses (gulp) GUI scripting you must make sure that "Enable access for assitive devices" is checked in the Accessibility System Preferences panel.
Smarties among you can figure out how to switch mono/stereo when using AppleScript to change AirPlay speakers.
And bear in mind that while the script works with the current OS (and probably an OS that may be released this Fall), Apple may change the layout of the System Preferences panels in a future update, in which case the GUI scripting will have to be updated.
[UPDATE December 28, 2018: Mojave made some changes and the updated version of the script can be seen here.
