Apple Music Profile
YouTube Channel
RSS Feed
Dupin
Join Together
M3Unify
30 Most Recent RSS FeedMojave
Do Some (Very) Rough Audio Editing in iTunes
This is not a tip for everyone.
You may be aware that Apple added some editing capabilities to Quick Look. For instance, Markup is available to edit text and image documents and Trim is available to edit video and audio files.
Using the script Have a Quick Look, a track can be selected in iTunes and its file displayed in a Quick Look window, via the qlmanage command:
The scrub/trim area becomes available after clicking the Trim button which initially appears in the upper-right corner of the window.
If this suggests to the suggestible reader that this makes a handy audio editor, think twice: editing this way is not very precise and accepted changes are permanent. But, for trimming large audio files of "dead air" or crowd noise or what have you, some may find it convenient.
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.
Apple Provides iTunes v12.8.2
Apple has released iTunes 12.8.2, an update for users who have not updated to Mojave (macOS 10.14).
If you don't see it in the App Store app, here is a link to a stand-alone version.
It apparently fixes some issues with AirPlay and, of course, makes the obligatory performance enhancements, and so on.
Trimming iTunes Audio With Quick Look
Mojave introduced some interesting contextual editing features to Quick Look. Quick Look was already handy for viewing disparate types of files in the Finder by pressing the Space Bar while a file was selected. Now, depending on the type file being viewed in Quick Look, various editing widgets will be made available.
I was very surprised when Apple first demo'd Quick Look in Mojave and saw that audio editing was a possibility. Albeit, it's just simple trimming—that is, audio can be removed from the beginning and/or ending of an audio file—but it might prove handy.
A few years ago I posted an AppleScript wrapper for the qlmanage command line tool, called Have a Quick Look. It allows you to select a track in iTunes and display a Quick Look panel of the selected track's file. A trifle, really.
But now that Quick Look has this new editing feature, Have a Quick Look could be a slightly handier tool. Here is a track from one of my "Live At Leeds" albums by The Who, which I have selected in iTunes and then run Have a Quick Look on. Pete Townshend famously talks a lot before each song. Now, I can trim that part out (sorry, Pete):
You can see the :40 seconds of Pete pontificating at the start of the track
Optimally, this sort of editing should be done with a Real Audio Editor. But if you're just fixin' Voice Memos (which can be added to iTunes by dragging from the Marzipan Voice Memos app) or something like that, I suppose this could be helpful.
Toggle Dark Mode
A variation of this has been around since the first beta, but what the heck:
tell application "System Events"
tell appearance preferences
set dark mode to not dark mode
end tell
end tell
Save it in Script Editor named "Toggle DM" (or whatever) and select "Application" as the File Format, which makes it activate by clicking on it in the Finder. I recommend putting it in the Dock or Finder window toolbar for quick access.
Updates for Mojave
As I mentioned last week, I have been updating scripts and apps for Mojave on a piecemeal basis. There are a good forty or so scripts now ready for Mojave Monday and the apps Dupin v2.14.2, M3Unify v1.11.1 and Join Together v7.8.2 have received initial updates for Mojave.
Mojave-ready scripts will explicitly state that they have been updated for Mojave. Otherwise, most scripts that can run on macOS 10.10 and later will likely be fine in 10.14. Except for being ignorant of your Dark Mode settings. And perhaps other very minor and benign incompatibilities.
Also, as I mentioned, the first time you run any apps or scripts of mine in Mojave you will be asked to "OK" access to iTunes.
If you click on "Don't Allow", you will need to visit System Preferences / Security & Privacy / Privacy and re-authorize the script.
I will continue to be cranking out updates over the coming days and weeks.
What About Dark Mode?
I wasn't rooting for a Dark Mode, the new low-light display preference in macOS 10.14 Mojave. And after working in it I don't particularly care for it. But I get that many people will find it compelling. So I'm guessing that there are a few "Dark Power" users who will expect that the scripts they download from this site will work in Dark Mode.
Well, they won't. Not all yet, anyway. In order for AppleScript apps and scripts to respond to Dark Mode they have to be built in Mojave. Anything built in prior operating systems won't know about Dark Mode. Now, other than updating the scripts just for Dark Mode, there aren't enough compatibility issues that necessitates a script to be updated yet (new security features, notwithstanding). Most all have been testing fine under the macOS 10.14 betas. So, in my opinion, there's no rush.
That said, there are some scripts and apps I will be updating for Mojave sooner than later, and these will include some of the more popular shareware apps and scripts. And then, eventually, as more scripts require regular maintenance they will be updated as a matter of course.
Mojave Security
Most apps from this site are 1) saved as read-only to inhibit malicious code injection, 2) codesigned with my authorized developer ID so that they will break if they are so edited and 3) packaged in a disk image that is also codesigned with my developer ID so that the disk image will not open if its contents doesn't check out. You—the user—also have Gatekeeper security options to allow just Mac App Store and/or developer signed apps.
Additionally, I would hope that my own personal reputation as a "good dude", cultivated over almost twenty years as an AppleScript developer, would also attest to the safety of my scripts. But that won't be the case for bad actors attempting to hijack processes on your Mac.
Apple is introducing a new level of security in Mojave called "AppleEvent Sandboxing". It effects how AppleScript is or isn't permitted to access certain locations and processes on your Mac.
When you launch an AppleScript of mine for the first time on macOS 10.14 Mojave you'll see something like this:
This message will appear before the app or script starts runniing or it may appear a little later into the launch, if and when it actually attempts to access iTunes. AppleScripts that work with multiple apps will display an alert for each of those apps.
(Personally, I think that "OK" button should say "Allow", but, whatevs.)
This is a new layer of protection that attempts to prevent AppleScripts, and other apps that use AppleScript, from controling apps and accessing data without you knowing about it. When you click "OK", you've acknowledged to the system that you indeed intend to use the script with said application. Once so acknowledged, you shouldn't see the dialog(s) again for that particular script.
Users of scripts that have targeted "System Events" may be familiar with this process when Accessibility requires a similar acknowledgement. This is a little different since it falls under the purview of Security & Privacy. In fact, if you go to System Preferences > Security & Privacy > Privacy > Automation, you will see the list of apps that use automation and which apps they target:
The list of apps on my machine is way longer than appear here.
If necessary, you can uncheck an app if you suspect the listed AppleScript is up to some funny business. Or, if you clicked on "Don't Allow" when first asked, you can enable access for a particular app.
Felix Schwartz has posted some first looks at AppleEvent Sandboxing and it's worth a read until Mojave is officially released and Apple tells us more.
macOS 10.14 Mojave Betas
Apple has released the first Mojave beta for enrollees of its Public Beta program. Developers have had access to two versions of the beta to date.
Like most developers, I'll be spending a lot of my Summer digging in to make sure my scripts and apps for iTunes are compatible and/or take advantage of new macOS features. And, as I caution around this time every year, if you are using the betas:
Don't count on current scripts and apps having complete compatibility this early. In my nominal testing so far, I haven't run into any serious issues with current versions of my software. But unless a script or app specifically states that it's macOS 10.14 Mojave-compatible, assume that it isn't—at least until the final release of Mojave later this year.
Early betas are simply not stable and can't be depended on for "mission-critical" work. If a script or app doesn't work like it used to it could be because the OS isn't fully-baked yet.
Report a problem! The whole point of the beta program is to expose problems. It's a good thing! If you have an issue with my software running under the Mojave beta, please let me know the details by emailing support AT dougscripts DOT com.
Thanks for your support and help!
