Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Open Source Fraunhofer AAC Encoder (fdk-aac) (Read 303116 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #25
I downloaded avconv and latest Winamp and encoded one song in VBR mode (quality = 1-6 for Winamp, 1-5 for avconv):
Winamp encoder: 37; 64; 103; 142; 215; 264 kbps
avconv encoder: (failed); 128; 141; 165; 258 kbps.

lowpass frequencies also differ significantly.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #26
I downloaded avconv and latest Winamp and encoded one song in VBR mode (quality = 1-6 for Winamp, 1-5 for avconv):
Winamp encoder: 37; 64; 103; 142; 215; 264 kbps
avconv encoder: (failed); 128; 141; 165; 258 kbps.

lowpass frequencies also differ significantly.


Mode 1 isn't valid for LC-AAC, afaik. I'll look into getting this documented.

It looks like low pass decisions are broken in CBR for bitrates >192kbps (2 channels/ 44100Hz).
It seems to never go above 17kHz even if the bitrate is set to 512kbps.


This is now settable in Libav.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #27
I'd settle for instructions on how to compile avconv (libav) with support for fdk-aac. Or would that be illegal too?


ffmpeg git compiles after applying a patch. Configure needs --enable-libfdk-aac.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #28
I downloaded avconv and latest Winamp and encoded one song in VBR mode (quality = 1-6 for Winamp, 1-5 for avconv):
Winamp encoder: 37; 64; 103; 142; 215; 264 kbps
avconv encoder: (failed); 128; 141; 165; 258 kbps.

lowpass frequencies also differ significantly.


To expand on what D404 said,  Profiles are not auto-selected.
So you need to pass `-profile aac_he` or `-profile aac_he_v2` manually.

IIRC, in Winamp:
q=2 --> aac_he
q=1 --> aac_he_v2


Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #30
Ok then.
Winamp encoder: 37; 64; 103; 142; 215; 264 kbps
avconv encoder: 37; 87; 141; 165; 258 kbps

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #31
lvqcl,

Can You post some frequency graphs of both encoders at similar bitrates or modes?

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #32
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 --

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #33
Spectrograms for VBR modes in avconv:

37 kbps, HE-AAC v2 --

87 kbps, HE-AAC --

141 kbps, LC --

165 kbps, LC --

258 kbps, LC --

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #34
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.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #35
VBR Mode
Code: [Select]
aconv -i <input> -c:a libfdk_aac -flags +qscale -global_quality [1-5] -afterburner 1 <output>

When using this command line:

It fails with a 96kHz source file:
Code: [Select]
Assertion failed!
File: ./libFDK/include/fixpoint_math.h, Line 459
Expression: (intValue > 0) && (intValue < 50)


It automatically downmix a 7.1 source file to 5.1.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #36
lvqcl

Thank You. So it's not extacly the same encoder as Winamp's one.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #37
Hello, do anyone knows where to get ffmpeg.exe x64 that has this fdk codec included or some automated compilation toolchain because i do not know anything about programming.

What is quality of this fdk codec anyway, this far i have used ffmpeg internal encoder but lot say this is bad quality(192kbs for me sounded fine), is this fdk better than any other open codec this far?

Death to patents....

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #38
playing around, testing with new ffmpeg (from git), only interested in vbr modes, this looks like it might work:

for lc:
Code: [Select]
ffmpeg -i in -c:a libfdk_aac -flags +qscale -global_quality 2 -afterburner 1 -vn out.m4a
(valid range for -global_quality seems to be >1 (1=error))

for he:
Code: [Select]
ffmpeg -i in -c:a libfdk_aac -profile:a aac_he -flags +qscale -global_quality 1 -afterburner 1 -vn out.m4a
(valid range for -global_quality seems to be 1-5)

for he_v2:
Code: [Select]
ffmpeg -i in -c:a libfdk_aac -profile:a aac_he_v2 -flags +qscale -global_quality 1 -afterburner 1 -vn out.m4a
(valid range for -global_quality seems to be 1-2)

-------------------

Real world speed test on entry level mac-pro (Lion), encoding one album from flac source:
case1: flac > fdk_aac (-flags +qscale -global_quality 2 -afterburner 1), time = 02:53 (slow), without afterburner = 02:52 (slow)
case2: flac > intermediate aif > apple aac (afconvert -v -f "m4af" -s 3), time = 01:10 (fast)
(note: this speed test is small and most likely irrelevant, could also be some mistake I did during compilation of ffmpeg with fdk)

-------------------
about ffmpeg used:
Code: [Select]
ffmpeg version N-43145-g32aeba1 Copyright © 2000-2012 the FFmpeg developers
  built on Aug  2 2012 19:14:22 with Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
  configuration: --prefix=/Volumes/tempdisk/sw --enable-gpl --enable-nonfree
  --enable-libx264 --enable-libfdk-aac --cc=clang --enable-runtime-cpudetect
  libavutil      51. 66.100 / 51. 66.100
  libavcodec    54. 47.100 / 54. 47.100
  libavformat    54. 22.100 / 54. 22.100
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter    3.  5.101 /  3.  5.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample  0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #39
It is also quite buggy: I found 4 different places where asserts are hit when encoding various files (3 of them are passing negative value to division and root square functions, one is too big value in inverse quantization). It probably "works" on Android, because asserts are enabled only for debug and for x86 builds. As smok3 noticed, it is also quite slow due to lack of any optimizations for x86 (there are asm functions for mips and arm). It has however one huge advantage: much better quality at low bitrates than faac and libaacplus.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #40
It is also quite buggy: I found 4 different places where asserts are hit when encoding various files (3 of them are passing negative value to division and root square functions, one is too big value in inverse quantization). It probably "works" on Android, because asserts are enabled only for debug and for x86 builds. As smok3 noticed, it is also quite slow due to lack of any optimizations for x86 (there are asm functions for mips and arm). It has however one huge advantage: much better quality at low bitrates than faac and libaacplus.


Could you shared samples and/or cmd lines that trigger these asserts?

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #41
It is also quite buggy: I found 4 different places where asserts are hit when encoding various files (3 of them are passing negative value to division and root square functions, one is too big value in inverse quantization). It probably "works" on Android, because asserts are enabled only for debug and for x86 builds. As smok3 noticed, it is also quite slow due to lack of any optimizations for x86 (there are asm functions for mips and arm). It has however one huge advantage: much better quality at low bitrates than faac and libaacplus.


Could you shared samples and/or cmd lines that trigger these asserts?


I uploaded 3 short samples here . I can't find 4th one unfortunately (the one that triggers assert on sbr envelope calculation).
Tested using newest fdk-aac and ffmpeg.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #42
I uploaded 3 short samples here . I can't find 4th one unfortunately (the one that triggers assert on sbr envelope calculation).
Tested using newest fdk-aac and ffmpeg.


They should be fixed now in the git version of fdk-aac.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #43
is there a "compile this git for dummies" txt somewhere?


Code: [Select]
ticho@ticho:~/ffmpeg/fdk-aac$ autoconf
ticho@ticho:~/ffmpeg/fdk-aac$ ./configure
configure: error: cannot find install-sh, install.sh, or shtool in . "."/.
ticho@ticho:~/ffmpeg/fdk-aac$ autoreconf
aclocal: couldn't open directory 'm4': No such file or directory
autoreconf: aclocal failed with exit status: 1

nevermind, this did the trick:
Code: [Select]
$ libtoolize --force
$ aclocal
$ autoheader
$ automake --force-missing --add-missing
$ autoconf
$ ./configure
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

 

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #45
I uploaded 3 short samples here . I can't find 4th one unfortunately (the one that triggers assert on sbr envelope calculation).
Tested using newest fdk-aac and ffmpeg.


They should be fixed now in the git version of fdk-aac.


That's great. I also forked it on GitHub and started working on x86 optimizations. Hopefully enough people will get interested to make it a good encoder.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #46
Hello HA,

I'm a pro developer and I've worked on some audio related projects as well (using ffmpeg and aac libs). I didn't use fdk yet, but I used the one from vo. I short, the one from vo looks like a joke. They basically took the 3gpp source and dropped the sbr part. I guess the logic was to drop HE part from AAC-HE to get AAC encoder  The funny thing is that the AAC part runs before sbr and the AAC part allocates buffer for the bitstream. It writes aac part in the buffer and then sbr part appends into that same buffer. They dropped the sbr part and as a result the voaac generates bitstream full of zeros. You can easily see that it's full of nullshit in a hex editor. Otherwise, it's similar to libaacplus I guess, but it has some minor cpu optimizations (pretty badly done as well). Google could have hired a good dev and that voaac could have been fixed in a couple of months (some bestest dudes from ffmpeg could have done that in a couple of weeks I guess). Overall, all pv or vo codecs that google bought from packetvideo or visual on are clear ripoffs from 3gpp code and they aren't even well done. Looks like some graduates from china worked on the 3gpp code.

About patents. Some view source code as explanation of the patent itself, that is, source code that implements patented technology infringes on it as much as the patent description. Source code might be converted to a tool that uses patented technology using a compiler. Patent description might be converted just the same way to a tool that uses patented technology using a developer with a compiler. But source code does not use patented technology. I think there were cases of successful defense that source code implementation cannot be blocked on grounds of free speech, something like: you can't prevent me to express this technology using some computer language. There is one guy who went to us court against the US and he was pretty successful representing himself without having any background in law training. I've stumbled upon this dude by reading his one of the fastest fft algorithms. I think he is also the person who wrote qmail. I don't know why I wrote the paragraph  I just realized that binaries were blocked from HA, not the source code...

I'm no sound expert, but why don't you guys start pushing OPUS all over the place? Personally, from my code review and study of the codec it's not worse that AAC. It's just insane how it's impossible to get any license to all that AAC bs, plus the price is ridiculous. My personal opinion is that they invent new crap not because there is a need, but because they want to prevent from new players coming into the big game. If you look at HEVC git history: all of the commits by employees from all these well known companies (rim, qualcomm, sony etc etc). They simply put a few developers full time on codec development project and a legal team that checks daily on progress and patents every incarnation of the bubble sort with the only intention to increase number of the patents related to the "new" technology so that it would practically be impossible to prove anything before all these patents actually expire. Just the idea that all these companies suddenly collaborate on a publicly available BSD licensed library is really fishy. To me it's clear what their intentions are. It's not only my guesses, I kind of worked on similar project by similar company and biggest expense was not the developers but the legal team that was working with us along the way. Their job was to check with us if there is something new was created and explore all angles from where they could patent it as an "invention". It all looked like dirty scam from inside, and from outside it's presented as research with all bells and marketing whistles.

(usual mambo-jumbo that i'm no legal expert is omitted).

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #47
Overall, all pv or vo codecs that google bought from packetvideo or visual on are clear ripoffs from 3gpp code and they aren't even well done. Looks like some graduates from china worked on the 3gpp code.
Quote
from china
Does this actually have any relevance, or is it just a daft stereotype with potential to be very offensive?

Quote
I'm no sound expert, but why don't you guys start pushing OPUS all over the place?
I’m sure that plenty of people are and that even more people will be once it’s seen a stable release. You should realise, though, that AAC’s popularity is due in no small part to its adoption and consequent aggressive promotion by Apple, Nero, et al.. You’ll excuse me if I’m pessimistic and suspect that all the open initiatives in the world and all of their enthusiastic supporters at the grassroots can’t eclipse corporate power. Vorbis is an illustrative example of this for numerous reasons.

I guess that ties into your fourth paragraph, at least as far as I’m capable of decoding it.

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #48
Overall, all pv or vo codecs that google bought from packetvideo or visual on are clear ripoffs from 3gpp code and they aren't even well done. Looks like some graduates from china worked on the 3gpp code.
Quote
from china
Does this actually have any relevance, or is it just a daft stereotype with potential to be very offensive?

Quote
I'm no sound expert, but why don't you guys start pushing OPUS all over the place?
I’m sure that plenty of people are and that even more people will be once it’s seen a stable release. You should realise, though, that AAC’s popularity is due in no small part to its adoption and consequent aggressive promotion by Apple, Nero, et al.. You’ll excuse me if I’m pessimistic and suspect that all the open initiatives in the world and all of their enthusiastic supporters at the grassroots can’t eclipse corporate power. Vorbis is an illustrative example of this for numerous reasons.

I guess that ties into your fourth paragraph, at least as far as I’m capable of decoding it.

Well, Opus do have some big corporations behind it (Broadcom, Skype a.k.a. Microsoft, Google...). Vorbis didn't have this momentum on release (it did have some support of Google after WebM but it only appeared on 2010 and Vorbis already was a old codec by this time), so maybe Opus will have a better chance to succeed. Anyway, even if Opus didn't succeed on general music applications it will probably survive on it's niche (it's way better than any other low-delay codec for Super-Wideband and Fullband applications, and it's very competitive on Wideband and Narrowband). Remembering that Opus is a MTI (mandatory-to-implement) codec on WebRTC, so it already have some uses.

This is really off-topic, but I don't think AAC is very succeful too. It have too many different profiles, many of them just eclipse one or another (just see this page here, that describes the entire MPEG-4 Audio; you have two codec for speech, three for general audio and three codecs for lossless). The majority of devices only supports the AAC-LC, many of them didn't support even the AAC Main Profile. The standard is so complex that some codecs never seem a working implementation (like ALS)-

AAC have it's niche too, but it didn't really eclipsed MP3 as the new standard for general music files, and I think no other lossy codec will ever have this achievement. Vorbis is very succesful on its own niche too (just look how many games use Vorbis as the codec to store music files).

Open Source Fraunhofer AAC Encoder (fdk-aac)

Reply #49
Quote
from china
Does this actually have any relevance, or is it just a daft stereotype with potential to be very offensive?


Nothing against china. Not sure why I have that in mind, probably because in comments (of the code) or somewhere I saw chinese names and decided that some part of that work was done in china where it's ok to take 3gpp code and then sell the code after making some minor changes and adding different interface.

Quote
I’m sure that plenty of people are and that even more people will be once it’s seen a stable release. You should realize, though, that AAC’s popularity is due in no small part to its adoption and consequent aggressive promotion by Apple, Nero, et al.. You’ll excuse me if I’m pessimistic and suspect that all the open initiatives in the world and all of their enthusiastic supporters at the grassroots can’t eclipse corporate power. Vorbis is an illustrative example of this for numerous reasons.

I guess that ties into your fourth paragraph, at least as far as I’m capable of decoding it.


The thing with apple is pretty clear I guess: they are one of the major patent holders for aac probably (am I right?); they are major patent holder in h264 video at least. They can easily release facetime client that uses h264 video and others might be in gray zone if they try to compete with them because for this type of app entry fee for the players is ridiculous: you might be charged a dollar per download by mpeg-la or you need to cover yourself with buyout license (which is millions of dolaz). So, they are pushing it.

About opus. It's already finished bistream format. It's now standard as it has been approved by IETF on July 2, 2012. Even a year ago tests by nokia confirmed that it was one of the best codecs for real time voice when compared to some state of the art codecs like amr-wb etc. There are also other tests that compare OPUS to codecs for general music. All that info on opus-codec.org.

Honestly, ppl get harassed for posting something that is considered to be illegal by HA. Instead, I think AAC should be considered illegal here instead
When working for some big guys' projects, I learned that they wanted to squeeze every drop possible for quality and performance. But they absolutely under no circumstances could even accept possibility that a non patent-incumbered codec could be used. So, I guess it's some kind of scam going on behind the scenes.