Open Source Fraunhofer AAC Encoder (fdk-aac) Options

[D404]

Android 4.1 has included an AAC encoding library by Fraunhofer, and Libav/FFmpeg support for this library is in the works (that is, in a day or two, it will be official.)

From the release announcement:

As part of the Android Jelly Bean source code released recently, a new AAC
library was released as well, developed by Fraunhofer:
https://android.googlesource.com/platform/external/aac

To ease using this library on platforms other than Android, I have added
an autotools based build system and done a minor portability fix, and
released this code as fdk-aac 0.1.0 today.

This project is hosted at sourceforge, under the opencore-amr project,
acting as an umbrella project for these codecs that are repackaged from
Android as standalone libraries, just as opencore-amr, vo-amrwbenc and
vo-aacenc before this one.

The release file is available at
http://sourceforge.net/projects/opencore-amr/files/fdk-aac/
and the code is available in git at
git://opencore-amr.git.sourceforge.net/gitroot/opencore-amr/fdk-aac.

This library is licensed under a custom copyleft style license:
http://opencore-amr.git.sourceforge.net/gi...a=blob;f=NOTICE

I in general intend to limit this project to minor tweaks and portability
fixes - for anything larger than that, I'd prefer if it first is
contributed upstream, to keep the difference between the upstream code and
this library as small as possible.

Edit: Obvious patent violation removed.

It can be used as such:

Bitrate Mode

CODE

avconv -i <input> -c:a libfdk_aac -b:a <bitrate> -afterburner 1 <output>

VBR Mode

CODE

aconv -i <input> -c:a libfdk_aac -flags +qscale -global_quality [1-5] -afterburner 1 <output>

VBR modes 1-5 correspond to roughly:

1. about 32 kbps/channel
2. about 40 kbps/channel
3. about 48-56 kbps/channel
4. about 64 kbps/channel
5. about 80-96 kbps/channel

-afterburner 1 enabkes "improved quality" mode.

Cheers.

Edit: This should be moved to the Tech forum.

This post has been edited by Garf: Jul 11 2012, 19:30

[lvqcl]

It turns that avconv adds 2048 null samples to the beginning of encoded files in LC-AAC mode (even more in HE-AAC).

Spectrograms for VBR modes in Winamp:

37 kbps, HE-AAC v2 --

64 kbps, HE-AAC --

103 kbps, LC --

142 kbps, LC --

215 kbps, LC --

264 kbps, LC --

[kode54]

It turns that avconv adds 2048 null samples to the beginning of encoded files in LC-AAC mode (even more in HE-AAC).

I'm seeing this, too. It would be extremely nice for gaplessness if these null samples would be reported as extra encoder latency in the Apple and Nero chapters, which are used for the track trimming.

Actually, it should not be using null samples, but rather, employ a linear predictive coder function to reverse fill from the initial samples of the input data. libvorbis and postfish include one if you don't already have one, or at least demonstrate how to use one for this purpose. I just lifted the one from libvorbis for opusenc in the opus-tools package for track end padding, when the last block of samples is not enough to complete an entire Opus packet. Look at me, I almost sound like I know what I'm doing. Actually, someone in #opus had to tell me that LPC would be better than last-sample-hold padding, and I had to research it a bit.