Dear list,<div><br></div><div>I've been thinking about the below section of audioCollector.cpp;</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre">   </span>// seem to only have stuff in the lower half - something to do with nyquist?</div>
<div><span class="Apple-tab-span" style="white-space:pre">      </span>float UsefulArea = m_BufferLength/2;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>for (unsigned int n=0; n<m_NumBars; n++)</div>
<div><span class="Apple-tab-span" style="white-space:pre">      </span>{</div><div><span class="Apple-tab-span" style="white-space:pre">            </span>float Value = 0;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">            </span>float f = n/(float)m_NumBars;</div>
<div><span class="Apple-tab-span" style="white-space:pre">              </span>float t = (n+1)/(float)m_NumBars;</div><div><font class="Apple-style-span" color="#ff0000"><span class="Apple-tab-span" style="white-space:pre">           </span>f*=f;</font></div>
<div><font class="Apple-style-span" color="#ff0000"><span class="Apple-tab-span" style="white-space:pre">             </span>t*=t;</font></div><div><span class="Apple-tab-span" style="white-space:pre">           </span>unsigned from = f*UsefulArea;</div>
<div><span class="Apple-tab-span" style="white-space:pre">              </span>unsigned to = t*UsefulArea;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">         </span>for (unsigned int i=from; i<=to; i++)</div>
<div><span class="Apple-tab-span" style="white-space:pre">              </span>{</div><div><span class="Apple-tab-span" style="white-space:pre">                    </span>if (i<m_BufferLength)</div><div><span class="Apple-tab-span" style="white-space:pre">                     </span>{</div>
<div><span class="Apple-tab-span" style="white-space:pre">                              </span>Value += m_FFTBuffer[i];</div><div><span class="Apple-tab-span" style="white-space:pre">                     </span>}</div><div><span class="Apple-tab-span" style="white-space:pre">            </span>}</div>
<div><br></div><div><span class="Apple-tab-span" style="white-space:pre">             </span>if (Value<0) Value=-Value;</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>Value*=m_Gain;</div><div><span class="Apple-tab-span" style="white-space:pre">               </span>m_FFTOutput[n]=((m_FFTOutput[n]*m_SmoothingBias)+Value*(1-m_SmoothingBias));</div>
<div><span class="Apple-tab-span" style="white-space:pre">      </span>}</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">   </span>return m_FFTOutput;</div></div><div><br></div><div>This section maps the FFT bins to the "bars" that correspond to the different "gh" bands in Fluxus. The squaring that I highlighted seems to be a attempt to compensate for how the output of the FFT transform is linear; the whole of the second half of UsefulArea will refer to the top-most octave of our bandwith (likely from 11.25 to 22.5KHz, or from "quite high" to "beyond the hearing"). Without such compensation 8 of the default 16 gh bands would cover that octave, 4 would cover the next down, etc.</div>
<div><br></div><div>The issue is that squaring the numbers doesn't go far enough; the curve is logarithmic. Another issue is that the kind of curve we'd ideally get isn't the same for all numbers of bands; at 10 bands it's easy as we can map each to one of the octaves (give or take) between 20 and 20K Hz. On the other hand; when we get 512 bins, due to a FFT frame of 1024 samples then setting the requested number of bands to 512 should create a linear mapping of one band per FFT bin. Ideally the curve would crossfade between logarithmic and linear as the number of bands increases from a relatively low number to approaching the number of bins (having more bands than bins doesn't make much sense to me).</div>
<div><br></div><div>I'm not sure what kind of variable curve those concerns imply in practice, but I do think that currently too many (5 according to my calculations)  of the 16 bands that we have by default are concerned with the top-most octave of our hearing. The highlighted lines are better than nothing under all realistic conditions that I can quickly think of, but I'd like to try coming up with a better plan.</div>
<div><br></div><div>Yours,</div><div>Kas.</div><meta http-equiv="content-type" content="text/html; charset=utf-8">