IPB

Welcome Guest ( Log In | Register )

6 Pages V  < 1 2 3 4 > »   
Reply to this topicStart new topic
Open Source Fraunhofer AAC Encoder (fdk-aac)
lvqcl
post Jul 13 2012, 20:38
Post #26





Group: Developer
Posts: 3208
Joined: 2-December 07
Member No.: 49183



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.
Go to the top of the page
+Quote Post
D404
post Jul 13 2012, 21:27
Post #27





Group: Members
Posts: 7
Joined: 30-July 08
Member No.: 56482



QUOTE (lvqcl @ Jul 13 2012, 15:38) *
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.

QUOTE (2012 @ Jul 12 2012, 12:45) *
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. smile.gif
Go to the top of the page
+Quote Post
skamp
post Jul 13 2012, 21:33
Post #28





Group: Developer
Posts: 1343
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (skamp @ Jul 13 2012, 20:55) *
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.


--------------------
caudec.net
Go to the top of the page
+Quote Post
2012
post Jul 13 2012, 21:46
Post #29





Group: Members
Posts: 63
Joined: 7-February 12
Member No.: 96993



QUOTE (lvqcl @ Jul 13 2012, 21:38) *
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
Go to the top of the page
+Quote Post
2012
post Jul 13 2012, 21:50
Post #30





Group: Members
Posts: 63
Joined: 7-February 12
Member No.: 96993



QUOTE (skamp @ Jul 13 2012, 22:33) *
QUOTE (skamp @ Jul 13 2012, 20:55) *
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.


libav (the real active upstream) does not need any patches.
Go to the top of the page
+Quote Post
lvqcl
post Jul 13 2012, 21:59
Post #31





Group: Developer
Posts: 3208
Joined: 2-December 07
Member No.: 49183



Ok then.
Winamp encoder: 37; 64; 103; 142; 215; 264 kbps
avconv encoder: 37; 87; 141; 165; 258 kbps
Go to the top of the page
+Quote Post
IgorC
post Jul 13 2012, 22:09
Post #32





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



lvqcl,

Can You post some frequency graphs of both encoders at similar bitrates or modes?
Go to the top of the page
+Quote Post
lvqcl
post Jul 13 2012, 22:47
Post #33





Group: Developer
Posts: 3208
Joined: 2-December 07
Member No.: 49183



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 --
Go to the top of the page
+Quote Post
lvqcl
post Jul 13 2012, 22:48
Post #34





Group: Developer
Posts: 3208
Joined: 2-December 07
Member No.: 49183



Spectrograms for VBR modes in avconv:

37 kbps, HE-AAC v2 --

87 kbps, HE-AAC --

141 kbps, LC --

165 kbps, LC --

258 kbps, LC --
Go to the top of the page
+Quote Post
kode54
post Jul 14 2012, 01:58
Post #35





Group: Admin
Posts: 4498
Joined: 15-December 02
Member No.: 4082



QUOTE (lvqcl @ Jul 13 2012, 14:47) *
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.
Go to the top of the page
+Quote Post
Brazil2
post Jul 14 2012, 10:29
Post #36





Group: Members
Posts: 119
Joined: 9-May 10
Member No.: 80499



QUOTE (D404 @ Jul 11 2012, 18:02) *
VBR Mode
CODE
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
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.
Go to the top of the page
+Quote Post
IgorC
post Jul 15 2012, 17:39
Post #37





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



lvqcl

Thank You. So it's not extacly the same encoder as Winamp's one.
Go to the top of the page
+Quote Post
jossilint
post Aug 2 2012, 12:26
Post #38





Group: Members
Posts: 5
Joined: 2-August 12
Member No.: 101956



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....
Go to the top of the page
+Quote Post
smok3
post Aug 7 2012, 00:32
Post #39


A/V Moderator


Group: Moderator
Posts: 1709
Joined: 30-April 02
From: Slovenia
Member No.: 1922



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

for lc:
CODE
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
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
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
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


This post has been edited by smok3: Aug 7 2012, 01:51


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post
qbast
post Aug 8 2012, 13:52
Post #40





Group: Members
Posts: 5
Joined: 8-August 12
Member No.: 102112



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.
Go to the top of the page
+Quote Post
D404
post Aug 8 2012, 16:56
Post #41





Group: Members
Posts: 7
Joined: 30-July 08
Member No.: 56482



QUOTE (qbast @ Aug 8 2012, 08:52) *
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?
Go to the top of the page
+Quote Post
qbast
post Aug 9 2012, 17:01
Post #42





Group: Members
Posts: 5
Joined: 8-August 12
Member No.: 102112



QUOTE (D404 @ Aug 8 2012, 17:56) *
QUOTE (qbast @ Aug 8 2012, 08:52) *
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.
Go to the top of the page
+Quote Post
D404
post Aug 10 2012, 21:09
Post #43





Group: Members
Posts: 7
Joined: 30-July 08
Member No.: 56482



QUOTE (qbast @ Aug 9 2012, 12:01) *
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.
Go to the top of the page
+Quote Post
smok3
post Aug 13 2012, 11:21
Post #44


A/V Moderator


Group: Moderator
Posts: 1709
Joined: 30-April 02
From: Slovenia
Member No.: 1922



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


CODE
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
$ libtoolize --force
$ aclocal
$ autoheader
$ automake --force-missing --add-missing
$ autoconf
$ ./configure


This post has been edited by smok3: Aug 13 2012, 11:25


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post
2012
post Aug 13 2012, 13:31
Post #45





Group: Members
Posts: 63
Joined: 7-February 12
Member No.: 96993



QUOTE (smok3 @ Aug 13 2012, 11:21) *
nevermind, this did the trick:
CODE
$ libtoolize --force
$ aclocal
$ autoheader
$ automake --force-missing --add-missing
$ autoconf
$ ./configure


autoreconf is your friend:
CODE
autoreconf -fi
./configure
Go to the top of the page
+Quote Post
qbast
post Aug 13 2012, 19:11
Post #46





Group: Members
Posts: 5
Joined: 8-August 12
Member No.: 102112



QUOTE (D404 @ Aug 10 2012, 22:09) *
QUOTE (qbast @ Aug 9 2012, 12:01) *
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.
Go to the top of the page
+Quote Post
pps83
post Aug 26 2012, 20:21
Post #47





Group: Members
Posts: 3
Joined: 26-August 12
Member No.: 102671



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 wink.gif 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 smile.gif 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).
Go to the top of the page
+Quote Post
db1989
post Aug 26 2012, 20:46
Post #48





Group: Super Moderator
Posts: 5141
Joined: 23-June 06
Member No.: 32180



QUOTE (pps83 @ Aug 26 2012, 20:21) *
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.
Go to the top of the page
+Quote Post
m45t3r
post Aug 26 2012, 23:48
Post #49





Group: Members
Posts: 22
Joined: 14-January 12
Member No.: 96431



QUOTE (db1989 @ Aug 26 2012, 16:46) *
QUOTE (pps83 @ Aug 26 2012, 20:21) *
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).
Go to the top of the page
+Quote Post
pps83
post Aug 27 2012, 00:18
Post #50





Group: Members
Posts: 3
Joined: 26-August 12
Member No.: 102671



QUOTE (db1989 @ Aug 26 2012, 20:46) *
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 smile.gif
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.
Go to the top of the page
+Quote Post

6 Pages V  < 1 2 3 4 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th April 2014 - 03:10