REW Beta Release REW API beta releases

[sm52]

Thank you. I tried this option.

 

[John Mulcahy]

Builds updated today (beta 32) with these changes:

• Added: FSAF measurement method
• Added: Support for importing Flac and MP3 files
• Added: Signal generator has a musical note selector
• Changed: If an error occurs when using the alignment tool via the API the response will be the error message rather than a result with zero delays
• Changed: Increased timeout for blocking API calls to 30 seconds
• Fixed: Using alignment tool through the API might produce zero alignment result
• Fixed: Spectrograms for imported audio data may not have started at t=0
• Fixed: Peak finder copy button did not work
• Fixed: Impulse response import did not use the Analysis preferences default width for the left window
• Fixed: Legend area right click popup could be dismissed by mouse wheel
• Fixed: Null pointer exception when clicking on a colour of the default trace colours in the View preferences
• Fixed: RTA was not correctly processing multi-channel WAV files
• Fixed: RMS+phase and dB+phase averages of measurements whose IRs start at 0 seconds had left window set to zero
• Fixed: Filter panel gain spinner buttons stopped working for negative gains in Macedonian locale
• Fixed: Camilla pipeline format was incorrect
• Fixed: Trace arithmetic 1/A with no gain limiting had incorrect Nyquist level

The big addition is measurement with FSAF, Fast Subband Adaptive Filtering. The FSAF process was developed by by Michael Tsiroulnikov aka Michael Zrull. See Michael Tsiroulnikov (2022). Loudspeakers for AEC: Measurement and Linearization, MATLAB Central File Exchange. FSAF measurement allows total distortion + noise (TD+N) to be measured for any test signal, including clips of music. REW's implementation of FSAF allows measurement with noise signals (white, pink, brown) or a section of a file, which can be WAV, AIFF, Flac or MP3. Help for FSAF measurement is here.

FSAF measurement works very well, but there is an important caveat: the process is very sensitive to clock rate differences and clock rate stability. The best results are obtained when using the same audio interface for both output and input, so there is only one clock source. If the input and output devices are different REW can use timing markers before and after the measurement signal to apply clock rate correction. Even with rate correction applied the results are heavily affected by the stability of the clock sources. USB microphones which rely on the USB clock are not suitable for FSAF measurement as the USB clock is not stable. That means, for example, UMIK-1, UMM-6 and Omnimic are not suitable for FSAF measurements. It is possible to use a USB mic which has an internal clock source, such as UMIK-2.

For discussion of FSAF use this thread.

 

[SantaGMO]

Is this the place to get help with REW API? I'm writing a script and I'd like to get the resulting measurement from an 'Arithmetic'. Is there a way to do this?

 

[John Mulcahy]

There are links to API help in the first post of this thread.

 

[SantaGMO]

I have been reading them and can't find what I want. But I will keep reading

 

[John Mulcahy]

The result can be read from here:

It will be a new measurement so the endpoints to get the frequency response or impulse response of a measurement would be used to access the data.

 

[SantaGMO]

Thanks, John. This is wonderful. I was using process-measurements instead of result so it wasn't working for me.

 

[navid0308]

Q - on beta 31 and earlier, when importing raw audyssey impulse measurements (when using the audyssey one script), they would hover around 120db. on beta 32 it seems to hover around 60db. the actual measurement level of these sweeps are closer to 75db. how exactly does rew determine the spl level?

 

[John Mulcahy]

There isn't a way to know what the SPL was for imported measurements. There was a change in beta 32 to the handling of imported data, I'll change that back for IR imports in the next build.

 

[navid0308]

There isn't a way to know what the SPL was for imported measurements. There was a change in beta 32 to the handling of imported data, I'll change that back for IR imports in the next build.

Alright. I use this tool called ratbudyssey to view the raw audyssey measurements and that usually gets the spl level spot on. I tried to post the link to my impulse responses as well as the git repo for ratbuddyssey but since I'm new here, it doesn't let me. Added screenshots below.

So far my finding has been speakers are coming in ~15db too low and the sub is coming in ~5db too low. The differences between the channels are also inconsistent compared to before, i.e. if FL is 5db louder than C, using beta 32 puts both their impulse response spls at roughly the same value.

 

[John Mulcahy]

Beta 33 uploaded with this fix:

• Fixed: Some impulse response imports had different SPL offset with beta 32

 

[Dr.OP]

Thank you John for the excellent tool!
I wonder if there is a way to loop bitstream measurements. For 7.1 bed layer it’s possible to sequence them for a sweep. What are the option for atmos e.g. sweep atmos speakers using bitstream files?

Maybe some sort for batch file/commands playlist to play external file.

 

[Bowkey]

Hi John,

In the latest few versions (30-33), there seem to be some problems when importing sweep recordings. If I use the API to import 5 subsequent messages (with blocking enabled), I get 5 successful replies from the API (with increasing "Import sweep ID.. completed" numbers), but only the first two measurements show up in REW. The ID numbers also keep increasing and don't match the actual number of measurements in REW (I'm not sure if this is intentional).

If I manually import sweep recordings (mono .wav versions which used to work in earlier versions), I often (but not always) get a 'Java.lang.arrayIndexOutOfBoundsException' error or 'The data in channel 1 is all zero and has been ignored'. In the latest version (beta 33), I get errors saying "Please choose which of the 2 channels in .wav to import" (although the .wav has only 1 channel) and, once an error saying the .wav was an mp3 or something along those lines (I didn't save that exact message, unfortunately).

The Stimulus + sweep recordings were made with an earlier REW version (but used to work fine up to this point), so maybe that has something to do with it as well.

Hope this helps.

 

[John Mulcahy]

In the latest few versions (30-33), there seem to be some problems when importing sweep recordings.

Please use the Help menu option to generate a diagnostic file and attach it.

 

[Bowkey]

Please use the Help menu option to generate a diagnostic file and attach it.

Done, I've also included the measurement wav files (including the stimulus) that cause the errors.

The first measurement generates the outOfBounds exception, the second one a 'The sweep and respone file sample rates are not the same' (although they both are 44.1kHz).

The measurement files are synthesized / composed and start with approx 250 zero samples, this has caused issues in the past, so maybe this has something to do with it.

 

[John Mulcahy]

Done, I've also included the measurement wav files (including the stimulus) that cause the errors.

No attachment, perhaps it was too large. You can email it to feedback@roomeqwizard.com

 

[Bowkey]

No attachment, perhaps it was too large. You can email it to feedback@roomeqwizard.com

Sorry about that, I probably forgot to click save, they seem to be there now (attached to post #388 above), but I've emailed them as well.

 

[John Mulcahy]

Thanks. For reasons best known to itself the MP3 handler was deciding those measured WAV files were actually MP3. I have uploaded beta 34 to deal with that.

 

[Bowkey]

Thanks. For reasons best known to itself the MP3 handler was deciding those measured WAV files were actually MP3. I have uploaded beta 34 to deal with that.

The mp3 handler was probably feeling a bit (pun intended..) left out, with everyone always going on about how much better lossless sounds ;-)

Thanks for the super quick fix, working great again now!

Talking about wav files; Would it be possible to add an endpoint to the API that would allow importing .wav files into the RTA?

 

[John Mulcahy]

I have added endpoints for RTA file import for the next build, but only one channel can be imported at a time and, since RTA file processing can take much longer than the API command timeout, the import command returns immediately with an OK response and import progress has to be monitored either via subscription or by polling the /import/rta-file/progress endpoint.

 

[Mike0815]

Hello John,

I'm getting some errors with Beta 33:
- Out of memory (heap space)
- Some snakeyaml error while saving camilladsp filters (this worked well in the past)

My Mac holds 16GB RAM. I do start REW with:
open -a REW —args -Xmx8192m

Regards
Michael

 

[John Mulcahy]

Beta 35 uploaded with these changes:

• Added: API endpoints to import files for RTA processing
• Changed: If an error occurs during FSAF processing save the excitation and mic data as wav files
• Fixed: Saving CamillaDSP filters to yaml produced an error

 

[John Mulcahy]

I'm getting some errors with Beta 33:
- Out of memory (heap space)
- Some snakeyaml error while saving camilladsp filters (this worked well in the past)

The yaml error was an obfuscation bug, fixed in beta 35 which I have just uploaded. The out of memory is occurring when allocating the image data for a spectrogram plot, but I don't see any issues with that even when running REW full screen on a 4k monitor, so the memory must have been used by some action before that. Did you load a very large set of mdat files? REW's heap usage is shown in the bottom left corner of the main window.

 

[Mike0815]

mdat gets quite large (> 100MB) with multiple mics & pro version, but this made no problems before even with regular 3GB startup setting. This heap error shows up even with smaller mdat of around 20MB and maybe 60 measurements (def. much less than my 300 limit set) Most of the time it happens when spectrogram is shown or redrawn.

 

[John Mulcahy]

Try without the big -Xmx value to see what effect that's having. If you get issues with 3G Xmx send me an example mdat and I'll see if I can reproduce the problem.