[Vorbis-dev] BARK implementation (or specification) error
Tor-Einar Jarnbjo
tor-einar at jarnbjo.name
Fri Mar 21 02:32:29 PDT 2014
Hi Chris,
Am 20.03.2014 18:56, schrieb Chris Moore:
> In the course of some work which I describe below, I have found a
very significant difference between the BARK function described in the
Vorbis specification and its implementation in libvorbis.
I believe to have implemented one of the first Vorbis decoders based on
the specification around 2002 and found several relevant differences
between the specification and the reference decoder. Most of the issues
I found were corrected in the specification, but I am sure that I didn't
find all of the deviations.
> In the specificationhttp://xiph.org/vorbis/doc/Vorbis_I_spec.pdf
> bark(x) = 13.1arctan(.00074x) + 2.24arctan(.0000000185x**2 + .0001x)
>
> In the libvorbis code http://svn.xiph.org/trunk/vorbis/lib/scales.h
> #define toBARK(n)
(13.1f*atan(.00074f*(n))+2.24f*atan((n)*(n)*1.85e-8f)+1e-4f*(n))
>
> You will note that the last term is inside the parentheses of the
second arctan function in the specification but outside in the libvorbis
implementation.
> This results in extremely large differences at high frequencies.
> Which is correct: the specification or the implementation?
Hard to say, since you may not even find an encoder making use of that
feature. The function is only relevant when decoding floor type 0 and
even the specification states:
"Floor 0 is not to be considered deprecated, but it is of limited modern
use. No known Vorbis encoder past Xiph.Org's own beta 4 makes use of
floor 0."
I remember having problems interpreting the floor 0 specification and
decided to not implement it at all. I am not sure exactly how much my
Java library (J-Ogg) has been used, but I've never heard any complaints
that someone has used it and run into problems that floor 0 is unsupported.
> What should I consider to be the reference Vorbis decoder?
> Currently I am supposing it to be the vorbisfile_example code in
Vorbis but I am rather surprised that while the heavy transcendental
functions are in double, many other calculations are only in float.
> I would have expected a reference decoder to use the greater
precision of double throughout.
I don't have time to check the specification right now, but I am pretty
sure that the specification does not require the decoder to use a given
precision. A few places, the specification points out that a fixed point
implementation should use a higher precision than what may seem obvious,
but there are several "shoulds" in these statements and I don't think
many "musts". The result is of course that two decoders may produce
slightly different PCM output and both be considered to be correct
according to the specification.
Regards,
Tor
More information about the Vorbis-dev
mailing list