API phase differs from text export

Hi John,

I am creating several AI agents to retreive REW data, and make some useful observations about the measurements. Basically I am a home studio/audio enthousiast with a programming background, and I wanted to see if it was possible to have an AI driven acoustic advisor available for my own home studio advantures. That said, I am no acoustician by any means, allthough I really enjoy reading and researching this topic.

That said, my development has hit a bit of an issue. It seems I (or rather my AI friend) can not validate that the phase of a measurement if I compare the directly exported version from REW (in text) vs. the API data.

As my agent puts it:

---- [AI generated - start] ----
I’m validating REW’s new API against REW text exports and have encountered a phase difference that I would appreciate some help understanding.

Environment:

• Windows 11
• REW 5.40 Beta 129
• API version 0.9.5
• Measurement originally made with REW V5.31.3
• Original measurement: 512k log sweep, four sweeps, 44.1 kHz
• No acoustic timing reference

I loaded the measurement into REW 5.40 and retrieved its frequency response through the read-only API at 96 PPO with smoothing requested as None.

I understand that converting a response to 96 PPO results in an effective 1/48-octave representation even when the requested smoothing is None. The API metadata correctly allowed us to identify that behavior.

To validate the API arrays, I exported the same measurement from REW using:

• Export measurement as text
• Full measurement range
• 96 PPO
• Explicit 1/48-octave smoothing
• SPL and phase included
• REW number format

I obtained an export whose frequency axis matched the API response directly:

• 956 API rows
• 956 export rows
• Start frequency: 20.187378 Hz
• Maximum coordinate difference: less than 0.5 µHz
• No interpolation or excluded rows

The SPL results match extremely well:

• Median absolute difference: 0.000252 dB
• RMSE: 0.000286 dB
• 95th-percentile absolute difference: 0.000474 dB
• Maximum absolute difference: 0.000503 dB

This appears to confirm that the API magnitude payload and decoding are correct.

The phase does not match in the same way. Using circular phase differences on the identical frequency coordinates:

• Median absolute difference: approximately 0.955°
• RMSE: approximately 31.4°
• 95th-percentile absolute difference: approximately 81.0°
• Maximum absolute difference: approximately 180°

The large differences are sporadic rather than a simple constant phase or time offset.

I also exported the native, linearly spaced response with no smoothing:

• Frequency step: approximately 0.336456 Hz
• 59,384 rows
• SPL and phase included

We unwrapped that dense phase response and interpolated it onto the exact API frequency coordinates, rejecting ambiguous wrapping intervals and checking interpolation sensitivity. The API phase did not match that representation either:

• 914 of 956 API points passed the interpolation-stability checks
• Median absolute circular residual on those points: approximately 3.77°
• 95th percentile: approximately 56.0°
• Maximum: approximately 160.4°

At this point I am not assuming an API decoding bug. The data suggest that the API and text-export paths may use different phase-processing or representation semantics.

Could you clarify the following?

1. When <span>/measurements/:id/frequency-response</span> is requested with <span>ppo=96</span> and smoothing None, what processing is applied to the returned phase array?
2. Is the API magnitude converted to the effective 1/48-octave representation while phase is produced through a different path?
3. Should API phase be expected to match an axis-matched 96-PPO, 1/48-octave “Export measurement as text” phase response?
4. Do the API and text-export paths differ in their treatment of impulse t=0, estimated IR delay, phase wrapping, IR windows, or smoothing?
5. Could loading a measurement created in REW V5.31.3 into REW 5.40 affect the relationship between API phase and exported phase?
6. Is there a recommended API request or text-export configuration that should produce numerically equivalent phase arrays?
7. Is the group-delay API response derived from the same phase representation returned by the frequency-response endpoint, or through a separate calculation?

---- [AI generated - end] ----

I’m happy to provide the measurement, API response, exports, comparison script, exact residual coordinates, or screenshots if any of those would help.

The practical question is which REW representation should be treated as authoritative when API phase and a properly settings- and axis-matched text-export phase disagree.

Thanks for any clarification—and thank you for adding the API. It is already proving very useful for automated and auditable measurement workflows.

Cheers,
Bastiaan

If you email the mdat file to feedback@roomeqwizard.com along with a screenshot of your text export settings I'll take a look.

I've send it over. Thanks for checking.

I think the difference arises from the way the API is trying to handle a requested smoothing of None and 96 PPO. Try setting the API smoothing to 1/48. I'll get the API to handle that automatically in the next build.