Menu
▾
▴
#60 faac endless loop in FixNoise
faac goes into an endless loop in FixNoise.
On the wav file being used the encoding starts and then about 8%
of the way thru the file the process goes into a loop consuming
100% of the cpu.
This has been observed on both FreeBSD and OS/X (haven't tried
other systems yet).
This command:
faac --mpeg-vers 4 --obj-type LC -b 32 -o red.aac red.wav
hangs at frame 1700 with:
Freeware Advanced Audio Coder
FAAC 1.24+ (May 17 2004) UNSTABLE
Average bitrate: 64 kbps
Quantization quality: 100
Bandwidth: 5442 Hz
Object type: Low Complexity(MPEG-4) + TNS + M/S
Container format: Transport Stream (ADTS)
Encoding red.wav to red.aac
frame | bitrate | elapsed/estim | play/CPU | ETA
1700/20273 ( 8%)| 64.2 | 2.3/27.2 | 15.91x | 24.9
The workaround is to add "--no-tns" to the options and then
the encoding proceeds normally
The command:
faac --mpeg-vers 4 --obj-type LC -b 32 --no-tns -o red.aac red.wav
runs to completion:
Freeware Advanced Audio Coder
FAAC 1.24+ (May 17 2004) UNSTABLE
Average bitrate: 64 kbps
Quantization quality: 100
Bandwidth: 5442 Hz
Object type: Low Complexity(MPEG-4) + M/S
Container format: Transport Stream (ADTS)
Encoding red.wav to red.aac
frame | bitrate | elapsed/estim | play/CPU | ETA
20273/20273 (100%)| 64.2 | 24.0/24.0 | 17.99x | 0.0
Logged In: YES
user_id=712256
There has been a similar report from a Linux user which
resulted in a rather huge thread on the Audiocoding.com
forum. It seems that the Windows version does not have
these problems, so it would be great if you could read through
that thread and also test the same file with a Windows
compile. By the way, another "trick" that was mentioned
there was to disable M/S matrixing with --no-midside, but not
disabling TNS.
http://www.audiocoding.com/phorum/read.php?
f=1&i=5311&t=5311
Furthermore using -b 32 with v1.24 should result in an
average bitrate of 32 kbps (if it's a stereo input file), not in
64 kbps (changed behaviour from earlier versions using the -a
switch), but this could also be caused by the outdated table
in the code for the ABR mode specifying the cutoff
frequencies for different bitrate settings.
Logged In: YES
user_id=713342
Thanks for the response. I have since verified that faac
goes into the endless
loop in FixNoise() on FreeBSD, OS/X, and Linux (SuSE 9.1).
Each has a slightly
different gcc version so if it's a compiler problem it
affects multiple systems and
compilers.
Out of the 4 systems in use none of them have any windows/M$
capability and I'd
prefer they stay that way (;)).
It is interesting though that the '-b' option did report
64kbps total, as if the
old behaviour of perchannel rate was still being used.
I will try the --no-midside option. If that also works then
there are two
workarounds for the hang, --no-midside and --no-tns
Logged In: YES
user_id=761
I believe I have isolated the cause of this bug. This is it:
In frame.c:faacEncEncode, the CalcAvgEnrg() function is
called, which computes the average energy and sets the value
of "lastx." Afterwards, the MSEncode() function is called,
which may switch to using mid/side stereo. If MSEncode()
does in fact apply the mid/side transformations, the values
in hEncoder->freqBuff will change. This invalidates the
results computed by CalcAvgEnrg().
Later, in aacquant.c:CalcAllowedDist, there is a condition
block that starts like this:
if (coderInfo->block_type != ONLY_SHORT_WINDOW)
Inside that block, if the value of "lastx" is stale due to
the use of mid/side stereo, a rare circumstance causes start
== end. When this happens, the value of xmin[sfb] computed
at the end of this function becomes NaN.
Then, in the FixNoise function, a NaN value of xmin[sfb]
will cause it to stay in an infinite loop. It's possible
that on Windows machines, the NaN is interpreted slightly
differently, causing it to not enter an infinite loop in
that case. That's why this bug only crops up on certain
platforms. Also, the bug only appears when both mid/side
stereo and LNS are enabled.
I know nothing about audio encoding, but the above is my
analysis of the bug based on code execution alone. I
believe the solution is simply to call CalcAvgEnrg() again
after calling MSEncode(). I will attach a patch which fixes
the bug for me.
Logged In: YES
user_id=761
I don't seem to have permissions to attach files, so here is
the patch inline, against current CVS. This should be
checked by someone with more intimate knowledge of how AAC
encoding works, but as I said, this solves the problem for
me, and I don't hear any distortions in the output audio.
--- faac/libfaac/frame.c.orig 2004-11-10
00:18:28.000000000 -0500
+++ faac/libfaac/frame.c 2004-11-10
00:23:17.000000000 -0500
@@ -748,6 +748,9 @@
}
MSEncode(coderInfo, channelInfo, hEncoder->freqBuff,
numChannels, allowMidside);
+ for (channel = 0; channel < numChannels; channel++) {
+ CalcAvgEnrg(&coderInfo[channel],
hEncoder->freqBuff[channel]);
+ }
#ifdef DRM
/* loop the quantization until the desired bit-rate is
reached */
Logged In: YES
user_id=712256
Great, thank you very much for your effort and analysis!
Perhaps you know that there is no active FAAC developer at
the moment, but I'll ask Menno tomorrow if he could commit
your patch to the CVS. To me it sounds as if this could be
the solution for that "mystery bug", at least the part that I
can understand.