Re: [9fans] mpg123

["Conor Williams" <connorwilliamsie@aol.com>]

nice 1 Nigel - that worked a peach.
There wasnt any noticable change warping wise
really...
I still like my 0.001 hack!

Tad & Russ - maybe incorporate the change
below into layer3.c on those 2 ports of mpg123.
l8r
will551
----- Original Message -----
From: <nigel@9fs.org>
To: <9fans@cse.psu.edu>
Sent: Tuesday, February 11, 2003 11:26 AM
Subject: Re: [9fans] mpg123


> > 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);
>
>
>
>