[FFmpeg-cvslog] r24892 - trunk/libavcodec/aacpsy.c

[Nathan Caldwell]

On Fri, Aug 27, 2010 at 10:11 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Alex Converse <alex.converse <at> gmail.com> writes:
>
>> > > Log:
>> > > acenc: LAME-inspired window decision
>> > >
>> > > This performs quite a bit better than the current 3GPP-inspired window
>> > > decision on all the samples I have tested. On the castanets.wav sample it
>> > > performs very similar to iTunes window selection, and seems to perform
>> > > better than Nero.
>> > > On fatboy.wav, it seems to perform at least as good as iTunes, if not
>> > > better.
>> > > Nero performs horribly on this sample.
>> >
>> > This broke aac-encoding completely for me: The resulting files sound totally
>> > distorted.
>> >
>>
>> What settings are you using?
>
> ffmpeg -i appletrailer.mov -ab 256k test.aac
> ffmpeg -i dvbrecording.ts -ab 256k test.aac
>
> Both sound ok with r24891, both sound heavily distorted with 24892.
>
> Does it work fine for you?

I'm looking into this. Do note, that stereo encoding is known to be
broken, even with the old 3GPP attack detection, it gives very poor
results!

My first hunch is it is a bug in stereo handling when common windows
are NOT used.

I did a quick hack that only allows common windows, and I get just as
bad output as as with the old 3GPP attack detection. However, it's not
worse like it is without the hack. This doesn't mean I'm correct (Alex
doesn't think so).

Also, I suspect this was never a reason with the 3GPP attack
detection, because, after a few frames it would bias heavily to long
blocks. Long blocks (in this case) will always use a common window
(which, mostly, is working).

If I'm correct, this may stay broken for a while, unless someone else
wants to fix it. I'm trying to only tackle small pieces at a time, and
fixing stereo is a few down on my list.


-- 
-Nathan Caldwell