There is a new addition to my collection - falabaac encoder
https://github.com/Sound-Linux-More/falabaac
It remains to understand whether it is worth using it at all?
Well, I've tried it, I've compiled it and it seems to produce a result that would be worthy of testing by those with ears a lot better than mine. ;)
Does it use CBR, ABR, or VBR encoding? I can't tell from the source code, and the README just says it has 6 "speed" levels, rather than bitrate controls or quality levels.
The following content is included in one of the header files of the source code.
For you attention:
1. sample rate only support 32, 44.1, 48kHz(I think enough, high is no useless, low sample rate sound terrible),
if you want to support more sample rate, complete fa_swbtab and add code in fa_aacenc_init by yourself, very easy
2 .vbr with quality control (0.1 ~ 1.0), vbr mode is recommend for it adjust bitrate according to the frame feature;
cbr(roughtly cbr, because if want have accurate bit rate can cost more bitrate control loop and will degrade the
speed performance), cbr support 16~160 per channel, means that if encode stereo audio, can support (32 ~320kbps)
default settings is: -q 0.7, band width is 17kHz, roughtly bitrate is 110 ~ 150kbps according to the audio sample feature
if you want the best quality and wide band width, use -q 1, the band width extend to 22kHz and encoding whole
frequency line using psychmodel
you can download the EBU test audio file frome the web site below to do sound quality test:
http://tech.ebu.ch/public-cations/sqamcd
3. 64 chn can support, lfe support (need you test, lfe I didn't test more)
4. now only support mpeg_version 2(mpeg2aac), sbr and ps not support now, is developing
MPEG2 1
MPEG4 0
and only ADTS format support
5. aac_objtype only support MAIN and LC, and ltp of MAIN can not support(useless, very slow and influece quality little) , SSR is not support
MAIN 1
LOW 2
SSR 3
LTP 4
6. ms encode is support, but if you use fast quantize method(according to you speed_level choice), I close ms encode
7. band_width you can change by yourself using option -w
8. I give 6 speed level(1~6), you can choose according to your application , 1 is the lowest but very good quality, 6 is fatest but low quality,
default is 1(strongly recommend),
I think level 3 is a good choice if you want fast encoding, the speed is more than 2 times compare to the speed_level 1.
9. Summary----
Want Best quality (default) : use -l 1 (best quality, very good sound, smoothly and stable)
Want Normal quality and fast speed: use -l 3 (it is good choise, normal quality and speed you can tolerant)
Want Fast speed : use -l 5 (if is rock music, can not hear abnormal; but if is quiet or piano audio, maybe not good)
Well, I've tried it, I've compiled it and it seems to produce a result that would be worthy of testing by those with ears a lot better than mine. ;)
I compiled it on Void Linux (Glibc version) x86_64 and it compiled in a second or two. I can execute it but when encoding I get segmentation fault every time. Did you experience the same?
No. I compiled for win32 using VS2015 and it ran fine, then I compiled using Intel19 and that ran fine as well, but faster. I tried compiling for x64 but that failed and I didn't pursue why that was. Since no x64 for Windows compile was offered for download I kind of assumed that it was a known problem although the MS project files in the download were for VC6 which perhaps tells it's own story!
No. I compiled for win32 using VS2015 and it ran fine, then I compiled using Intel19 and that ran fine as well, but faster. I tried compiling for x64 but that failed and I didn't pursue why that was. Since no x64 for Windows compile was offered for download I kind of assumed that it was a known problem although the MS project files in the download were for VC6 which perhaps tells it's own story!
Thank you for the reply and information!
The following content is included in one of the header files of the source code.
Thanks! Where did you find it?
[2587975.733391] falabaac[30154]: segfault at e0e22048 ip 0000000000403bb7 sp 00007ffd6fb9d280 error 4 in falabaac[400000+199000]
;D
The following content is included in one of the header files of the source code.
Thanks! Where did you find it?
https://github.com/Sound-Linux-More/falabaac/blob/master/src/include/fa_aacapi.h
There is a big difference in VBR bitrate when I used 0.8 quality (pushing the bitrate to 129kbps with default speed 1) and speed 3, which is over twice as fast but the bitrate bloated to 168kbps. Speed setting 2 had hardly any speed increase but a very slight bit rate difference to speed 1.
[2587975.733391] falabaac[30154]: segfault at e0e22048 ip 0000000000403bb7 sp 00007ffd6fb9d280 error 4 in falabaac[400000+199000]
Well, that's not going to work:
typedef unsigned uintptr_t;
There is a big difference in VBR bitrate when I used 0.8 quality (pushing the bitrate to 129kbps with default speed 1) and speed 3, which is over twice as fast but the bitrate bloated to 168kbps.
I guess the speed setting is similar to the -q switch in qaac. Increasing the encoding speed results in bitrate bloat since the encoder isn't trying as hard to find the most efficient compression method.
Latest news - falabaac encoder has been updated to version 2.1.1
https://github.com/Sound-Linux-More/falabaac
[2587975.733391] falabaac[30154]: segfault at e0e22048 ip 0000000000403bb7 sp 00007ffd6fb9d280 error 4 in falabaac[400000+199000]
Well, that's not going to work:
typedef unsigned uintptr_t;
It's weird but correct.
It works now. It's because I launch it from its compile directory without install, like ./falabaac
************************************************************
* *
* falabaac encoder v2.1.0.230 *
* *
* Copyright (C) 2012 luolongzhi ��� (Chengdu China) *
* Free Software *
* *
* Email: luolongzhi@gmail.com *
* *
************************************************************
SUCC: inputfile is garvarentz_-_hashisch_party.wav
SUCC: check option ok
NOTE: configuration is below
NOTE: inputfile = garvarentz_-_hashisch_party.wav
NOTE: outputfile= garvarentz_-_hashisch_party.aac
NOTE: vbr switch= 1
NOTE: quality = 0.700000
NOTE: speed lev = 1
samplerate = 44100
band width= 17599.998047 kHz
the frame = [7837]
The number of 1 index cost time is 10.152905 sec
Well, that's not going to work:
typedef unsigned uintptr_t;
It's weird but correct.
It works now. It's because I launch it from its compile directory without install, like ./falabaac
It works now because the typedef was fixed: https://github.com/Sound-Linux-More/falabaac/issues/1
I guess there's a bit of a language barrier. He replied with "don't care" to your bug report, and then he fixed it anyway. :P
Shouldn't that be "#include <stdint.h>" instead?
It works now because the typedef was fixed: https://github.com/Sound-Linux-More/falabaac/issues/1
It's already defined in stdint.h
I had no problem in 32 with GCC 10.2.1 and in 64 with GCC 5.5.0
There was ton of warnings - perhaps about it - but eventually it works.
Shouldn't that be "#include <stdint.h>" instead?
Yes it's in it. Maybe I got some "already defined .." warning but I didn't notice.
So this redefinition shouldn't have posed problem ?
/* Types for `void *' pointers. */
#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned long int uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned int uintptr_t;
#endif
I guess there's a bit of a language barrier. He replied with "don't care" to your bug report, and then he fixed it anyway. :P
He might mean "don't worry, it will be fixed." by that. Sounds like a language barrier to me either.
Shouldn't that be "#include <stdint.h>" instead?
It's already defined in stdint.h
For whatever reason he's not using stdint.h but has his own fa_inttypes.h.
As far as I know, VC6 didn't have stdint.h (it is a relatively recent addition to the C standard), and the project file is for VC6 (from good old 1998). So, probably this is why stdint.h is not used.
Having modified 'getopt.c' to include string.h, and modified 'fa_inttypes.h' to include stdint.h and exclude the typedefs that conflict, I can get a clean compile in Intel 19.0 for win32 and x64. I can make them available if anyone is interested.
Having modified 'getopt.c' to include string.h, and modified 'fa_inttypes.h' to include stdint.h and exclude the typedefs that conflict, I can get a clean compile in Intel 19.0 for win32 and x64. I can make them available if anyone is interested.
Without your compiles, this topic would clearly not be complete. Thanks!
Without your compiles, this topic would clearly not be complete. Thanks!
Your wish is my command!! ;) Here they are;
www.rarewares.org/files/aac/falabaac-2.1.1.win32.zip (http://www.rarewares.org/files/aac/falabaac-2.1.1.win32.zip)
www.rarewares.org/files/aac/falabaac-2.1.1.x64.zip (http://www.rarewares.org/files/aac/falabaac-2.1.1.x64.zip)
Opinions on quality, etc, welcome. :)
Hello,
Thanks John for the compiles.
One type of rhythm this encoder doesn't like attached below. With -t 1 (short block only), it's Ok but bitrate goes all to 256kbit-ish, regardless you specify VBR or a bitrate.
AiZ
Thanks, John! Quick test with the Win32 binary at roughly 96 kbps stereo, 48-kHz Wave as input: CBR ("-b 91") sounds better than VBR ("-q 0.3"), both are automatically band-limited to less than 14 kHz, overall audio quality is, unfortunately, consistently bad in comparison to other (xHE-)AAC encoders - spectral holes, stereo image collapse, low-frequency rumbling. Probably even worse than MP3. Encoding was stable, though, it seems. ADTS format, not seekable, no MP4 containering.
Might be better at higher bit-rates, but then again, we have FDK-AAC and others at those rates. The psychoacoustic model should probably be re-evaluated.
Chris
I encoded with this program doing:
falabaac -i C:\Users\Use\Music\wav\10.wav -q 1.0"%i.m4a"
it works, it creates an aac file and then I remux with pazera audio extractor.
Then both files are corrupt and there is an hissing sound at the end at 0 db; like the electricity goes off.
Maybe because I'm a windows 7 user. What is the error?
Darnit, it seems this is not the FAAC replacement I was looking for (so far).
Still, I admire the effort :)
BTW, when I mux the AAC output with FFMPEG to a M4A container I get a nice file reduction (around 0.1%) :)
Edit: I meant 1% (like I save 300kb from a 3.6MB file.)
Edit2: Forget about the speed settings for now (i.e. the -l 6 lowpass is 10khz), the default -l 1 setting is pretty good.