afconvert(1) - an audio file format converter, which includes Apple's superior AAC codec from the Core Audio framework
diskutil(8) - tons of tools for fixed and removable storage
Oh wow! A while back I ripped some concert audio from Youtube, but it was too large for me to sync using my `iTunes Match`. I've been too lazy to figure out how to downsample it juuuuust enough. But it looks like this works right out of the box
Mostly I use XLD (https://tmkk.undo.jp/xld/index_e.html) for audio conversion (as I'm mostly converting from .BIN + .CUE to "iTunes Plus" AAC for uploading to iTunes Match); but my understanding is that under the covers it's mostly just using afconvert (or whatever the system-framework equivalent of it is.)
So if your needs are just "one audio file in, one audio file out, and let me tell you exactly what it should look like", then afconvert is probably what you want.
XLD is great.
The best thing about it is the heavy parallelization if you have many cores to throw at the problem.
You can convert mountains of albums very fast.
Yes, iTunes also uses the same Core Audio framework. In fact, even iTunes on Windows uses the same code base through the Quicktime-for-Windows libraries it runs off of.
I prefer to encode with afconvert on the command line because it gives me a few more options for tweaking things, that I don't have access to in iTunes (or "Music" as it's called these days). Additionally, I use a simple shell script that handles all of it when for example ripping a whole CD.
afcovert uses the superior inbuilt AAC converter. FFmpeg can do this as well with the right arguments but you have to dig them up and the quality is capped to a lower value than you can get with afconvert.
I have three reasons: when using a good encoder (Core Audio, FDK or Nero) it's a quality-wise better lossy format than MP3, it's smaller than FLAC which matters for storage footprint, and unlike Opus and FLAC it's supported pretty much everywhere. At some point Opus will reach the same level of adoption and that's the point where I'll make the switch from AAC, because Opus is evidently a better lossy encoder per same bitrate.
ffmpeg offers a few different encoders for many of its supported audio/video formats, and the result depends on what encoder you tell ffmpeg to use. It does not have support for using Core Audio on macOS but it does offer FDK AAC, which is one of the better AAC encoders available today - though not nearly as good as the one available in Core Audio.
Do you have any sources/informations on an objective comparison of encoders quality ?
Way back then (iPod era), I made an exposé for a science exam (small paper), proving that AAC was indeed better than MP3 both subjectively and objectively at most bitrates. This is how I got introduced to Fourier transforms and the likes; it was very interesting to see that you can literally "see" the difference in quality on the encoded waveform output.
But I just used the default encoders on the Mac and I didn't think about going in deep into encoder comparisons at the time.
Does it matter that much? From what I know, it just about properly programming a math spec, with some tricks but I wonder if that makes that much of a difference.
In any case, above 256kbps it takes a very skilled listener to correctly identify encoded music. Apple has some useful tools for that, particularly AU Lab that allows you A/B testing of tracks with on-the-fly encoding.
https://www.apple.com/apple-music/apple-digital-masters/
One source would be the Hydrogen Audio forums where there are regular scientific comparisons - PSNR etc. instead of blind listening tests - between various encoders and formats. Apple's AAC encoder consistently comes out well above anything MP3, best of all the AAC encoders, and up at the absolute top together with Opus which produces a bit better results per same bitrate.
> Does it matter that much? From what I know, it just about properly programming a math spec, with some tricks but I wonder if that makes that much of a difference.
It does matter a lot and the difference can be staggering. Producing the audio bitstream is a case of both effectively analyzing the original input and programmatically expressing the waveform as correctly and as efficiently possible. Two excellent examples: the old MP3 encoder Xing, which compared to LAME produces very poor material even at higher bitrates, and one of the earliest open-source AAC encoders, FAAC, which also renders a very poor product. A lot of "early adopters" got bitten by FAAC and many of them still stubbornly cling to the misunderstanding that AAC is a worse format than MP3.
OK I get it.
Isn't all that because it is rather hard to correctly implement such math trickery?
Since it's not just about manipulating bits, you need to have a pretty good background in physics to do it properly. The more you know about the physics of sound the cleverer you can be about what to discard and what to keep.
I have used Mac since my youth and used iTunes before it was even called that, so encoder quality was never a problem I had.
I guess I'll revisit the topic more deeply one of these days, still not that keen on that much math though.
>From what I know, it just about properly programming a math spec
Incorrect. The specification only concerns the bitstream and the decoding. Encoders are free to do whatever they want, as long as they produce a valid bitstream.
Of course, the implementations are going to have varying performance depending on code quality/optimisations but that's a given.
Edit: some other poster gave some cues to my question.
I guess you can do some trickery by decomposing the waveform before encoding and recomposing it.
"superior" ...
It looks silly to include such a judging adjective in the description of a comman line utility. I don't need "subtle" Apple ads on the command line. And aac is about the last format I would choose, encoding my audio in.
To be very clear, the man page is claiming that Apple's implementation of the AAC codec [the encoder specifically] is superior to other implementations of AAC encoding; not that AAC is superior to other audio codecs.
If you're wondering how one implementation of an audio codec could be superior to others — mostly, it's because any lossy audio codec has an encoding phase called "psychoacoustic compression", where each implementation of the codec is free to do whatever it likes to "simplify" the waveform in some way (most easily pictured: by taking a Discrete Cosine Transform of the waveform, and then quantizing / convoluting some parts of the frequency space. Like what JPEG does to discard information from the chroma channels.)
IIRC, rather than blunt-force quantization, Apple's AAC encoding does clever things (akin to the instrument separation done to audio in Melodyne) to split the waveform into "features", and then discards information in such a way that the features' separability is maintained (i.e. it doesn't become harder to "pick out" any given "sound" from the audio.)
Its quality is technically superior as evident from the product's PSNR and other factors. There are no "ads" here, I'm not a brand warrior, and nobody cares what formats are the last ones you'd encode your audio in.
> (Uses built-in macOS capabilities for transcription from audio to text.)
Question (to self, currently researching)... Which capabilities? Released when? I ask because Apple Intelligence has expanded the use of audio transcription features.
Answer: `hear` uses SFSpeechRecognizer [1] which has been available since macOS 10.15. I'm not yet sure how it relates to Apple Intelligence transcription services.
Note: "speech recognition is a network-based service" which perhaps suggests Apple Intelligence (the marketing term, not an Apple Developer term, I don't think) uses it as well
I used Platypus to make my simple command line tools accessible to coworkers who considered the command line to be "too much" to learn. I've loved that app for close to two decades.
open -n file.pdf : opens new instance of Preview application which is useful if you want to open the same file twice (for example to look at different pages at once).
caffeinate -d : prevents display turning off, useful if you want to look at display without moving mouse.
You can use it to pass a pid to keep the computer awake until that process completes. I use it for longer-running scripts that I don't want interrupted
Finder is pretty good, and it's handy to be able to open it from the terminal. But I find it super annoying it litters everything with .DS_Store files and there is no way to turn that off, except for external and network drives. Aside from, obviously, using a different file manager. Very un-Apple.
Well those files are to keep the view/presentation settings.
I guess you could do that centrally with some sort of database but that would open another can of worms; and most importantly you wouldn't be able to transfer a folder and keep its Finder presentation intact.
Nowadays it's not as useful because of the App Store but when software was only released as .dmg images, it became expected to open a nice layout with graphics presenting the app and a shortcut to the App folder that you would drag'n'drop the app bundle to.
This presentation relies of .DS_Store to work.
There are some other use cases like that, it all comes down to a simple fact: Apple has always cared a lot more about how things look than Microsoft ever did, this is a perfect example.
I don't think xattr works for folders. And you still wouldn't have the fancy presentation you can get with .DS_Store with the graphics and all that jazz.
Of course, they could rethink the whole thing but the point is that it's a legacy thing and at this time it's not worth dedicating much ressource to a solve problem just to remove some mostly invisible files (on UNIXs).
It's really easy to have scripts to cleanup for sharing to outside world, even some zip utilities do that automatically.
It can be annoying but it's really not a big deal, I doubt they could come up with something much better while still preserving the functionality and not making another complicated/convoluted proprietary folder format that wouldn't transfer any better to Windows...
The .DS_Store files are not Finder specific; Apple treats everything as a file (including folders), and it exists to supply folders and the files within them with metadata.
It is just the first time the .DS_Store file is needed is often when the folder is touched by Finder.
Disk Utility used to be excellent, a model of how an app should be.
But then they rewrote it in Swift and now it's just bad.
Apple promotes Swift heavily but the results are not really encouraging.
I don't think the "so-so" results are entirely because of Swift (probably due to newer, less battle tested software and also newer/younger devs) but still the fact is, all the not-so-great new software from Apple came with Swift rewrites, hard to not make a connection...
I have known the UI bring bad in general and I think it has more due to APFS… I used to be able to do backups but APFS is so different to everything else that at this point I wish Apple switched to ZFS but honestly that wasn’t gonna happen after the buyout of Sun to oracle .
AFPS is more complex yes, and it's sad they let down Time Machine (somewhat) with it, considering the capabilities.
But that's pretty much on point with current Apple, they would rather have you pay for iCloud "backup" than make an individual/personal solution that doesn't require subscription to their services.
It's a bit sad because the whole point of Apple was, "we are not IBM" after the PC got its start. They are very much IBM now.
As for ZFS, it has its use for sure (servers) but it's very heavy on ressource and very complex. I don't think it's just because of the buyout of Sun, overall, it's just overkill for a personal computer; and since Apple completely left the server market, even for SMBs, there is no real reason to push for it.
In the end it's not really about any filesystem, the problem is mostly that Apple is not a user focused company as much as it used to be. They could make better technical UI/Apps/Solutions but they don't care that much, they make too much money selling gadgets (those are good but really not the same thing as "proper" computers).
If you have a modern Mac you have very little business using `pdisk`. It is only for editing disks mapped with an “Apple Partion Map”. This is obsolete replaced in practice by GPT on modern apple machines.
It happens but Ctrl-R has helped me get much better at finding commands I’ve used even just once before based on some tiny thing I remember about them.
Ha, when I search through my history I usually find I ran them exactly once, right after installing, and then forgot all about them. But there are some exceptions, I often use httpie instead of curl, MTR is great, I am liking doggo instead of dig...
That's the difference between recall memory and recognition memory. The GUI took off because we can recognize a menu and easily figure out where we need to go, versus having to memorize obscure and cryptic commands. Honestly having a LLM spit out command line arguments is probably the best way forward if things don't have a GUI.
I found a tool of mine submitted by someone else on the site (pleasant surprise!) and I want to update the description and add a more recent/better image. How would I do that?
nc(1) - netcat, arbitrary TCP and UDP connections and listens
networkQuality - Speed test + network stress tool.
system_profiler(8) - Useful way to grab extensive system information in shell scripts.
wdutil(8) - wdutil provides functionality of the Wireless Diagnostics application in
command line form.
And for those of us who have to support macOS users:
sw_vers (to display the version/build of macOS),
dsenableroot (to enable the root user), and
say "phrase" (useful for freaking out users over a remote SSH connection)
If you want the least useful macOS commandline utility, 'pdisk' is:
"...a menu driven program which partitions disks using the standard
Apple disk partitioning scheme described in "Inside Macintosh: Devices".
It does not support the Intel/DOS partitioning scheme[.]"
Sort of like command+k in the Finder, connects to a server. You can type in vnc://host or vnc://localhost:port... the latter is for VNC to hosts via an SSH tunnel.
As they seem to have removed Bluetooth Explorer and all ways to get diagnostic info about the bluetooth system and/or change codecs and settings, does anybody know any good cmdline ways in later mac osxes to do the same?
For example I'm having a problem that comes and goes now and then where Bluetooth audio is 300 ms delayed compared to the video playback everywhere except in Youtube on Safari, very strange. It's good for a few months then suddenly it becomes unusable, then back to zero sync delay after a few months.
I was thinking this might be related to CODEC selections etc or some hidden setting that might get changed which we normally aren't allowed to determine :)
(btw I know there is a difference between latency and synchronization - latency might be unavoidable but video sync should always be able to compensate - I got curious on how exactly that works, where in the app / SDK / OS pipeline does the a/v sync happen on a Mac?)
Thanks.. but that github program only lists the same info you get if you command-click on the BT icon in the menu bar. It basically only shows the device name.
I guess filtering the streaming log entries in the Console app gives some info.
It actually understands roman numerals, to a certain extent. E.g. `say LVIII` will say "58". However, `say MCMLXXIX` speaks some gibberish that ends in the word "six", for some reason.
It also knows how to say numbers up into the trillions but not more than that (although I feel like it used to).
Other cute `say` tricks: muck around with OSX Default Speech Voice (to a siri-ish voice) and you can invoke that from the CLI.
I hacked together a little script for demo recording like:
START_FROM="$1"
STARTED=0
function transcript() {
ID="$1"
TO_SAY="$2"
if [[ ...STARTED || START_FROM && ID... ]]; then
STARTED=1
say "$TO_SAY"
fi
}
transcript "STEP001" "This is a test"
transcript "STEP001b" "of the emergency broadcast system"
transcript "STEP002" "This is only a test, if this was ..."
transcript "STEP003" "...etc..."
...and then I have a hardcoded `--output` which will then change the invocation to `say -o "$ID.wav" "$TO_SAY"` and output audio files.
That way I can iterate on voiceover scripts, eg: `./demo-script "STEP002"` => `./demo-script --output`
It's really helpful for iterating on pronunciations, eg: `transcript "STEP005" "In case of Four Hundred and Four errors..."`, I can just "skip to" and iterate against that line (and subsequent ones), or "skip back" and hear it in more of a flowing context.
...even if I don't end up using the `say`-generated audio, having a transcript (and even pacing) that I can just read through with my own voice is super helpful.
I've found reliably "turning on" with pmset to be hit or miss. I can't remember the gotcha I ran into if it was that you had to have your laptop lid open or something else...
since I switch between linux and macos a lot I wrote a dotfile function called "clip" that will work the same on both. nice thing is it will automatically paste if nothing is piped to it to copy so there's no need to use separate commands... although I just realized it might be nice to have a "passthrough" mode that both copies and pastes if you add this to a pipeline in order to capture some intermediate part to the clipboard
if [[ "$(uname)" == "Darwin" ]]; then
clip() {
[ -t 0 ] && pbpaste || pbcopy
}
else # assume linux if not macos
clip() {
[ -t 0 ] && xclip -o -selection clipboard || xclip -selection clipboard
}
fi
That's handy, thanks! `osc copy` may also take args for files to copy to the clipboard, but in the absence of that and no data on stdin it maybe should switch to paste.
At my job I have to work with a lot of JSON that's usually minimized. This command has single-handedly saved my sanity:
$ pbpaste | jq | pbcopy
Then I can paste it into whatever text editor I want and it's all nice & pretty-printed for me.
Bonus is that I don't have to change the command at all, just copy the minimized JSON to the clipboard (say from DBeaver, for example), then hit the 'up' arrow and enter.
I have thousands of old photos that preview can open, but I can’t upload them into the photo.app because the file format is wrong. I’m going to try and use SIPS to convert them all into png first and then add to photo.app. Thanks for this pointer.
sips looks really cool, thanks for pointing this out.
Not gonna lie, I missed this because I thought it was related to macOS SIP, System Integrity Protection. Which is something I am deeply uninterested in.
There is also 'say' which is great if you need to step away from a long running command, in a similar fashion to ringing the terminal bell but with more context.
Yep, I do this in a tmux session. But sometimes I'm on a call and forget and the ROBOT VOICE says "DATABASE DUMP IS COMPLETE" and I jump out of my skin.
What I'm really missing still is a cli to iCloud stored passwords. AFAIK 'security' cli can't access the credentials stored in the cloud. This would be helpful to store secrets outside of git but would still allow scriptable access to them similarly as 1password cli 'op' has.
I'm fascinated by "sips" which has a full JavaScript interpreter built into it for rendering images using an entirely undocumented (as far as I can tell) Canvas-like API: https://til.simonwillison.net/macos/sips
Say you've got a directory that has scripts or data files related to some thing you do. For example I've got several scripts that I use when I scan books with my book scanner. I only need these when doing book scanning stuff so don't want to put them somewhere in $PATH. I want to be able to easily run them from scripts that aren't in that directory, but I don't want to hard code the path to that directory.
Solution: in the directory with the book scanning scripts I make a file named ID that contains a unique string. I currently use 16 byte random hex strings [1].
I have this script, named find-dir-by-ID, somewhere in $PATH:
#!/bin/zsh
ID=${1:?Must specific ID}
IDSHA=`echo $ID | shasum | cut -d ' ' -f 1`
mdfind $ID 2>/dev/null | grep /ID | while read F; do
FSHA=`shasum $F | cut -d ' ' -f 1`
if [ $IDSHA = $FSHA ]; then
dirname $F
exit 0
fi
done
exit 1
If some script wants to use scripts from my book scanning script directory, it can do this:
SCRIPT_DIR=`find-dir-by-ID 54f757919a5ede5961291bec27b15827`
if [ ! -d $SCRIPT_DIR ]; then
>&2 echo Cannot find book scanning scripts
exit 1
fi
and then SCRIPT_DIR has the full path to the scanning script directory.
The IDs do not have to be hex strings. If I'd thought about it more I probably would have made IDs look like this "book-scanning:54f757919a5ede59" or "arduino-tools:3b6b4f47bf803663".
[1] here's a script for that:
#!/bin/sh
N=${1:-8} # number of bytes
xxd -g $N -c $N -p -l $N < /dev/urandom
You mean something like having ~/well-known-stuff and under that having a 54f757919a5ede5961291bec27b15827 directory with the book scanning scripts and so on?
That could work fine, but generally the directories I've used this on are directories that I want to have somewhere else, and with a reasonable name. Usually the directories came first and various other things in fixed relative positions were using them, and then later I wanted to use them from elsewhere and added the ID.
I suppose ~/well-known/stuff/54f757919a5ede5961291bec27b15827 could by a symbolic link to the original.
The mdfind approach does have the advantage that if I reorganize things and move the directory it keeps working.
I set a shell alias so I can just do `airport -s`. I've no idea why this is hidden away inside some framework and not in a directory which is in the normal path, but there you go.
FWIW that appears to be soon deprecated according to MacOS 15.2:
WARNING: The airport command line tool is deprecated and will be removed in a future release.
For diagnosing Wi-Fi related issues, use the Wireless Diagnostics app or wdutil command line tool.
Oh, that's a pity. I'm pretty bad at keeping up to date on MacOS releases, but I should probably start figuring out `wdutil` so that my muscle memory is adapted before I've got no choice!
Except xdg mime types are easily heist-able by programs and there is no universal truth for it.
Install vscode on Linux and have fun with it hijacking opening directories. Which is easy enough to fix (with a bit of know how) or work around but annoying.
MacOS is far from perfect but open always doing what I expect is a good example of what Apple did well.
Does anyone remember the shortcut that brings up a list of currently available keyboard shortcuts for the current app? It may not be built-in, in which case it was a free utility.
plutil. Maybe not that useful to a lot of people but I have been going through and collecting bookmarks and Safari bookmarks are binary files. plutil is a means of converting the binary property file to a json or xml file.
Looks like a lot of these have linux equivalents that could be aliased. I wonder if anyone's made a set of those for regular macos users who occasionally use something else.
locate searches a database for all pathnames which match the specified pattern.
The database is recomputed periodically, (about once a week) and contains the path-names of all files which are publicly accessible.
That's interesting, I have never needed to do that. My Pixels have always just charged even if the lid is closed, on Intel and Apple Silicon machines. I like to travel light so I often use my laptop as a battery bank instead of carrying a seperate one.
Indeed, many applications I would expect to prevent sleeping (some audio playback ones, games, etc.) don't implement this. I assume it's a case of Apple's APIs changing over the years and not everyone catching up/caring. At one point I had downloaded Amphetamine[^1] but it is much nicer to just use the terminal here.
I was able to install a `caffeine` package with Apt on Linux. In that one the `caffeinate` command is supposed to be run with another command. While the `caffeine` command does what macOs `caffeinate` does.
While it may avoid sleep, it doesn’t prevent inactivity, in my experience. For instance, my chat app at work will still show me inactive while running caffeinate. I have to do non-interactive training semi-regularly and need to interact to keep from looking like I’m away from my desk.
Doesn’t work with Slack at least. I’ve had an iTerm window running `caffeinate -disu` for years. I think it used to work and stopped working in the last few months.
This can be done by passing a PID. I believe there are other options, as well. (Not at my computer to look it up right now.) I haven't used those features "manually", but I have in scripts that I expect to generate long-running processes.
> If you store your secrets in the Keychain (and you should!)
As part of the OS, Keychain suffers from the same sorts of sharp edges as using a built-in interpreter. An alternative is to use a password manager. Below is an example of the tools available in one.
Would you mind expanding on what these "sharp edges" are that you're warning about? I'm not really sure what you mean by this. Keychain has served me (and I imagine many others) really well for a while.