Despite the bad vibe I was getting, I was willing to tolerate issues I've found in the cutoff logic (bad/buggy assignment for high CBR, no checks for valid ranges).

But what I see here is really dangerous. One should not rely on this code for anything serious.

I hope Google didn't pay much for this!

This sucks, quality on difficult samples is much better than libaacplus and faac. I was hoping that we are finally getting good free encoder with quality comparable to best commercial ones.What do you mean by bad cutoff for high CBR? Too low?

Despite the bad vibe I was getting, I was willing to tolerate issues I've found in the cutoff logic (bad/buggy assignment for high CBR, no checks for valid ranges).

But what I see here is really dangerous. One should not rely on this code for anything serious.

I hope Google didn't pay much for this!

What do you mean by bad cutoff for high CBR? Too low?

Well, not too low. But it will never go above 17kHz for bitrates from 192kbps all the way up to 512kbps (stereo). So you need to pass '-cutoff 20k' (or whatever value you desire) manually.

And btw, It used to crash if you forgot the 'k'. And It used to silently use 20k if you passed higher values without even a warning. That's what I meant by "no checks for valid ranges". This does not happen anymore in ffmpeg/avconv because a small patch was applied to check for this (in libav/FFmpeg).

This is just an example I came across.

It's obvious now that other (more relevant) parts of the code lack important checks and unit tests. It's possible the whole implementation was never properly tested!