Rational Acoustics



Jamie
April 16th, 2010, 04:56 PM
Hey all,

Here is a quick discussion of Smaart v7's MTW vs. Smaart v2-6's FPPO, and includes mention of SIM's standard FFT settings for Transfer Function in the mix. (This inclusion is due to the fact that this post began life as a response to a specific question regarding MTW and how it related to SIM's standard FFT settings for Transfer Function measurements.)

FPPO was our previous version (v2 - v6) of using multiple time windows in Transfer Function to create constant (fractional octave) frequency resolution data. FPPO in fact stands for "24 Fixed Points Per Octave." We achieved this though a devious mixture of FFT size and sample rate (via decimation) choices, as well as some data point banding for good measure (where the raw frequency resolution was much greater than the target 24th octave). SIM II uses a similar process (as does SIM III I believe), but generally relies on a more straight forward process that uses more FFT's with simple decimation (1/2'd sample rates) between each.

The factors that drove SIA's decisions when creating the original SmaartPro FPPO process are many - having as much to do with available processor power and data handling issues as with target resolution and TC's. When we began development of v7, we were able to take a fresh look at FPPO and the FFT settings for Transfer Function measurements. With processor power being what it is today, running FFT's of 16k, 32k or even 64k in real-time was no longer a concern. So we had to ask ourselves, do we need/want to use a multiple FFT based approach? Why not just run a huge FFT and smooth it to whatever target fractional octave resolution we wish?

Our answer for the first question was, yes, we still want to use multiple FFT's as our default. And the reason we do was the answer to the second question. (Here is the quick version) Single 16k and 32k FFTs have measurement TCs (time constants) of 341 ms and 683 ms respectively. Those are pretty huge windows when considering measurements in the mid and high frequencies, but necessary to achieve usable LF frequency resolution. The place this clearly shows itself is in the impact that reflected/reverberant energy has on the coherence trace. With a single FFT transfer function, reverb energy arriving 60, 70, 80 ms late has FAR less negative impact than in a multi-time window process that uses significantly shorter TCs for the HF portion of the measurement.

Simply put, the question here is mathematically, what reverberant energy should Smaart consider signal, and what is noise? Here our choice of TC has a significant say - do we want to treat HF the same as LF? Does our listening mechanism? Should our Coh. trace?

We chose, as our default, to use multiple time windows as we had done in the past. So . . . the next question was, what should the TC's be. In the past, we were confined to a short list of "power of 2" FFT/TC sizes. Now here in the future (where I hear everyone is gonna wear 1-piece jump suits) we can easily and efficiently use virtually any TC size. That meant we could choose our TC's with our focus on the resulting frequency resolution and the impact of the TC on our classification of reverberant energy. (What is signal, what is noise?)

Without getting into the exact numbers here (which we have no intention of publishing - but if you are handy with the math, we're confident you can derive the numbers yourself ;) ) we chose the TCs in our new MTW process so that we have >48th octave resolution above 60 Hz, and 1 Hz resolution below 120 Hz. (The math is pretty is pretty easy for figuring that lowest TC :D )

One final note, given the resolution of the new MTW process coupled with our fabulous, new, fractional-octave smoothing algorithms, we no longer combine data points in the HF to create a base 24 FPPO TF resolution. We leave that to your choice of smoothing. (And as always, if you want, you can still go back to single FFT transfer function if you wish.)

Attached is a screen capture showing FPPO, MTW and single 16k FFT transfer functions so that you can compare resolutions. The MTW and the 16k are of the same measurement. The FPPO is older, unrelated data.


Peas,
-j

PhillipIvanPietruschka
April 17th, 2010, 11:42 PM
Jamie,

Thank you for your answer. My curiousity though, exceeds the bounds of your answer. Not because I care particularly about magic time constants but because I want to better understand how the MTW will behave differently to the other systems I have some familiarity with (Sv6 FPPO, Sim3).

To this end I've spent all morning playing with Smaart 6 & 7 along with Pink Noise and a delay line. Seeing the difference has made comprehension much easier.

With your blessing, I hope, I'd like to provide a link to a blog where I have posted many screen captures that help illustrate how MTW differers from FPPO.

http://ab4t.blogspot.com

cheers,

phillipivan.

lundbergsound
April 20th, 2010, 11:02 PM
Jamie,

Thank you for the explanation. I have two questions regarding the MTW that have come up: firstly, why does it not want to run above 48k? This wouldn't normally matter except that the other day I was using v7 with an 01V running at 48k on its own clock with analog outs going into my interface, and the impulse tracker was showing a lot of problems with this. I have also noticed that when running pink noise at 96k and down-sampling the measurement signal for the MTW, the pink noise seems to stutter.

Secondly, it seems the MTW in v7 requires more level than FPPO in v6; is that the case? and if so, how come? At lower levels of pink noise, only the upper portions of the magnitude trace appear when the whole trace shows up in v6. I had thought that it might be a coherence view setting issue, but the same problem occurred when viewing an EQ trace at 100% coherence until I raised the output level.

Outside of that, the software is a thrill to use and I can use it more efficiently than v6.

Cheers,
Daniel

hurto
September 21st, 2010, 05:04 AM
mmm... thanks for info

adam
September 21st, 2010, 01:54 PM
Jamie,

Thank you for the explanation. I have two questions regarding the MTW that have come up: firstly, why does it not want to run above 48k? This wouldn't normally matter except that the other day I was using v7 with an 01V running at 48k on its own clock with analog outs going into my interface, and the impulse tracker was showing a lot of problems with this. I have also noticed that when running pink noise at 96k and down-sampling the measurement signal for the MTW, the pink noise seems to stutter.

Secondly, it seems the MTW in v7 requires more level than FPPO in v6; is that the case? and if so, how come? At lower levels of pink noise, only the upper portions of the magnitude trace appear when the whole trace shows up in v6. I had thought that it might be a coherence view setting issue, but the same problem occurred when viewing an EQ trace at 100% coherence until I raised the output level.

Outside of that, the software is a thrill to use and I can use it more efficiently than v6.

Cheers,
Daniel

Daniel,

Firstly please accept my apology for the late reply. I seem to have missed your post until today.

We will allow you to run MTW at 88200 and 96000, however we will downsample the input to either 44100 or 48000. So unless you have a specific reason for sampling that fast it's just a waste of CPU bandwidth. We limit MTW to these sample rates as the process is using some hand tuned filters that are sample rate dependent and at this point it's just not feasible to create filters for all sample rates.

With v7.1 we improved magnitude thresholding for MTW. The HF crossing threshold before the LF is no longer the case. All freqs are now virtually crossing at the same time.

Calvert Dayton
September 21st, 2010, 05:32 PM
Actually I'd beg to differ with Adam's explanation to some small extent. The main reason for not running the MTW above 48k is that there simply no good reason to do so. It's a measurement technique whose main advantages are its correlation with how our ears work and also its computational efficiency, relative to the FFT sizes you'd have to run to get the same low-frequency resolution.

Given that our ears don't really work above 20k as such, there's no real advantage to going higher than that in terms of perceptual correlation. The efficiency thing is perhaps the lesser advantage but still a key point when you want to be able to do multiple Transfer Function measurements at the same time on fairly run-of-the-mill hardware. We're also doing more FFTs per measurement than we used to, just to get the time windows where we wanted them.

We're actually already doing the additional down-sampling pass(es) that we'd need to do to support greater than 48k SRs more directly though. The filters are extra work of course but it's work that's already being done if you're running really high sample rates. The issue is that to actually do anything with the additional HF information, we'd have to either run additional FFTs on top of that, or run bigger FFTs across the board to preserve our target time windows, or just run the same decimations and FFT sizes that we use for normal audio sampling rates and accept the hit on the LF resolution and time window sizes, as we did in SmaartLive 5 and Smaart 6.

But since none of those are terribly attractive options and there's no really good reason to do it in the first place, we decided just not to do it. We provide downsampling for higher sampling rates as a convenience, so that you don't have to keep switching SR's in case you actually do have some good reason to want to run your inputs at 96k (or whatever) for other types of measurements. Most people don't of course, but there occasions when its actually useful and in any case, it's not our place to judge.

PhillipIvanPietruschka
November 24th, 2010, 06:53 PM
With v7.1 we improved magnitude thresholding for MTW. The HF crossing threshold before the LF is no longer the case. All freqs are now virtually crossing at the same time.

Big Improvement. Thank you!

Michael Häck
December 23rd, 2010, 09:50 AM
Hello Everyone,

Only for the pleasure of to investigate, with the help of a good friend, and with the invaluable help of the trace of coherence, I think MTW uses 6 different sizes of FFT.

10KHz to 20KHz = 256 FFT
1860 Hz to 10 kHz = 1024 FFT
560Hz to 1860Hz = 4096 FFT
280Hz to 560Hz = 8192 FFT
140Hz to 280 = 16384 FFT
10 Hz to 140 = 32768 FFT

I hope not to be too wrong.

Greetings

Hi Pepe,

interesting post. I´m wondering about your formular: 256FFT 1.06ms=20% Coherence to TC 5,333ms. How was your measurement-rig for the examples you did in the screenshots ?

merlijnv
January 17th, 2011, 09:24 AM
We chose, as our default, to use multiple time windows as we had done in the past. So . . . the next question was, what should the TC's be. In the past, we were confined to a short list of "power of 2" FFT/TC sizes. Now here in the future (where I hear everyone is gonna wear 1-piece jump suits) we can easily and efficiently use virtually any TC size. That meant we could choose our TC's with our focus on the resulting frequency resolution and the impact of the TC on our classification of reverberant energy. (What is signal, what is noise?)

Hi Pepe,

AFAIK your FFT sizes might arguably be in conflict with Jamie’s explanation of MTW. I’ve come to the following conclusion (see attached image) at 48 kHz, assuming that all frequency points are shown when magnitude smoothing is turned off.

Regards,

Merlijn

merlijnv
April 18th, 2012, 07:14 AM
We chose, as our default, to use multiple time windows as we had done in the past. So . . . the next question was, what should the TC's be. In the past, we were confined to a short list of "power of 2" FFT/TC sizes. Now here in the future (where I hear everyone is gonna wear 1-piece jump suits) we can easily and efficiently use virtually any TC size. That meant we could choose our TC's with our focus on the resulting frequency resolution and the impact of the TC on our classification of reverberant energy. (What is signal, what is noise?)

Hi Pepe,


Sorry for taking so long. I’m not familiar with your way of calculating FFT’s, I’ll try to delve into it and make myself understand. Hopefully we’ll arrive at the same conclusion.

For those who are new to this thread, it’s an attempt to figure out the FFT’s used by SMAART’s MTW process. Pepe’s approach is by means of coherence and my approach is by using the frequency resolution or step size between data points, assuming SMAART show’s them all, with all smoothing turned off. The controversy seems to be that SMAART 7 is one of few or maybe AFAIK even the only dual-FFT analyzer that abandoned conventional power 2 FFT’s and choose, at their discretion, their own FFT sizes. This is clearly explained in Jamie’s OP, of which I included a quote at the top.

Over a year ago using the mouse cursor, I literally went over either magnitude or phase trace with all smoothing turned off to make note of the increment in frequency from one data point to the next one. I used these values as a starting point for my assumption of SMAART’s FFT sizes, and these seem indeed to abandon the conventional power 2 series of FFT’s. Today by means of the “Copy to ASCII” function SMAART allows you to “apparently” copy “all” 806 raw data points into i.e. Excel. Now it’s very easy to acquire the step size or frequency resolution, simply by subtracting the frequency of a data point form the next one in line. This leads to the same frequency resolution I found a year ago, doing it the visual way. And yet there seems to be a discrepancy between Pepe’s and my way, hence the ongoing thread.

I’ve included a screenshot of my Excel file of a random SMAART trace (I'm only interested in the frequencies) to give you an idea of the process. The first 4 columns are the original data pasted from SMAART, the rest is added by me.


Regards,


Merlijn

adam
April 18th, 2012, 09:51 AM
This is my favorite thread by far. I truly enjoy the discussion and find the methods used to reverse engineer MTW quite interesting. I won't divulge the process (what fun would that be?) but I will say that nobody has nailed it, yet. Though some of the suggested solutions would more or less yield the same result. And I suspect that most people find the result more interesting than the process. So from that perspective, you've done a fine job at analyzing the result. Thus gaining a better understanding of what the trace is depicting.


-A

merlijnv
April 18th, 2012, 02:14 PM
Ok I'll bite. Assuming that resolution and time constant is the goal. Different FFT's at different sample rates give identical TC's. By that I mean that TC is the division of FFT over sample rate which can be a reciprocal relation like time vs. frequency. So the question becomes, as to the process, which FFT's are used at what sample rates for which part of the spectrum. To be continued...

merlijnv
April 19th, 2012, 02:08 PM
Without getting into the exact numbers here (which we have no intention of publishing - but if you are handy with the math, we're confident you can derive the numbers yourself ) we chose the TCs in our new MTW process so that we have >48th octave resolution above 60 Hz, and 1 Hz resolution below 120 Hz. (The math is pretty is pretty easy for figuring that lowest TC )

Hi there,

So this is the part where I start wildly guessing. My calculations where based on the assumption that one sample rate was being used. Adam’s response clearly suggests otherwise. According to him, I’m looking at a picture. I should think about the process being used, not the outcome. Jamie’s OP stating that there’s 1 Hz resolution below 120 Hz, is IMHO simplified, in contrary to the “ simple math”. I suspect that MTW works slightly different for 44.1 kHz and 48 kHz. The way I read it, Adam acknowledges the assumption that, the step size I took from the ASCII information is correct. Not the FFT sizes, which leaves one variable, sample rate. Also after thoroughly going through the entire thread again, there’s mention of different sample rates for filter purposes. Being way out of my league, I reasoned that maybe use was being made of undersampling or bandpass sampling. AFAIK 1 Hz resolution equals a time constant of 1 second, regardless of the sample rate. In both 44.1 kHz and 48 kHz MTW’s, this doesn’t fit. Also according to the ASCII information, both MTW’s cross over between those pass bands at a frequency around approx. 140 Hz. This was misleading a first, unless I am wrong. With no way of telling which sample rates are being used, it made sense that they would be fractions of each other. The only lead I had, are the sample rates supported by SMAART. Which are 96000, 48000, 44100, 32000, 22050, 11025, 8000, 5512 and 4000 Hz. 32000, 8000 and 4000 are fractions of 48000, respectively 2/3, 1/6 and 1/12. 22050, 11025 and 5512 are fractions of 44100, respectively 1/2, 1/4 and 1/8. Using those values as a staring point, I started re-examining the frequency resolutions. I quickly realized that for the various pass bands, multiple sample rates using different FFT sizes resulted in the same time constants. Also the overlap at different sample rates in each pass band alone is relatively big, taking Nyquist into account. It seems MTW allows you to choose crossover frequencies for pass bands and sample rates separately. The pass band crossover frequencies structurally don’t coincide with any sample frequency change or a fraction of those sample frequencies. In other words it looks like multiple FFT’s are being used at different sample rates within some pass bands. I couldn’t find any clues either visually or in the ASCII information, that indicate the crossover points being used for changes in sample rate. Which left me with no alternative than to use Nyquist as a guideline. I’ve included a screenshot of my Excel file, where you can see 2 tables for 44.1 and 48 kHz MTW. The letter N in the last column stands for Nyquist, indicating a change in sample rate within that specific pass band. I’m out of ideas and most likely out of my league. But like Adam said, I tried to figure out the process.


Regards,


Merlijn

merlijnv
April 20th, 2012, 04:34 AM
Sorry,

I stand corrected, it would be downsampling and/or decimation, like Pepe already said, instead of undersampling or bandpass sampling. In the case of 44.1 kHz all factors are integer. For 48 kHz 32000 Hz seems to require resampling. 8000 and 4000 Hz are the results of integer factors again. I assume that in both scenarios at the end of the line, everything needs to be upsampled or interpolated back again to the original sample rate. Again assuming only the sample rates in my previous post are being used.

Regards,

Merlijn