Useful built-in macOS command-line utilities

A couple more:

    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

Examples:

    afconvert in.wav -o out.m4a -q 127 -s 2 -b 160000 -f m4af -d 'aac '

    mb=300; diskutil eraseVolume APFS myramdisk `hdiutil attach -nomount ram://$((mb*2048))`

> afconvert

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

How does that compare with ffmpeg? The arguments seem about the same.

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.

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.

"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.

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.

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/

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.)

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.

Love those type of OG Mac indie software.

There's no reason to use AAC when we have both OPUS and FLAC.

Today OPUS is on par of AAC if not better. We aren't at the MP3/OGG times.

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.

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.

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.

Opus is better at same bitrate - not by much, but all the same it has the upper hand.

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.

I think those are the commenter's descriptions, not Apple's man page synopses. My system has

     afconvert -- Audio File Convert
     diskutil -- Modify, verify and repair local disks.

Correct. Though AAC (when produced with a proper encoder) surpasses all other lossy formats with the exception of Opus.

>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.

It does. -c:a aac_at uses Core Audio (_at means AudioToolbox).

That makes sense.

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.

I'll read more on the specs.

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 Macs 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.