Gabriel Bouvigne wrote:
> I'd like to know the purpose of ath5.
Here's a message excerpt to cover your query:
Mark Taylor wrote:
> Anyway, I see that the interpolation functions are used for yet
> another ATH formula. We already have too many, so you are going to
> have to justify your motivations for a new one! The ATH values are
I spent the time collecting and cross-referencing data to fill a
void. For some, the previous ATH types of LAME are surprisingly
insensitive to frequencies from 15 to 19 kHz (by roughly 10 or 20
dB). The primary motivation for this ATH type is to remedy this
shortcoming of LAME's existing ATH types by providing an
alternative based on experimental data that does not marginalize
the high frequency region. To keep this ATH type sane for its
purpose, I referenced and/or merged existing data from ATH curves
used in encoders like LAME, mppenc, and others.
This new ATH type may become more useful or bit rate effective
with future LAME expansion. At present, frequencies above 16 kHz
require many bits in VBR mode. Also, LAME has yet to perform
ATH-shaped dithering when quantizing bands; this procedure may
yield a more pleasant signal above 16 kHz at lower bit rates, or
allow a reduction of bits spent on the high frequency region.
I do believe that a multitude of ATH types is a bad thing for an
encoder that targets a one setting fits most philosophy. However,
a more flexible encoder might ideally have a unified ATH based on
the varying spectrum of hearing ability across individuals. For
example, a setting of 90 might be practically transparent for 9
out of 10 people. Unfortunately, I am not aware of sufficient
independent data to support this more ideal unification. Until
such a unification, different ATH types are available to give
users the advantage of several ATH options for different
preferences or hearing abilities.
> The first thing is is this really usefull? Does it helps in some cases over
No, it's not _really_ useful at the moment. However, certain future
enhancements to LAME would much improve its usefulness.
It's only a step in the process.
> The second thing is that a very close result to ath5 could have been obtain
> without adding new functions to the lame code (qinterp_cf_42,
> qinterp_cf_3,qinterp_eval) by passing an appropriate value to the already
More functions aren't always better, but quadratic interpolation
functions allow general curve development without the need for
external curve fitting tools, and without requiring the entry of
as many data points as with linear interpolation.
> existing ath2 formula (the way ath3 is handled).
ATH type 3 is directly derived from ATH type 2.
ATH type 5 is not, and references data from several sources.
Fitting to a type 2 derivative would wipe out the data in one
area of the curve or another.
Extending type 2 for a special case just adds more overhead, and
the actual data still isn't obvious to new coders who may wish to
tweak the ATH. Additionally, for the current realization of ATH
type 2, a compiler already generates more code than either type 1
or type 5, and ATH type 2 eats the most CPU cycles.
> I'm asking because if it was there only for a specific testing, perhaps it
> could be removed if it doesn't provide anything usefull to the encoder.
ATH type 5 is currently useful for testing (or for normal use with
"--vbr-mtrh"), but it's usefulness can only increase with further
If we are to purge ATH types today, keeping only ATH type 2
currently seems to be a reasonable compromise. If certain
problems of LAME are resolved, "--athtype 3 --athlower 6" may hold
the more promise as a default. With additional developments,
"--athtype 5" may become the most viable alternative. Until the
dust settles, and LAME is set in concrete, removing ATH types may
best wait. (Even after LAME is finished, having the alternatives
available may serve some users.)