Re: BARK implementation (or specification) error

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