Loading Profile...
v.3.1b1_FFT window size changes Rev Time
3.1b1 (3010.2.1)
This new version of the Rev plugin adjusts the calculated Rev time according to the FFT window size. It seems to me that the default window size ends up being to short for accurate rev time calculations; you have to make it longer manually until the Rev times stop changing. Am I getting it right? Could this be automatic?
This new version of the Rev plugin adjusts the calculated Rev time according to the FFT window size. It seems to me that the default window size ends up being to short for accurate rev time calculations; you have to make it longer manually until the Rev times stop changing. Am I getting it right? Could this be automatic?
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?I just compared Rev data obtained with v.3 to 3.1b1. It turns out that if I leave the FFT window size to automatic, the REV time data is wrong with this new version. But if I make it longer manually, I get the exact same results now than before, only with more data where SNR is bad (great!).
So the old way was able to adjust the FFT window size for accurate RT calculations... -
Inappropriate?This is an intentional change, and a change for the better. The trouble with reverberation time estimations is the effect of the noise floor on estimated data.
The 'old way' of doing reverberation time calculations was not to window the data at all. The estimation would be performed on the energy decay curve (Shroeder plot) calculated for the whole impulse response. The new method only performs the estimation on the data inside the user-selected window.
So, the way you use the 'new' method is to switch your impulse to the energy decay curve display, and window the portion of the decay curve from its peak to where it 'intersects' with the noise floor. This will give you a much more accurate calculation.
There are methods that exist for determining these things programmatically, but I have yet to master the mathematics behind them. The simplest, and most flexible method, seems to be windowing out the excess noise floor data, which is the direction I decided to take for now.
I will have to update the manual accordingly to reflect the change. -
Inappropriate?It definitely is a change for the better. The drawback is the extra manipulation involved for the user that makes the time needed substantially longer. So, yes, an “automatic” feature would be appreciated. I’m also thinking about less skilled users who may get confused by this approach ...
BTW, are we still ISO 3382 compliant with this new method? -
Inappropriate?We're definitely still ISO 3382 compliant here. The ISO 3382 merely states that the individual bands must be filtered by fractional octave (or third-octave) filters (preferrably the ones defined by IEC 61260, which is what I implement), and the calculation of the curve to be estimated is done using the energy decay curve for each band.
How the reverberation time estimation is done is left as an exercise to the reader of the spec. You can actually use FuzzMeasure to do a manual implementation of ISO 3382 to find T20 (for example) by the following:
1. Create an octave band decomposition of the signal
2. Switch to the energy decay curve graph in the impulse view
3. Visually determine the points at -5dB and -25dB for a given octave band
4. Visualize a straight line that fits between the -5dB and -25dB points
5. Extend that line to intersect with -60dB on the Y axis
T20 is the time between the 0dB point and the -60dB point you found using the method above.
Obviously, it's better you let my software do this automatically for you. ;)
EMPLOYEE
