AAC encoders comparison

Vouk , you know it is rather surprising that on my listening tests, I find NeroAACEnc marginally better than both Apple's CoreAudio aka QAAC and FDK on low bitrates such as HE-AACv2 with PS at 32kb, though the internet is full with QAAC better than FDK better than Nero reports.

Although my listening tests are done on a reference AKG-K702, but I easily hear that annoying 'warbling' effect in QAAC where as Nero just drops the sonics a little in favour of overall sound stability, in my ears opinion of course.

What are your thoughts and experiences on this?

Tried MagicYUV for a while, then went over to that japenese utvideo codec and then went back to Cineform, and now kind of settle on JPG2000, though current Adobe Premiere release has a bug in the output where a blinking line appears at the top left edge of the video in anything below 12bit, so currently playing with Prores 4444. Now all these codecs are all well and good if we keep away with FFMPEG, it's the moment we throw FFMPEG into the workflow where outputs are reused in the workflow that we start hitting all kinds of issues like missing first frame or a few milliseconds of audio at the end etc. As an output for consumption tool, FFMPEG is great, just when we start to rely on it as an intermediate generator brings headaches.

FLAC is something I definitely want to use in my workflow, already have the FLAC importer plugin for Premiere, but the problem is that we can't open a video file with a FLAC stream back inside Premiere, if we could then that is exactly what I would be using for my masters/bridges, currently settled with raw PCM at 24 bit.

The AAC I tend to use for long-term archives and previews to ship out to clients, which are often either internal intranet distributed or for public facing websites, whence why best quality at lowest bitrates for online consumption is always on the priority list, indeed I'm often having to do multiple encodes where some clients are fussy about wanting to support WebM as well as H264, it gets pretty tedious.

In as far as discernible audio quality is concerned, mobile devices is where poor audio encodings tend to reveal their flaws moreso than desktop bass thumping speakers, and of course reference studio monitors/headphones really show the ugly side of nasty encoder artifacts.

I just would love to know which AAC encoder is the champ in each range, ie. low bitrate HEAACv2, LC and HE-AAC... but based on my own listening tests I find it very difficult to trust the online 'listener tests', whence why I was wondering if you had any exposure to this multi-coder abyss.

To be fair, it really is all dependant on the source type, ie dance vs classical vs singing right down to db levels, so many variables it's an absolute nightmare. Lossless and low-bitrate, now that would be magic, but of course beyond the realm of current technology.

That goes without saying, but lossless compressed bridging codecs don't really have any impact on speed if negligible at worst in the workflow, such as prores/cineform/mxf etc, pretty much why they're used extensively in the industry. Well when you compare a few terrabytes of raw uncompressed YUV 4:4:4 footage to a few hundred gig, a no brainer really.

But, consumer exports and selecting the right AAC encoder for the audio is the nightmare, I can never just put my finger on it and say 'thats' the codec" for every source.

Just did an export a few minutes ago, HE-AAC 64kb, QAAC output was terrible, Nero was perfect, but NeroAACend has not had any further development for quite a few years. Maybe an earlier version of CoreAudio dll's performed better than current for QAAC.

Anyhow, not a concern for Voukoder, as long as the options to select the AAC codec are there then it really is down to us to decide which we need to suit whatever perceptive inclination we may hold.

I recall a recent scientific study claiming not all ears hear the same sounds... I guess it really is as simple as that, maybe I just have far too sensitive ear-drums.

Exactly! And this is where it gets annoying, because unless you have a bit-perfect lossless source such as SACD etc, compressed versions sound abysmal on high-end gear. My monitors barely get much use outside of source engineering, indeed they were a worthy investment for master tuning, but playing back anything compressed bar very extreme bitrates really shows how terrible lossy audio codecs still are, it is as they say 'perceptive' and this would be down to accommodating typical consumer grade hardware, for example I'm often having to put on a pair of consumer grade sony headphones to 'hear' what the average person will.

Unlike the big players, I don't have a team of listeners/viewers to get feedback on edits etc... but I still like to make sure I'm doing all I can to perfect my final outputs even if they may be for a very small closed-door userbase.

I'm looking forward to FDK Voukoder integration, I can see countless nights of testing coming up

poo schrieb:

Best AAC encoder probably is one that YouTube uses. Too bad it's not for public usage.

Can't seem to find any info on their encoder, I wonder what it's based on if not totally inhouse developed.

I did some tests, uploaded a vid, grabbed it using a youtube downloader, demuxed it, ran it through spectral layers pro, I can see what they're doing to achieve a better sound, they're actually tweaking the harmonics for the encode, need to do a few more tests to be conclusive. Now this kind of processing will achieve perceptual similarity with very little to no artifacts on any hardware, be it consumer or high-end, but... if you had the original source to listen to, then you do notice the difference.

For streaming online they've definitely hit the nail on its head... that's the kind of effort all the generic encoders are missing though most do the typical 'cut high frequencies' etc... but still a far-cry from what youtube appear to be doing.

Now if we had a batch script that we could run on our raw 24 bit uncompressed audio to prepare it for a quality encoder before encoding... then we could in theory emulate their process...

the above is all guesswork based on the spectral analysis, for all I know it could be their encoder itself that does the wizardy on the fly...

either way... yup, you said it, too bad it's not for public usage.

When we get piping support, I'll definitely be including nero as an option in my planned workflow gui, still use neroaacenc quite heavily in my scripts even after all these years.