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?

    If quality is important i would rather go with uncompressed audio (i.e. FLAC, ALAC or even PCM). For my (non-pro) needs the FFMpeg internal AAC encoder is good enough.


    Just like i preferred recording with MagicYUV (uncompressed) rather than with MP4.

    Help to improve this plugin and support me on patreon or paypal. Thank you.

    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.

    I have seperated this to the non-voukoder related forum.


    In the editing workflow i would only use uncompressed (or at least uncompressed). It is even faster to edit and you don't loose any quality at this point. I would only compress / encode it on the final export.

    Help to improve this plugin and support me on patreon or paypal. Thank you.

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

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

    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.

    Reviving this very old thread as it's still relevant, I would enjoy a way to be able to use alternative encoders using Vouk as a wrapper, e.g. like how I can use alternative AAC encoders in foobar2000.


    Is there any possibility to include options to hook into Nero, Apple, FDK/FHG or QAAC DLLs for more advanced audio encoding, or is support limited to what's in FFmpeg core?

    hello world!

    Quote from manowar_gub

    Agreed, best AAC encoder is Nero 1.0.0.2, released on may 2006

    Yes! But why? Apple AAC has been updated over and over since then, with every version they get better transparency, so why couldn't they ever catch up with Nero?


    I have a theory about it, and it's related to the reason I chose M4A as my definitive storing format.


    Back when my computer was still full of all these lossless audio files I had to decide what lossy format I'd ultimately end up using, so I made my research and then downloaded ABX software and started listening...


    2-Pass WMA reached transparency at 160kbps, so I could just use that and be done with it, but people were recommending AAC so I ripped Nero tracks at 160kbps to compare and started the ABX listening...


    I was blown away! According to it, Nero AAC had fooled me 9 out of 10 times! That was all I needed to know to stick with it, though I still went with VBR .54 Quality files because their sizes were reasonable.


    It hasn't been until recent times that I came up with this theory: the Internet is full of websites clamoring that Apple AAC is the best, showing charts that go from "Imperceptible" to "Perceptible" but not annoying" to "Slightly annoying", and so on. Apple outranks Nero every time.


    What they had missing was "Perceptible but pleasing"!


    In the ABX I could tell apart Nero from Lossless 90% of the time, it wasn't fooling me at all. But I was picking the one I thought sounded the best on those times!


    I think what Nero does is adding noise to add detail to the songs, I was picking up these details, so I thought I was picking the lossless version. This is similar to analog emulator DSPs that add distortion to music to make it "warm."


    It reminds me of the waifu2x AI powered image magnifier, in where the user submits an image and it produces an outstanding one with double the resolution, a process that "invents" 3 new pixels for each existing one, and it's so good that you can get better results if before importing the image you shrink it to about 2/3 its size (losing even more pixels)!


    Can Nero really sound better than lossless? I think most developers of encoders have focused on this "as perceptibly close to lossless as possible" goal, instead of an "as pleasing to the ear as possible with the available bits" one.


    If this is the case (it's just a theory!) maybe Nero has already perfected the art of pleasing encoding (at least at +160kbps) regardless of its difference with lossless (which can be a good thing!)


    That's why they hadn't need to update it in 15 years, at the "not quite the same, but better" point we can consider lossy encoding solved, and move on.