Vorbis dev - Oct 2001 - FLOOR_fromdB_LOOKUP

Hello,
You know, I always worry about the precision
and the float constants... and there is a large
lookup table in the floor1.c ... and I figure out
a way to keep the code size and speed, but
to improve the precision at this lookup table.
(the difference is small, but audible)

Here is the modifications in the floor1.c:

tatic unsigned long FLOOR_fromdB_LOOKUP[256]={
0x33E4B434,0x33F390FF,0x3401B286,
0x340A2036,0x34131A1E,0x341CA95A,
0x3426D7A0,0x3431AF44,0x343D3B49,
0x34498767,0x3456A01A,0x346492AE,
0x34736D4B,0x34819F83,0x348A0BF7,
0x3493048E,0x349C9263,0x34A6BF2B,
0x34B19538,0x34BD1F8C,0x34C969DD,
0x34D680A4,0x34E4712D,0x34F3499C,
0x35018C83,0x3509F7BA,0x3512EF01,
0x351C7B70,0x3526A6BA,0x35317B31,
0x353D03D3,0x35494C56,0x35566133,
0x35644FB0,0x357325F3,0x35817985,
0x3589E381,0x3592D977,0x359C6480,
0x35A68E4C,0x35B1612C,0x35BCE81E,
0x35C92ED5,0x35D641C6,0x35E42E39,
0x35F3024F,0x3601668B,0x3609CF4B,
0x3612C3F0,0x361C4D93,0x362675E2,
0x3631472C,0x363CCC6D,0x36491157,
0x3656225E,0x36640CC6,0x3672DEB0,
0x36815393,0x3689BB17,0x3692AE6D,
0x369C36AA,0x36A65D7B,0x36B12D30,
0x36BCB0C1,0x36C8F3DE,0x36D602FB,
0x36E3EB59,0x36F2BB16,0x3701409E,
0x3709A6E7,0x371298ED,0x371C1FC4,
0x37264518,0x37311337,0x373C9518,
0x3748D669,0x3755E39C,0x3763C9F0,
0x37729781,0x37812DAC,0x378992B9,
0x3792836F,0x379C08E1,0x37A62CB9,
0x37B0F942,0x37BC7973,0x37C8B8F9,
0x37D5C442,0x37E3A88C,0x37F273F2,
0x38011ABC,0x38097E8F,0x38126DF5,
0x381BF202,0x3826145D,0x3830DF51,
0x383C5DD3,0x38489B8C,0x3855A4EC,
0x3863872D,0x38725068,0x388107CF,
0x38896A67,0x3892587F,0x389BDB26,
0x38A5FC05,0x38B0C564,0x38BC4236,
0x38C87E24,0x38D5859B,0x38E365D3,
0x38F22CE3,0x3900F4E5,0x39095643,
0x3912430B,0x391BC44D,0x3925E3B0,
0x3930AB7B,0x393C269D,0x394860C1,
0x3955664E,0x3963447E,0x39720963,
0x3980E1FE,0x39894221,0x39922D9A,
0x399BAD78,0x39A5CB5F,0x39B09195,
0x39BC0B09,0x39C84362,0x39D54706,
0x39E3232D,0x39F1E5E8,0x3A00CF1A,
0x3A092E02,0x3A12182D,0x3A1B96A6,
0x3A25B312,0x3A3077B3,0x3A3BEF79,
0x3A482607,0x3A5527C3,0x3A6301E2,
0x3A71C273,0x3A80BC38,0x3A8919E7,
0x3A9202C3,0x3A9B7FD8,0x3AA59AC8,
0x3AB05DD5,0x3ABBD3EC,0x3AC808B0,
0x3AD50884,0x3AE2E09B,0x3AF19F03,
0x3B00A959,0x3B0905CE,0x3B11ED5B,
0x3B1B690D,0x3B258281,0x3B3043FB,
0x3B3BB864,0x3B47EB5E,0x3B54E94A,
0x3B62BF5A,0x3B717B98,0x3B80967D,
0x3B88F1B8,0x3B91D7F7,0x3B9B5245,
0x3BA56A3F,0x3BB02A24,0x3BBB9CE0,
0x3BC7CE0F,0x3BD4CA14,0x3BE29E1D,
0x3BF15832,0x3C0083A4,0x3C08DDA5,
0x3C11C297,0x3C1B3B80,0x3C2551FF,
0x3C301052,0x3C3B815F,0x3C47B0C6,
0x3C54AAE3,0x3C627CE5,0x3C7134D2,
0x3C8070CD,0x3C88C995,0x3C91AD39,
0x3C9B24BF,0x3CA539C4,0x3CAFF683,
0x3CBB65E3,0x3CC79380,0x3CD48BB7,
0x3CE25BB2,0x3CF11176,0x3D005DFA,
0x3D08B588,0x3D1197DE,0x3D1B0E01,
0x3D25218B,0x3D2FDCB8,0x3D3B4A6B,
0x3D47763F,0x3D546C8F,0x3D623A83,
0x3D70EE20,0x3D804B29,0x3D88A17E,
0x3D918287,0x3D9AF747,0x3DA50957,
0x3DAFC2F0,0x3DBB2EF7,0x3DC75902,
0x3DD44D6C,0x3DE2195A,0x3DF0CACF,
0x3E00385A,0x3E088D77,0x3E116D32,
0x3E1AE08F,0x3E24F126,0x3E2FA92D,
0x3E3B1387,0x3E473BC9,0x3E542E4D,
0x3E61F836,0x3E70A783,0x3E80258F,
0x3E887973,0x3E9157E1,0x3E9AC9DC,
0x3EA4D8F8,0x3EAF8F6D,0x3EBAF81A,
0x3EC71E95,0x3ED40F33,0x3EE1D716,
0x3EF0843C,0x3F0012C6,0x3F086571,
0x3F114293,0x3F1AB32B,0x3F24C0CE,
0x3F2F75B1,0x3F3ADCB2,0x3F470165,
0x3F53F01D,0x3F61B5FB,0x3F7060FB,
0x3F800000
};

tatic void render_line(int x0,int x1,int y0,int y1,float *d){
  int dy=y1-y0;
  int adx=x1-x0;
  int ady=abs(dy);
  int base=dy/adx;
  int sy=(dy<0?base-1:base+1);
  int x=x0;
  int y=y0;
  int err=0;

  ady-=abs(base*adx);

  d[x]*=*((float *)&FLOOR_fromdB_LOOKUP[y]);
  while(++x<x1){
    err=err+ady;
    if(err>=adx){
      err-=adx;
      y+=sy;
    }else{
      y+=base;
    }
    d[x]*=*((float *)&FLOOR_fromdB_LOOKUP[y]);
  }
}

tatic void render_line0(int x0,int x1,int y0,int y1,float *d){
  int dy=y1-y0;
  int adx=x1-x0;
  int ady=abs(dy);
  int base=dy/adx;
  int sy=(dy<0?base-1:base+1);
  int x=x0;
  int y=y0;
  int err=0;

  ady-=abs(base*adx);

  d[x]=*((float *)&FLOOR_fromdB_LOOKUP[y]);
  while(++x<x1){
    err=err+ady;
    if(err>=adx){
      err-=adx;
      y+=sy;
    }else{
      y+=base;
    }
    d[x]=*((float *)&FLOOR_fromdB_LOOKUP[y]);
  }
}

I made the lookup table with this small program.
(I hope this is a correct calculating):

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

void main(void)
{
 int i;
 float lookup;
 unsigned long *p=(unsigned long *)&lookup;
 FILE *fp=fopen("lookup.txt","wt");
 const double d=log(2.0f)/log10(2.0f)/20.0f;

 for(i=0;i<256;i++){
  double a=(double)(255-i)/256.0f * -140.0f;
  lookup=(float)exp(a*d);

  if(!(i%3))
   fprintf(fp,"\n");
  fprintf(fp,"0x%8.8X,",*p);
 }
 fclose(fp);
}

So, this is just an idea.
I hope it's useful.

regards
Attila Padar

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> Hello,
> You know, I always worry about the precision
> and the float constants... and there is a large
> lookup table in the floor1.c ... and I figure out
> a way to keep the code size and speed, but
> to improve the precision at this lookup table.
> (the difference is small, but audible)
> 
> Here is the modifications in the floor1.c:
> 
> static unsigned long FLOOR_fromdB_LOOKUP[256]={
> 0x33E4B434,0x33F390FF,0x3401B286,
[snip] 
>   d[x]*=*((float *)&FLOOR_fromdB_LOOKUP[y]);
Hmm, doesn't this trick depend on float representation
within the CPU, and hence is inherently nonportable?

Also, AFAIK float only guarantees 7 significant digits. 
The constants in the current source all have at least 8, so 
they should be safe.

I don't really understand how this could make a
difference, let alone an audible one.


-- 
GCP

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Fri, Oct 12, 2001 at 07:17:01PM +0200, Attila Padar
wrote:
> Hello,
> You know, I always worry about the precision
> and the float constants... and there is a large
> lookup table in the floor1.c ... and I figure out
> a way to keep the code size and speed, but
> to improve the precision at this lookup table.
The values listed are official and not to be changed.  Any
modifications of these values will render decode of already existing
files incorrect; encode and decode must match as exactly as machine
representation permits for correct results.

(If your encoder and decoder match, then they'll be compatable, but
your encoded files will decode incorrectly in the rest of the Vorbis
universe).

BTW, these constants are used to render floor1 in both encode and
decode; modifying them to 'better precision' will *not* improve
encoding quality (although you may think so because you might be
defeating the noise floor level by derating these constants.  You
could do the same by offsetting the noise through the psychoacoustics
settings).
> (the difference is small, but audible)
An audible difference == 'incorrect decode'.  Please do not mess with
these mandatory constants in search of greater quality.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.