REW: export smoothed impulse responses (.wav), but "measured" and not "minimum phase"...

[John Mulcahy]

Impulse graph axis can be switched between % and dBFS via the dropdown in the top left corner of the graph.

 

[Stewix]

Ok, this is how it looks the actual measured (and not modified) R impulse of a Telefunken-M15, for example...

It looks more like an "acausal" one, but it is measured (real and not modified); so...why does it looks in this way?...

Only because it is not minimum phase?...

But this would bring me back to my question: how can I distinguish between a causal but not minimum phase response, and an "acausal" one?...

Sorry to be so "annoying", but I think I'm finally really close to understand the matter once and for all...

 

[John Mulcahy]

If the bandwidth of what you are measuring exceeds half the sample rate there will be some sinc-function effects, hard to tell if that is the case without seeing the mdat file. Does look very noisy, mind.

 

[Stewix]

Being a tape machine it is surely noisy (and we're not even talking about the crosstalk measurement!)...

Here is another (a lot cleaner) measurement: the left channel of an Api Eq (again, not crosstalk, that could be so low to cause some "strangeness"):

Again, it is somewhat similar to an "acausal" one...

Regarding the higher bandwidth: it could be, both regarding the analog piece and the converter used to record the sweep...

If you want I can post some .mdat if it is of help...

 

[Stewix]

PS: if the sweep (which was a 48k file) has been recorded throught a system working at 96k (which, of course, has applied a high quality sample rate conversion, both before and after the actual recording), do you think that is possible that these impulses are "exhibiting" this "acausal" look due to a linear phase upsampling and downsampling process?...

Shouldn't the conversion be practically transparent instead, being of a high quality?...

 

[Stewix]

Ok, I was curious to see if the 48k to 96k to 48k conversions were causing this, so I've done a test and I've created an impulse of an 1176 compressor directly at 96k (no conversions at all)...

As you can see the look is still similar to an "acausal" response:

What is going on?...

Oh man, I feel like, in an attempt to better understand the matter, I've opened a really awful can of worms!...

A lot of the impulses that I've created are like this!... What went wrong?... Am I "doomed" to use the minimum phase versions instead (saying somewhat "goodbye" to the "realism" of what I was trying to do)?...

Anyway, I've attached the last .mdat of the 1176 I've created...

Many thanks for your patience!...

 

[John Mulcahy]

Nothing is wrong. The bandwidths of the systems you are measuring are close to the limits of what can be captured at the sample rates used. Some of what you see is the response of the anti-alias filters in the system, which are often linear phase. Systems with a bandwidth close to the limit of the sample rate show sinc-like behaviour. Here's a site with a paper on sampling theory to explain that.

 

[Stewix]

Ok, thanks again!...

So, just to see if I got you correctly: the problem has to do with the anti-alias filters of the ad/da converters (and/or the SRC algorithm used), and not with the way the impulse response is "calculated" when imported...

I ask also because I still have the sweep recordings and the sweep tones (exported from REW) used to create them; so, if there were a different way to import the sweeps, I could try that...

But I think, if I got you correctly, that this is not the case: that "behaviour" is already "imprinted" in the sweep recordings...

And also, nothing to worry about... except from one thing: how can I distinguish then this specific "problem", from an "acausal" response?...

But I think I already have the answer for that (and I just ask for your confirmation): if the impulse is a "measured" one, and it is not modified in any way, it is obviously a matter of the anti-alias filters in the system (and, like said, nothing to worry about)...

On the other hand, if one is modifying the impulse in some way (for example "db + phase average", or "1/A", etc.), and then the impulse looks significantly more like an "acausal" one (compared to the one preceding the modification), then one has probably generated a "problematic acausality" (or at least a "more problematic" one, compared to the one already "imprinted" in the impulse, which is very minimal and nothing to worry about)...

Did I get all of this right?...

And thank you also for the link (useful papers from Lavry all in one place!)!...
Generally speaking I already knew this stuff, but I've briefly looked there and I think that there is the chance to go a lot deeper...

 

[John Mulcahy]

if one is modifying the impulse in some way (for example "db + phase average", or "1/A", etc.), and then the impulse looks significantly more like an "acausal" one (compared to the one preceding the modification), then one has probably generated a "problematic acausality"

Yes.

 

[Stewix]

Yes.

Many many thanks again!...

You have been awesomely helpful as per usual!...

 

[Stewix]

Hi!...

Sorry to bother again, but this time I'd really like to do everything in the "right way"...

I've still got a pair of merely "practical questions" on the matter...

As has already been said, the impulse which is the most "faithful" to the hardware is the one measured (and not altered)...

In the past I simply exported the impulses in their entire length (and cut in the convolution plugin appropriately); but now I'm taking advantage of the fact that, to preserve the relative time of different impulses, one can simply apply the same window (with the same ref time) to all of them, and then export applying this window...

But what about the "estimate IR delay" function? Considering that this changes the impulse phase, what can be considered the "most faithful to the hardware" impulse, the one shifted or the one untouched? Doesn't this "shift" also change the relative time of the impulse, so that it is better to avoid doing that if one wants to preserve things as they have been captured?...

Regarding my other question: I'm using REW also to convert the sample rate of some external impulses (for example from 48k to 44k, or vice versa), and I believe that it does a really good job at that...
In fact I've tried some null tests, between the original audio and that same audio "convolved" with a perfect impulse (previously converted); and, compared to other SRC programs, it always won...

Anyway, the question is: what is the best procedure to do that (and also, considering that it has been mentioned before, to import sweep recordings), to let the preferences at their default settings, and to not change things at all?...

For example, things like "IR oversampler" (maybe from "Windowed sinc" to "FFT time shift")?
My understanding is that these things are related only to the generation of the graphs; am I right?

But what about the "Truncate IR after..."?
I've tried, for example, to import an impulse response long around 4 seconds, and it has not been truncated, even if the settings were the default ones...

And last (but this is not a question, just an observation): I need some of these impulses to be minimum phase (regardless of them being no more "faithful" to the hardware); I've noticed that if I apply the same window (and ref time), and then export applying that window, the impulses peak doesn't reside at a millisecond that corresponds to the left window width as expected (and explained in the help)...

Of course I can easily work around that, I just wanted to mention it (as always, to better understand)...

Thanks again!...

And please, forgive my "prolixity"...

 

[John Mulcahy]

But what about the "estimate IR delay" function?

That only moves the IR, it doesn't change it.

I'm using REW also to convert the sample rate of some external impulses

REW is an OK oversampler but not on a par with commercial applications.

things like "IR oversampler"

That only affects graph generation.

what about the "Truncate IR after..."?

That only affects new sweep measurements.

I've noticed that if I apply the same window (and ref time), and then export applying that window, the impulses peak doesn't reside at a millisecond that corresponds to the left window width as expected

That would suggest the ref time was not at the peak.

 

[Stewix]

REW is an OK oversampler but not on a par with commercial applications.

I've compared it to the convolution plugin that I use while mixing, and also to a free/demo (considered good) program...
Now, it is possible that my test was flawed in some way (I don't think so, as far as I can tell), but the point is: it gave me always the "highest null"; sometimes just a little better, other times a lot better...

While we are at it: (talking about the IRs generated with REW) do you think that converting the sample rate while exporting the IR without applying the window (or applying a window that corresponds to the whole length of the IR), then importing again the converted IR, and only then exporting while applying the window, can give a better result compared to directly exporting/converting while applying the window?...

EDIT: just to avoid to spread misinformation I've redone some tests; and, on one hand, I can confirm that for downsampling REW outperformed the other options I've tried (but one has to apply a window while exporting/converting: REW seems to do a better conversion in this way, also when upsampling)

On the other hand, regarding upsampling all the programs did a similar job, with the convolution plugin I use "winning" by a slight margin....

I've tried only conversions from 44k to 48k and vice versa, not from or to 96k or others...

Anyway, I encourage whoever reads this to do their own tests...

That only affects graph generation.


That only affects new sweep measurements.

Ok, perfectly clear; thanks!...

That would suggest the ref time was not at the peak.

I think I get what you are saying; I'll check that...

That only moves the IR, it doesn't change it.

So, if I'm exporting four IRs, which have been measured using the same ref time (the one of the sweep generated by REW), and I want to maintain all the relative delays of the system measured (even if very small, for the usual "faithful to the hardware" purpose), does this means that, in this case, is better to avoid that "shift"?...

Man, I really feel like I'm abusing your time and kindness, sorry about that!...

 

[John Mulcahy]

do you think that converting the sample rate while exporting the IR without applying the window (or applying a window that corresponds to the whole length of the IR), then importing again the converted IR, and only then exporting while applying the window, can give a better result compared to directly exporting/converting while applying the window?

Hard to say, probably easiest to just try it.

If you want to preserve relative timing then avoid moving any individual IR.

 

[Stewix]

Hard to say, probably easiest to just try it.

Ok, I'll try that then...

If you want to preserve relative timing then avoid moving any individual IR.

Perfect, thanks. Which leads to my last question (finally)...

Let's say I've got 4 measurements/impulses: let's call them A, B, C, and D...
Let's say that I want to preserve the relative timing between A and B; and that I want to do the same between C and D...

But that, at the same time, I want to time align A and C instead...

My reasoning tells me that I need to do the following:

1) Make sure to apply the same window and ref time to A and B.
2) Make sure to do the same for C and D.
3) Make sure, at the same time, to apply the same window to A and C, but to keep their own ref time untouched...

Is this right?...

 

[John Mulcahy]

Use the offset t= 0 controls to move both C and D by the time required to align C with A.

 

[Stewix]

Use the offset t= 0 controls to move both C and D by the time required to align C with A.

Ok, thank you!... But...

1) How do I know the exact time required to align C with A? Do I have to look at "Cumulative shift", in the "Offset t=0" controls, and make them identical (of course taking care to move also D by the same amount)?...

2) After that, can I simply apply the same windows to all so that the relative timings, plus the now aligned A and C, will be kept?...

---------------------------------

On an unrelated note (still related to the OP), I'm a bit embarrassed but I forgot to ask a really simple (but important) question...

If I apply some EQ curves (within REW) to a measurement/impulse, for example with "Export EQ filtered IR" (or "Generate measurement from predicted" in the EQ section), do I risk once again to end up with an "acausal" response, or are those EQ filters "immune" to this?

Yes, I can look at the impulse (as I did); but starting with an impulse which is already somewhat looking like an "acausal" one makes it a bit difficult to tell...
So if there is, at least in this case (regarding the filters), a theoretical "black or white" answer, it would be great to know...

 

[John Mulcahy]

How do I know the exact time required to align C with A?

You could look at the difference between the figures produced by Estimate IR delay for each of them, or you could look at the difference between their individual delay figures if they were both measured with the same timing reference.

are those EQ filters "immune" to this?

EQ filters are causal and minimum phase.

 

[Stewix]

EQ filters are causal and minimum phase.

Ok, good: as I was thinking using them shouldn't generate an "acausal" response, just like when mixing and using a minimum phase EQ...

You could look at the difference between the figures produced by Estimate IR delay for each of them, or you could look at the difference between their individual delay figures if they were both measured with the same timing reference.

If I'm not wrong the second method is more "precise", right? Anyway, I used the same sweep, which contained also a Time ref...

But the measurement went as follows: the first sweep went through the left channel, while I was recording both the left and the right channel (the latter for the crosstalk response); and then the second sweep went through the right channel, to do the same but inverted...

So I guess that only the left channel and the right channel crosstalk have the same timing reference (and also, vice versa), but not the "normal" left channel with the "normal" right channel, right?...

Oh, and by the way, where can I look at their individual delay figures?...

Just to clarify: I know that in this case all these respective delay times are so small that they'll probably end up at the same sample anyway, but all these concepts are still important to understand, for example when one wants to create "true stereo sets" of a room response (aka left and right speaker into both left and right mics: 4 impulses): in this case those delay figures are bigger (but I guess that, if one pays attention to play the same ref time always through the same speaker, then applying the same windows to all is enough to preserve their "realistic" relative timings)...

PS: just out of curiosity, considering that "Apply to all, keep ref time" does not serve this specific purpose (align the peak of two impulses), what does it do exactly (I think I'm maybe confusing the "t=0" and "ref time" concepts)?...

 

[Stewix]

Ok, I've done some tests applying some arbitrarily chosen delay time with a plugin in my DAW, and I've come to the conclusion that I was still misunderstanding the way that Time Ref actually works...

For example, if I record two impulses responses of a room with a speaker and two mics (or two different mic positions), even if the Time Ref signal is being played by the same speaker, those two impulses won't share the same Time Ref: in fact, in the case of the second mic (position), that Time Ref is going to be shifted together with the sweep recorded (correct me if I'm wrong, of course)...

And this same problem I think affects also the "normal vs crosstalk" sweep recordings of analog gear I've done (looking at the way I've done them)...

But I think I've come to a "solution" to work around that: align in my DAW the sweep generated by REW with the sweeps recorded, and copy-past only those brief Time Ref signals (generated by REW) to the analog recorded sweeps, keeping the alignment between these "pasted" and "copied" signals; then, of course, export the results to import them in REW...

Anyway, I'll wait for your answers to the questions in my previous post (and eventual corrections to this), because I think you can shed some more light on this...

This has been an unexpected, even if interesting, "rabbit hole" for me; and I've would have been lost without you...

I hope that at least this thread could be of help for those of us that use REW for these kind of "unusual" things...

 

[John Mulcahy]

The timing reference establishes the position for t=0.

The reference time for windows (which is used to position the windows) can vary, it is usually at the peak of the IR. If you want to export windowed responses to preserve relative delays you need to make sure the windows start at the same time. That is done by making sure they all have the same left width and they all have the same window reference time.

 

[Stewix]

The timing reference establishes the position for t=0.

The reference time for windows (which is used to position the windows)

Ok, you're clarifying that the "timing reference" (contained in the measurements) and the "reference time for windows" are actually two different things...

The reference time for windows (which is used to position the windows) can vary, it is usually at the peak of the IR.

Ok, I think I get it: that's for the fact that it can vary that it is not necessarily true that, to align different impulses, is enough to keep their own respective ref time (as they are "automatically calculated" by REW), while also making sure that they have the same left width, right?...

If you want to export windowed responses to preserve relative delays you need to make sure the windows start at the same time. That is done by making sure they all have the same left width and they all have the same window reference time.

Yes, this is something I had already figured out...

What I was misunderstanding, but find out with some tests, is the way one should record the sweeps so that they are actually measured (recorded) with the same timing reference...

For example, one speaker and two mic positions is not going to work (I thought it could); while two speakers and one mic position can work, if one plays back the timing reference signal always from the same speaker (also when the sweep to record/measure is played back by the other speaker).

Anyway, I think that, thanks to your explanations, and also to some tests I did on my own, all is clear now...

I was trying to understand the initial "cumulative shift" of measurements, but then I find out a thread where you explained it ("the cumulative shift figure comes from fractional sample adjustments that were made to align with the timing reference")...

My only remaining question is: what's better, regarding the EQ filters, to "Export EQ filtered IR", or "Generate measurement from predicted" and then export that?...

 

[John Mulcahy]

what's better, regarding the EQ filters, to "Export EQ filtered IR", or "Generate measurement from predicted" and then export that?

Should give the same result.

 

[Stewix]

Should give the same result.

Thank you again!...

To conclude: what can make REW not put the window ref time at the impulse peak?
Maybe a measurement with a poor sound to noise ratio?...
Or what else?...

 

[John Mulcahy]

what can make REW not put the window ref time at the impulse peak?

REW always puts the ref time at the peak, but you may change it afterwards.