REW Trace Arithmetic issues

[RobertTheBruce05]

Hello,

I'm having issues with the "Trace Arithmetic" control, specifically the "Merge B to A" option. When I try to merge the two SPL measurements I'm not getting the full response in the new frequency response that's created. Im trying to combine a far field measurement (with IR Window applied) that is 217- 20,000 Hz and a corrected near field measurement that is 20-20,000Hz. However when I try to combine the two measurements the newly created response only goes down to 217Hz instead of all the way down to 20HZ.

Ive attached a screenshot to help visualize.

Any help would be greatly appreciated. I just cant seem to figure out what the issue is...

 

[John Mulcahy]

Try the V5.20.14 early access build, it has a fix for merge when the A measurement has a high start frequency.

 

[RobertTheBruce05]

Thanks for the reply, but unfortunately I had the same result.... I loaded the saved files from version 20.13. Also, I attempted on a Mac should I try the Windows build? Is there anything else I can do?

Is there an older version of REW I should try?

 

[RobertTheBruce05]

Update, same result in windows build. Still producing a result with an IR. Thoughts?

 

[John Mulcahy]

Please attach an mdat file with the measurements you are trying to merge.

 

[RobertTheBruce05]

After consulting with a friend he discovered a solution to the merge problem. One of the measurements (Corrected Near Field) was edited in Excel and then imported into REW so it did not have a impulse response. After applying the generate minimum phase function to the (Corrected Near Field) measurement it allowed the two measurements to be merged successfully. This shifted the SPL but did not effect my desired result.

I also experimented a bit and found that REW v19 allowed the merge without having to generate a minimum phase to the measurement.

I've uploaded both files if you want to investigate further.

Thanks for your help, and your amazing Software/Dev skills!

 

[John Mulcahy]

The result is actually OK, you just need to increase the right hand IR window. Since only one measurement has an IR the window settings for the result were taken from that. I'll change the behaviour for the next build to take account of the lower frequency limit of the B measurement.

 

[John Mulcahy]

Left window also needs increasing for that data, I'll handle that as well in the next build.

 

[RobertTheBruce05]

Thanks again for looking into this! Can't wait to see/use future REW builds.

 

[u.froemberg]

I have problems with the trace arithmetic from time to time. Sometimes there are not understandable deviations from the expected results, sometimes shifts by 3 dB. To test the A/B operations, I generated simple data sets and tried some operations (with REW_macos_5_20_14ea69). With A = 0 dB and B = -1 dB, A/B should be +1 dB. For demontration I have attached a corresponding mdat file.

 

[John Mulcahy]

I have problems with the trace arithmetic from time to time. Sometimes there are not understandable deviations from the expected results, sometimes shifts by 3 dB. To test the A/B operations, I generated simple data sets and tried some operations (with REW_macos_5_20_14ea69). With A = 0 dB and B = -1 dB, A/B should be +1 dB. For demontration I have attached a corresponding mdat file.

Everything in that mdat is at 0 dB SPL as far as I can see, including the measurements labelled "-1 dB". Are you using the SPL axis?

 

[u.froemberg]

Yes, I used the SPL axis because SPL calibration was also important to me in the measurements and I wanted to perform SPL-true calculations. All measurements used are scaled in SPL.

 

[John Mulcahy]

Yes, I used the SPL axis because SPL calibration was also important to me in the measurements and I wanted to perform SPL-true calculations. All measurements used are scaled in SPL.

Perhaps I have misunderstood your question. The measurements you have labelled as -1 dB in your mdat are all at 0 dB SPL, as are the other measurements, and all the results of divisions of those 0 dB SPL measurements are also at 0 dB SPL, as they should be. What issue are you trying to highlight with that file?

 

[u.froemberg]

No, the misunderstanding was mine. The problem is myself. I had over 40 SPL calibrated, grouped measurements in the session and then needed relative comparisons between group averages at a reference frequency and so did SPL offsets. I was sure I had added the offsets to the data. Apparently the concentration has dropped or I have lost track, probably not for the first time and maybe I am not the first to whom this has happened.

This got me thinking and I would have a suggestion:

Since calibrated absolute values become invalid at offsets, I suggest to signal the status SPL-Offset ≠ 0 even more clearly, e.g. changed background color of the SPL offset, in the selection lists of the Trace arithmetic and trace display lists. Before executing the Trace arithmetic, a warning dialog could be opened at SPL offset ≠ 0 with the option to execute Add Data subsequently in this dialog or to accept invalid SPL values.

It is, of course, a trade-off between usability and higher program complexity.

What do other users say about it?