From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <063e01c2d33e$9df94f70$4d4a800a@will551>
From: "Conor Williams" <connorwilliamsie@aol.com>
To: <9fans@cse.psu.edu>
References: <47ba03a0d75f21fcb5985bfeb9bb0aa7@9fs.org>
Subject: Re: [9fans] mpg123
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Date: Thu, 13 Feb 2003 09:02:20 +0000
Topicbox-Message-UUID: 5af269b6-eacb-11e9-9e20-41e7f4b1d025

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