[FFmpeg-devel] [RFC] AAC Encoder
Tue Aug 19 19:30:18 CEST 2008
On Tue, Aug 19, 2008 at 06:26:43PM +0200, Gabriel Bouvigne wrote:
> Michael Niedermayer a ?crit :
> >>Regarding the highpass method, if the highpass freq is properly choosen,
> >>it's a method that demonstrated its usefullness. Its main drawback is
> >>usually the computation time compared to spectrum-based methods which
> >>can often be done using data that is already computed.
> > And how does one properly choose it?
> > Is it content dependant, if so i really have my doubts about it being a
> > good choice as algorithm.
> The highpass freq should be choosed in order to:
> a)filter low freq content in order to not trigger short blocks on low
> freq transcient, as humans are not really sensitive to "low" freq
> attacks. Some codecs like mp3 and atrac even some possible mixed block
> sizes, where low freqs are coded with a long block while higher freqs
> are coded with some short blocks. Usually, a 2 or 3kHz highpass is fine
> for it.
> b) filter low freqs so you are not fooled by the period of a low freq
> signal (you could end up with fake surges within some of the short windows)
> (Lame uses fs/4 as an highpass value)
> From a practical POV, when there is a transcient (this is the same for
> audio or video), you have some energy spreaded over a big part of the
> spectrum, so a "too high" highpass is not really a big deal.
If i have a signal of just a sine wave that will result in the same high pass
energy no matter if the signal changes its frequecy significantly a few times
The highpass method would fail to be able to seperate these. And i suspect
some of these would be better coded with short windows.
What i dislike on the highpass method is that it is a heuristic checking for
some pattern very commonly occuring together with cases that are better coded
with short windows. It does not check which of the transform sizes is better
at decorrelating the data which is what actually matters.
So no, i do not belive at all that the highpass method is a good choice :)
We really have to do actual tests to see what is best in practice ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel