Useful built-in macOS command-line utilities

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/

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

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.

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