V5.20.14 early access build

[John Mulcahy]

John, hello. On the ALL SPL tab, I need to move one of the graphs up or down. I can only do this if the vertical axis is SPL. With other units of measurement, the numbers in the Measurement actions window change, but the graph selected in the same window does not move. That is how it should be?

Yes, they are SPL offsets, other units are not affected.

 

[John Mulcahy]

Live measurements with j-test file also look different.

Should I generate all my test files again with the current build?

Leave it with me while I look into it further.

 

[sm52]

Thank you. Maybe you know a link to a video on how to calibrate REW and measure not the speakers, but the amplifier, phono stage of the vinyl player?

 

[kimmosto]

One on the main purposes of "Use loopback as cal and timing reference" is possibility to provide protection for fragile DUTs with either passive (capacitor) or active high-pass filter in the signal path. Purpose of "loopback as cal..." option is to eliminate effect of high-pass filtering from the result. Reference input is connected to the output of high-passing stage/component so correct result is flat magnitude and phase if response of DUT is ideal flat.

For example, active 1st order high-pass at 500 Hz in both measurement signal and loopback. HP filter is Xilica XP-4080 having some latency, but it does (should) not matter because "..as timing" option should remove latency of reference loop from the measurement.
ARTA, result is okay down to ~10 Hz:

REW ea25 with "Merge loopback..." option, result is wrong:

REW ea25 with "Make calibration..." option, result is wrong:

Comparison to flat signal in reference loop. Measurement loop has 1st order HP at 500 Hz:
ARTA, result looks okay down to ~20 Hz:

REW ea25 with "Merge loopback..." option, result looks okay down to ~20 Hz:

Comparison to flat signal in both inputs. Xilica DUT and Focusrite Scarlett 2i2 soundcard are not perfectly flat 5-40k, but "loopback as cal" should give flat result if channels are identical.
ARTA, result is exact down to 5 Hz:

REW ea25 with "Merge loopback..." option, result is not exactly flat:

"Make calibration..." gives the same result; not exactly flat.

Time windows in Preferences - Analysis were L=125 ms and R=500 ms in previous measurements. Window functions Tukey 0.25.
Program jams with 'Merge loopback...' option if time windows are (much) longer, for example L=500 ms and R=1000 ms.

 

[John Mulcahy]

One on the main purposes of "Use loopback as cal and timing reference" is possibility to provide protection for fragile DUTs with either passive (capacitor) or active high-pass filter in the signal path. Purpose of "loopback as cal..." option is to eliminate effect of high-pass filtering from the result. Reference input is connected to the output of high-passing stage/component so correct result is flat magnitude and phase if response of DUT is ideal flat.

On the Analysis preferences uncheck "Limit cal data boost to 20 dB". It is provided to avoid issues from sharp roll-offs (such as near Nyquist) producing large corrections which boost the noise floor.

I've fixed the long windows bug for the next build, thanks for reporting that.

 

[John Mulcahy]

Thank you. Maybe you know a link to a video on how to calibrate REW and measure not the speakers, but the amplifier, phono stage of the vinyl player?

I don't, sorry, but calibrating for voltage readings is pretty straightforward if you have a voltmeter.

 

[John Mulcahy]

Builds updated today with these changes:

• Changed: Dither amplitude is increased for 24-bit test tones whose frequencies have integer sample periods to fully remove quantisation artefacts.
• Fixed: Some generator signals incorrectly had low level dither applied (e.g. J-test)
• Fixed: Long IR windows could cause an error during measurements with merge loopback cal

 

[John Mulcahy]

Live measurements with j-test file also look different.

Should I generate all my test files again with the current build?

The J-test signal should be correct again with the latest build. I have also adjusted the dither for signals with short integer periods (e.g. 1 kHz at 48 kHz sampling has only 48 sample values) as the normal level is not sufficient to fully remove the artefacts for those.

The option to treat 32-bit data as 24-bit only affects the output path, it stops REW trying to put data into the least significant bits which will end up being removed. On the input side nothing needs to be done as the bits are zero anyway and the changes to input handling prompted by the bug identified with a WAV file mean that doesn't cause an issue. It did reveal some problems with 24-bit test signals generated in earlier versions, which were masked by the way the input data was previously being treated. That has been addressed, but the penalty is an increase in the signal noise floor of about 1 dB. It remains far below the noise floor of any device, however. There may still be some very low level artefacts (around -180 dB) for signals near full scale, but removing those would incur another 2 dB or so of noise floor increase so I have left them.

 

[kimmosto]

On the Analysis preferences uncheck "Limit cal data boost to 20 dB". It is provided to avoid issues from sharp roll-offs (such as near Nyquist) producing large corrections which boost the noise floor.

Unchecking avoids radical error, but there is still ~2.5 dB uncompensated at 20 Hz (ea25), and response at LF does not look exactly minimum phase. It's not very severe because visible error starts ca. 1 oct. below protection HP filters' -3 dB point. Just for comparison, ARTA leaves ~2 dB smaller error at 20 Hz. The same amount of noise at LF disturbs both.

One risk is that user (just like me) does not find/know the checkbox or realize meaning or significance of 'Limit cal data boost' and leaves it checked. With acoustical measurement of HF DUT it's impossible to see whether result is correct or not so program should force it unchecked or give big red warning if checked and limit is activated for example within 20-20k while measurement with 'loopback as cal' option selected.

 

[John Mulcahy]

Strange, I don't see that roll-off (500 Hz 1st order HP in both paths). I wonder what the difference is in our setups?

I'll mull over how best to handle the cal boost limit, I could just remove it for the merge (as was the case previously) but it causes artefacts for measurements of devices with bandwidth less than the measurement bandwidth.

 

[onlyoneme]

The J-test signal should be correct again with the latest build. I have also adjusted the dither for signals with short integer periods (e.g. 1 kHz at 48 kHz sampling has only 48 sample values) as the normal level is not sufficient to fully remove the artefacts for those.

The option to treat 32-bit data as 24-bit only affects the output path, it stops REW trying to put data into the least significant bits which will end up being removed. On the input side nothing needs to be done as the bits are zero anyway and the changes to input handling prompted by the bug identified with a WAV file mean that doesn't cause an issue. It did reveal some problems with 24-bit test signals generated in earlier versions, which were masked by the way the input data was previously being treated. That has been addressed, but the penalty is an increase in the signal noise floor of about 1 dB. It remains far below the noise floor of any device, however. There may still be some very low level artefacts (around -180 dB) for signals near full scale, but removing those would incur another 2 dB or so of noise floor increase so I have left them.

I still do not understand it. In my examples below I've used WiiM streamer connected to ADI-2 over toslink. My test sine files are 96/24 with 24 bit dither.

Results for old builds and old test file:
Treat 32-bit data as 24-bit is On:

Treat 32-bit data as 24-bit is Off:

New build, old test file, treat 32-bit data as 24-bit has no effect:

New build, new test file, treat 32-bit data as 24-bit has no effect::

As you can see input was affected by treat 32-bit data as 24-bit setting in older builds.

Maybe I'm just too dumb to understand it, but is the behavior above correct now?

 

[John Mulcahy]

The treat 32 as 24 setting did have an effect on the input in the older builds. It shouldn't and now doesn't.

 

[onlyoneme]

The treat 32 as 24 setting did have an effect on the input in the older builds. It shouldn't and now doesn't.

Ok, it's clear for me now, thx.

What about the different behavior with current build when test files generated by 5.20.13 were used vs current ones? Is it related to that "low level dither applied" you've mentioned?

 

[John Mulcahy]

The old files had artefacts that were masked by the old input handling, they become visible with the new input handling.

 

[onlyoneme]

So I will have to generate new files if I want to achieve an old "Treat 32-bit data as 24-bit" behavior with new builds. Thx for explanation.

 

[John Mulcahy]

Unchecking avoids radical error, but there is still ~2.5 dB uncompensated at 20 Hz (ea25), and response at LF does not look exactly minimum phase. It's not very severe because visible error starts ca. 1 oct. below protection HP filters' -3 dB point. Just for comparison, ARTA leaves ~2 dB smaller error at 20 Hz. The same amount of noise at LF disturbs both.

One risk is that user (just like me) does not find/know the checkbox or realize meaning or significance of 'Limit cal data boost' and leaves it checked. With acoustical measurement of HF DUT it's impossible to see whether result is correct or not so program should force it unchecked or give big red warning if checked and limit is activated for example within 20-20k while measurement with 'loopback as cal' option selected.

View attachment 58611

I can't work out that is happening in those measurements to produce the roll-off. Could you attach an mdat file? There may be some clues in the data. What measure dialog settings did you use?

Here is what I get for a similar situation:

 

[kimmosto]

I can't work out that is happening in those measurements to produce the roll-off. Could you attach an mdat file?

This is frequency response from Output 2 to Input 2, measured with 'Loopback as timing reference' only. No calibration files loaded.

I assume that this will - or at least should become calibration data with some scaling for measuring with 'Loopback as cal and timing ref'.
But it is not. Program does some equalization when measured out 2 -> in 2 is converted to calibration data. Relative level at 20 Hz has increased ca. 2.5 dB compared to 10 kHz. Black dotted curve below. Not very easy to compare visually due to vertical centering, but there is clear difference in bending at LF.

Funny rule that I have to post 10 message to get permission to link. So let's waste AV NIRVANA's server space for big mdat file.

 

[John Mulcahy]

This is frequency response from Output 2 to Input 2, measured with 'Loopback as timing reference' only. No calibration files loaded.

I think this might be a side effect of the correction flattening outside the frequency span of the measurement. Could you try a measurement with the start frequency set to zero? If that corrects it I can make a change to deal with the later start frequency.

 

[kimmosto]

I think this might be a side effect of the correction flattening outside the frequency span of the measurement.

That's it.

 

[John Mulcahy]

Builds updated today with these changes:

• Changed: Merging loopback cal to the IR ignores the state of the Analysis "Limit cal data boost to 20 dB" preference. If boosting outside the range of the device being measured causes artefacts the measurement span could be reduced to exclude them.
• Changed: The reference measurement for loopback calibration uses data outside the nominal measurement range

 

[Orochi]

Hi John,
My Cosmos ADC does not work with 32 bit format on MacOS. And I found that if I use the Macbook's built-in microphone or speaker, which is 32-bit float in MIDI, it still shows 24-bit in/out in rew.

 

[John Mulcahy]

REW asks for the greatest bit depth the OS offers for any device selected. There are no devices that manage 24-bit performance as yet (which has a theoretical noise floor of -144 dBFS), so the 24-bit sample depth is not a limitation.

 

[serko70]

REW asks for the greatest bit depth the OS offers for any device selected. There are no devices that manage 24-bit performance as yet (which has a theoretical noise floor of -144 dBFS), so the 24-bit sample depth is not a limitation.

As far as I know max human hearing capacity is something like 120dB. Why on Earth do we ever need and have 32 bit equipment then?

 

[phofman]

As far as I know max human hearing capacity is something like 120dB. Why on Earth do we ever need and have 32 bit equipment then?

• Marketing - reason to buy a new equipment
• Measurement devices
• 32 bits are the very standard in IT/digital computing, unlike 24bits (3 bytes) which require conversions from 32bits.

 

[serko70]

Dear John,

No effect on calculations but just a visual bug I guess, the FDW extension does not show up for some measurements in the trace aritmetic drop down list:

version: REW_windows-x64_5_20_14ea26





PLEASE IGNORE THE ABOVE: [FDW] was stuck with L for some reason, it's not supposed to show FDW situation in the drop down list!!!