REW 5.40 beta 116 – Trace Arithmetic merge NF/FF not working correctly

[spyros-]

Hello,

I am using REW 5.40 beta and I believe there is a bug with Trace Arithmetic → Merge when merging near-field and far-field measurements.

Here is the exact issue:

• I have two measurements:
  
  • A = far-field (FF)
  • B = near-field (NF)
• I first do Align SPL successfully (the curves match correctly in the overlap region).
• Then I use Trace Arithmetic → Merge B to A at a frequency within the overlap.

Result:
The generated trace is identical to the far-field measurement (A).
The near-field data is not included at all.

However:

• If I reverse the order:
  
  • A = near-field
  • B = far-field
  • Merge A to B

The result follows only the near-field trace.

This suggests that in REW 5.40 beta, the merge operation always keeps trace A and ignores the merge logic.

I tested the same workflow in REW 5.31.3, and the merge works correctly there.

Best regards,

My setup:

• NF and FF both have valid overlap
• Levels are aligned with Align SPL
• Blend on/off makes no difference
• Issue is fully repeatable

Can you please confirm whether this is a known issue in 5.40 beta?

Thank you for your work on REW.

 

[John Mulcahy]

Can you please confirm whether this is a known issue in 5.40 beta?

It isn't. Please attach an mdat with the measurements you are merging.

 

[spyros-]

Hello John,

I have attached the MDAT file with the two measurements:

• Far-field mid-range
• Near-field mid-range
• The same MDAT merges correctly in REW 5.31.3

Thank you for taking a look.

Best regards,
Spyros

 

[John Mulcahy]

Seems fine to me. Note that you do not need to align SPL, merge does that automatically at the merge frequency.

 

[spyros-]

I found the cause: merge works only if FF has no IR windows applied.
If IR windows are applied to FF before merging, Merge B to A keeps only FF.
In REW 5.31.3 this worked correctly.
So it seems IR-windowed FF breaks merge in 5.40.116 beta.

 

[John Mulcahy]

It is still working, the bug is that it is defaulting to the measurement A windows for the result when it should be using measurement B. I have fixed that for the next build, but you can simply change the windows on the result.

 

[spyros-]

Hi John,

Thank you for the clarification.
That explains the behaviour perfectly.

I’m glad I could help identify the issue and confirm it on my side.
Looking forward to the next build.

Best regards,
Spyros