Re: [9fans] mpg123

[nigel@9fs.org]

> thanks Nigel
> Heard my first plan9 mp3 late last night!
> I ended up subtracting 0.001 from that eqation and let
> it run the 1 -> 16 loop! doesnt seem to have warped it 2
> much!

That's almost bound to be a bad decision. It will warp
all the values, rather than just the one which I suspect
is not used.

You forced me to get my copy of 11172-3 off the shelf.

These tables are used for intensity coding, e.g. the left
channel has the intensity of the frequency bucket,
the right channel the pan ratio.

Given that the equation is

ratio = tan(pos * pi / 12)
L' = L * ratio / (1 + ratio)
R' = R * 1 / (1 + ratio)

which can be rewritten as

ratio = tan(pos * pi / 12)
R = ratio/(1 + ratio)
L' = L * R
R' = L * (1 - R)

R = 0 pans fully to the right, and increasing values
tend towards the left. When R hits 1, it is fully
panned to the left.

The tan function tends to infinity at 90 degrees, or
PI/2 radians. Thus is makes no sense for pos to
take a value > 6. In fact, 6 itself is special. You can
interpret it as meaning R = 1.

The spec. indicates that pos == 7 disables the panning
effect.

So I contend that encoders will only generate values
from 0 - 7, even though the field can be 4 bits, only
3 are used for intensity coding. Thus my fix will
trash one row of the pow[] table which is generated
in the same loop, which does use 4 bits.

If you look at mad (libmad/layer3.c), you will see that
it confirms this. The implementor of mad clearly
thought about what this part of 11172-3 is supposed
to achieve.

A better fix is therefore:


  for(i=0;i<16;i++) {
    double r;

    if (i < 6) {
	double t = tan( (double) i * M_PI / 12.0 );
	r = t / (1.0 + t);
    }
    else
	r = 1.0;

    tan1_1[i] = r;
    tan2_1[i] = 1.0 - r;
    tan1_2[i] = M_SQRT2 * r;
    tan2_2[i] = M_SQRT2 * (1.0 - r);