Handbrake without FDK-AAC, new FFMPEG AAC encoder viable alternative?

[jaggy]

Is the FFmpeg AAC encoder a viable alternative to Fraunhofer's FDK-AAC encoder which is no longer included with Handbrake? The main benefit of installing the new Handbrake release is in updated x265 encoder (1.9). I don't see that they changed the x264 encoder.

Handbrake announcement

HandBrake 0.10.5 Released

Thursday, Feb 11, 2016

Unfortunately due to circumstances beyond our control we can no longer include binary distributions of HandBrake which include the FDK-AAC encoder.
Please also be aware that if you are distributing any previous 0.10.x you must cease doing so now due to licensing issues.

According to Handbrake see HandBrake - AAC Encode Change the quality of the LibAV AAC encoder is lacking in comparison to FDK but is passable for most."We are looking into upgrading LibAV to get further improvements in their AAC encoder. Hopefully it will eventually become on-par with FDK.

I don't quite understand the FFmpeg/LibAV situation'. Is the below FFmpeg announcement applicable to Handbrake?

"December 5th, 2015, The native FFmpeg AAC encoder is now stable!

After seven years the native FFmpeg AAC encoder has had its experimental flag removed and declared as ready for general use. The encoder is transparent at 128kbps for most samples tested with artifacts only appearing in extreme cases. Subjective quality tests put the encoder to be of equal or greater quality than most of the other encoders available to the public."

Hydrogenaudio

Listening Test

[LigH.de]

As you can see in the comparison results on hydrogenaud.io, the average of all participants reported ffmpeg's AAC encoder not to preserve as much quality as Fraunhofer's AAC encoder, which you may use if you build your own binary from sources, but you may not distribute the compiled binary (that's their license).

Fortunately, it is rather easy to have a binary compiled on Windows, using the fdkaac_autobuild suite you can download from the qaac download area. Unzip to a separate directory and execute the included batch file; a MinGW compiler environment will be downloaded, together with the encoder sources, and run the compilation automatically. Then you can add it to your Handbrake installation.

If this appears too much trouble to you, then use ffmpeg's AAC encoder which is certainly not bad (better than most MP3 encoders for sure) and may improve in the future; but for now, you may have to get used to slightly increase the target bitrate over your previous threshold of acceptable quality.

[jaggy]

Thank you. So the LibAV AAC encoder included in Handbrake is the same as the ffmpeg's AAC encoder?

Based on the post-release HandBrake 0.10.5 Discussion Thread it does not appear I can simply add the binary to the existing Handbrake installation.

[LigH.de]

ffmpeg is a command line interface for the libavformats (de)multiplexers and libavcodec (de/en)coders. Handbrake is a graphical user interface built around the same libraries. Same engine, different casing.

The author of Handbrake will previously have built fdkaac as a library into Handbrake, instead of calling it as a separate encoder; so you won't be able to exchange it easily.

Other converters using separate encoders are more flexible. But they may have to be handled in a different way... Therefore, if you insist in using Handbrake, you will have to restrict yourself to the libav AAC encoder. Or you may prepare the AAC audio with an additional converter and just multiplex the prepared AAC audio into your movie later, and keep using Handbrake at least for the video conversion and multiplexing.

[jaggy]

Thank you, that was helpful. I was aware of Handbrake being a GUI. I was not quite sure if its LibAV libraries were the same as those referred to in the FFMPEG announcement. I also don't know if Handbrake's LibAV libraries are the most current.

Other converters have other issues, like the overall stability, not being able to support several audio tracks, requiring too many external components that don't always play well together etc. If you have a suggestion, I'd love to hear it. I would only multiplex external audio in special projects. There's a point where one needs to draw a line. Handbrake is/was a great self-contained, simple tool. Bringing in additional tools would negate this very quality (and the need for Handbrake).

With regards to your suggestion to slightly increase the target bitrate over the previous threshold, i.e. 192 kbps being the next logical step going from 160 kbps, I am not aware of any players (except some versions of Apple products) having any issue with higher bitrates.

If someone disagrees with anything please do leave a comment.

[pandy]

It should be possible to call fdkaac lib frome ffmpeg (or perhaps better - compile ffmpeg with fdkaac ) .

[AntW93]

Remember, you can compile HandBrake from source and enable the FDK-AAC encoder, see my guide on how this can be done for the Windows version: https://forum.videohelp.com/threads/383208-How-to-get-HandBrake-with-FDK-AAC-for-Windows

However, this is not an easy process (although I have tried to simplify it as much as I can in this guide!) and would only recommend this to advanced users, any further comments and suggestions about this guide would be appreciated!

I still hope that a new and better quality AAC encoder will added to the Windows and Linux versions of HandBrake in the future, or the LibAV AAC encoder recieves at least some improvement, at the moment the default AAC encoder in HandBrake is letting down an otherwise great piece of software!

[Zero-11]

who gives a rats ass about AAC? just use opus

[Marsia Mariner]

who gives a rats ass about AAC? just use opus

Opus may be great, but there are only 3 containers that support it:
Matroska, transport stream, and the useless Ogg.

[hello_hello]

who gives a rats ass about AAC? just use opus

Is opus widely supported yet? None of the video playing devices in our house (TVs with built in media players, bluray players etc) support opus but they all support aac.

[AntW93]

Opus may be great, but there are only 3 containers that support it:
Matroska, transport stream, and the useless Ogg.

Exactly, I (and I'm sure many others!) need .mp4 or .m4v files with an AAC audio track so they can be played on iPads or other similar devices, its as simple as that!

[Zero-11]

who gives a rats ass about AAC? just use opus

Opus may be great, but there are only 3 containers that support it:
Matroska, transport stream, and the useless Ogg.

Your Android Smartphone supports everything so just use Miracast.

[hello_hello]

I don't know about anyone else, but I won't be using an Android Smartphone as my primary media player any time soon, or possibly ever.
My TV doesn't support Miracast anyway, so I think I'd have to ether buy an adaptor or I'd have no video to go with the unsupported audio. And if I bought an adaptor, doesn't the video get re-encoded and DRM'd as part of the process? All my attention to video quality when re-encoding down the pooper? Sounds much easier to plug a drive with video files containing AAC audio into the TV's USB input.

Nothing against Opus. If it was as well supported as AAC I'd have no issue using it, but if Miracast is the only way.....

[Marsia Mariner]

Opus was invented (OR has been promoted, at least) by Xiph, therefore it had to be designed to suck.
I am not talking about the quality of the compression, I am talking about the usability of the format.
The Ogg container sucks, the channel layout is not defined in the elementary-stream itself, and Xiph didn't define a TwoCC either
(so that a strict-CBR stream could be wrapped in a .WAV or .AVI file).
Unless Xiph decides to fix these deficiencies
(assuming that they can be fixed),
I will keep saying NO to Opus.

[LigH.de]

Could a moderator please crop the Opus bashing? This thread is focused on Handbrake, ffmpeg, and AAC encoders.

[hello_hello]

Maybe a moderator will realise the Handbrake, ffmpeg conversation finished over a year ago and the discussion has evolved.

Opus was invented (OR has been promoted, at least) by Xiph, therefore it had to be designed to suck.
I am not talking about the quality of the compression, I am talking about the usability of the format.

I (yetanotherid) was involved in a discussion a while back regarding the re-invention of ReplayGain for Opus.
https://hydrogenaud.io/index.php/topic,112452.msg926739.html#msg926739
Nothing against the quality of the encoder, but even the fact that the ReplayGain tags are no longer ReplayGain tags (Opus specific R128 tags instead, when they were eventually allowed) and not being in an easily human readable format seems a big step backwards to me (the original ReplayGain could take a bit of time to get your head around as it was), and contrary to the EBU R128 standard, apparently storing peak values is prohibited for Opus. I'm still not sure if I'm crazy about that one, because it means if you want an idea of the peak value you must either somehow save it contrary to the Opus spec, or re-scan the file to find out what it is.

That discussion was a while ago so I'd have to research it all again to refresh my memory, but I'm not sure the Opus ReplayGain changes were all necessarily for the better. I think the world should move to using R128-speak rather than the original ReplayGain way of specifying volume (R128s -18LUFS rather than ReplayGain's 0dB relative to an 89dB target volume) but however it's done everyone should be doing it the same way. Opus doing it differently just potentially adds to the confusion.

I'd still like to know if there's a phenomenally good reason for it not being totally retarded that I need a calculator for this.

-1137 / 2^8 = -4.44140625 + 5 (difference between R128 and ReplayGain target volumes) = +0.56 dB (rounded)