home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: Multimed / Multimed.zip / pm123v10.zip / realeq.txt < prev    next >
Text File  |  1998-06-16  |  3KB  |  76 lines
  1. Real Equalizer
  2. ==============
  3.  
  4. This Equalizer is a THE real thing.  A full fledged FIR designed with the
  5. window method using OOURA's RDFT and a von Hann window.  It's not the cheap
  6. assed EQ in the MPEG audio decoding that distorses the sound more than
  7. anything else... But because it's a real EQ, it uses juice. I mean major
  8. juice.  On my P150, it hits 45% CPU usage with a FIR order of 64 while
  9. processing stereo 44.1kHz samples. I'm planning on using a Remez exchange
  10. algorithm instead of the window method to optimize the FIR order needed to
  11. achieve the desired result.  All I know is that it can "significantly
  12. reduce the order of a FIR filter", what that exactly means, I don't know. I
  13. also don't want to use an IIR, as it's 1. too complicated for me at the
  14. moment (unless I can get my hands on MatLAB), 2. might (hum) become
  15. obsolete because of advancing CPU power, and because it dephases the sound
  16. (lower quality).
  17.  
  18. To come back on the filter order for the casual user, this is the number of
  19. samples processed (in addition to the current sample) to obtain a new
  20. sample. What does this means?  Ok say you are playing at 44100Hz, this
  21. means there are 44100 samples passing per second in the filter also, right?
  22. Ok, so say you'd like to catch 20Hz and filter that decently.  This means
  23. you will need a filter order of at least 44100/20-1 = 2204!!!  With values
  24. in this range, you can make your stereo EQ jealous.  Get a Pentium II and
  25. ditch your stereo.
  26.  
  27. This also means that with my small 64 filter order, I cannot process
  28. frequencies under 44100/(64+1) = ~678Hz properly. So the choice of any
  29. bands under this frequency might be irrelevant, and modifying one of the
  30. other might give the same effect (if any effect at all).  The 32 middle
  31. bands are defined by step of 1/3 octave and are as follow in Hz (granted,
  32. the first band and last band aren't that useful, but what the heck):
  33.  
  34. 16
  35. 20,16
  36. 25,40
  37. 32
  38. 40,32
  39. 50,80
  40. 64
  41. 80,63
  42. 101,60
  43. 128
  44. 161,27
  45. 203,19
  46. 256
  47. 322,54
  48. 406,37
  49. 512
  50. 645,08
  51. 812,75
  52. 1024
  53. 1290,16
  54. 1625,50
  55. 2048
  56. 2580,32
  57. 3250,00
  58. 4096
  59. 5160,64
  60. 6501,00
  61. 8192
  62. 10321,27
  63. 13004,00
  64. 16384
  65. 20642,55
  66.  
  67. The FIR order needs to be a multiple of 2. The plansize is for the initial
  68. FFT and therefore needs to be a power of 2.  Just leave it at 4096, that's
  69. fine, unless you are planning on playing anything way over 44100kHz.
  70.  
  71. Well ok so it's not very useful on a x86 machine... I'll have to see how
  72. good it does with the Remez exchange or an IIR filter later, but you're
  73. welcome to try now.
  74.  
  75. - Samuel Audet <guardia@cam.org>
  76.