REW Beta Release REW API beta releases

Builds updated today (beta 107) with these changes:
  • Added: Interface supports French
  • Changed: The siggen.properties bundle has additional entries for output level calibration
  • Changed: Add jdk.accessibility to the runtime
 
Hi

I have measure so SNR is mostly over 60 db. Can see in screenshot the calculated T60 values are more or less diffrent to real T60 values measured. maybe when SNR is over 60 db can use the real value that is in measurement at -60 db ?

you can see here how diffrent the real to calculate RT60 values are

188 T160.jpg


t60 51 hz.jpg


In the 51 hz slice there is show noise -50 db. but when look at the curve it is -55 - -56 db. also in the following is noise less than -61.4 db



t60 288.jpg


Is it possible with the API that there is every 1-2 sec a measure done at a frequency i need reduce reflections, for example 180 hz. usefull to walk thru room with basstraps or big basotect plate in hand and and see which place give the linearest decay. can hear with headphones. even if they are very diffrent in frequency response after short hear all sound great. so i hear and notice most important is to reduce this unlinear decay as can see ~180 hz with basotect basstrap placement or basotect placement and look that RT60 is simular after EQ too. I notice often EQ sound more worse but FR is good. because when boost frequency the decay time also increase this i think let sound the real EQ settings worse and give strange feeling in ears as when switch polarity of 1 speaker . foam do not much with FR. only can change Decay time of reverb good. and reduce decay time make sound lots better
 
Last edited:
Can see in screenshot the calculated T60 values are more or less diffrent to real T60 values measured.
T60 values as used in acoustics are defined by the slope of the decay curve, as set out in ISO3382, with an underlying assumption of a diffuse soundfield. That assumption breaks down at low frequencies in small spaces, but that doesn't mean that REW can arbitrarily redefine the meaning of the measure. The problem is not the calculation, but your use of RT60 in a frequency region and environment where it is not applicable.
 
I think the latest Beta may have a bug in convolution generation (was not a problem a ~month ago) - when exporting stereo as filters impulse response as wav both L/R channels are identical. My speakers are not identical so I always EQ them separately and now it stopped working. I can still generate 2 separate mono wav files, no bug there.
 
T60 values as used in acoustics are defined by the slope of the decay curve, as set out in ISO3382, with an underlying assumption of a diffuse soundfield. That assumption breaks down at low frequencies in small spaces, but that doesn't mean that REW can arbitrarily redefine the meaning of the measure. The problem is not the calculation, but your use of RT60 in a frequency region and environment where it is not applicable.

currently it is a version of ISO 3382-3 from 2022 . original ISO 3382 is very old, i dont know what they change in newer version, maybe the calculation ? https://www.din.de/de/mitwirken/nor...dc-beuth:din21:345469066/toc-3338603/download and here is the german page(can translate in browser) which contain previous link


this is the -2


this is the -1


ISO and DIN is same, seem the ISO is come from germany DIN and accept in ISO
 
Last edited:
John, when I look at the distortion tab for the downloaded FSAF measurement file, and the TD+N graph is displayed, there is an option to change the maximum number of harmonics displayed in the THD. If you change this digit up or down from the current number, a Java exception occurs.
 
Currently, to generate a measurement from the target shape, we’re forced to use an existing measurement in order to send the command:

POST /measurements/{id}/eq/command → "Generate target measurement"

Sometimes, no measurement exists yet. That’s why I’d like to be able to trigger this command directly from the EQ block of the API (for example):

POST /eq/default-house-curve/commands → "Generate target measurement"

This action is already possible outside the API via the application’s user interface, so it would be great to have an endpoint that exposes the same functionality.
 
The next build will support POST /eq/command → "Generate target measurement" to generate a target response from the default settings.
 
Retina Display Rendering Issue in REW on MacBook M1 Pro
Hi there,

I’ve been experiencing an issue with REW on my MacBook M1 Pro 16-inch, running macOS Tahoe 26.1. The problem is that REW doesn’t render properly on my Retina display — everything looks blurry, including fonts and lines.

At first, I thought it might be an issue with my operating system. So, I did the following:
  1. I installed a fresh version of macOS Tahoe 26.1.
  2. I reinstalled REW on this clean setup.
  3. Unfortunately, the problem is still there, and REW continues to display poorly.
I’ve attached a screenshot for reference.

I would appreciate any help or advice on how to fix this!

Thanks in advance!

View attachment 87791
Hi Jacky

i am your fb friend 林佑叡(carsound Lin),did you update to 106 or 107,john have change java runtime,maybe can fix you display bug.
 
Builds updated today (beta 108) with these changes:
  • Added: The installer offers a language selection which will be used for REW unless the View preference to use English overrides it
  • Added: The View preferences have a "Frequency band style" entry to choose a musical or Bark scale
  • Added: There is an /eq/command API endpoint that accepts a "Generate target measurement" command to generate a measurement from the default target response
  • Fixed: Altering highest harmonic in THD for an FSAF measurement caused an exception
  • Fixed: When using loopback as cal and timing reference and merging the loopback response to the IR the MTW Analysis preference was not applied
 
Hi John, in the RTA view, the display will grey out the frequency range outside of the low pass and high pass range defined in the distortion settings. Would it make sense to only grey out the out of band range when "show distortion" is selected? Currently the area is greyed out at all times.
 
Ok, no problem. Another minor bug, when the graph scale is set to Volts, Volts/sqrt(Hz), or W, I am unable to type in the limits boxes to adjust the high and low graph limits. Up/down arrows are the only way.
 
Last edited:
That's expected, the limits are changing in dB steps that get converted to a Volt (or other linear) figure for display, arbitrary linear unit figures aren't accepted.
 
I honestly think arbitrary scaling range should be avoided regardless of whether the scale is dB or linear units, it should be a defined span, which is why I often use manual entry to define it. As far as a UI goes, the text box implies that user entry is allowed, and even an "allowed" entry is not accepted. Perhaps an improvement would be to allow user entry in the text box, and round the input to the nearest "accepted" scale range. Otherwise, my other suggestion would be to grey out the text box to disallow user entry.
 
As far as a UI goes, the text box implies that user entry is allowed, and even an "allowed" entry is not accepted. Perhaps an improvement would be to allow user entry in the text box, and round the input to the nearest "accepted" scale range. Otherwise, my other suggestion would be to grey out the text box to disallow user entry.
The component doesn't allow values that aren't in the list it is generated from. If it is made editable it has very restrictive behaviour to prevent anything that isn't in the list being entered, that's why I decided to make it not editable. I can also prevent the text from getting focus, but greying it out would be wrong as that would imply it is disabled. The fastest way to change those values is with the mouse wheel.
 
Ok, fair enough. Scroll wheel is great for adjustment here, until I try it for SPL, the step is an odd value, and there appears to be rounding error, so scroll down then back up won't arrive at the same value. Scrolling to the nearest 5dB division would make the most sense to me. Same can be said for X axis for frequency, the steps for scrolling are quite odd, and scrolling up and down doesn't arrive at the same numbers, it feels like a random number generator. For this reason I've always used manual entry, which threw me off when I tried using RTA with voltage scale. Sorry, I know this is nitpicky stuff.
 
Added: There is an /eq/command API endpoint that accepts a "Generate target measurement" command to generate a measurement from the default target response
Is there any difference from the old endpoint:

curl -X POST "http://localhost:4735/measurements/1/eq/command" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"command\": \"Generate target measurement\", \"parameters\": [75]}"

except for not needing a measurement number?
 
I am trying to save EQ filter data in rePhase format but am getting an error message.

Screenshot 2025-11-30 at 8.03.44 AM.png

This occurs on both a Mac Mini M4 and a MacBok Air M2 both running Tahoe 26.1. REW v5.40 Beta 108
 
Back
Top