Frequency dependent window shifts all frequencies to the right

keantoken

Registered
Thread Starter
Joined
May 31, 2018
Messages
49
Attached are measurements with and without FDW and the measurement
 

Attachments

KSTR

Registered
Joined
Jun 7, 2019
Messages
36
I've recently had a very similar display problem on an import of a impulse reponse which was 88.2kHz, adding to a set of data which was 44.1kHz. The FR of the IR was off by a factor of two like if the sample rate had not been adjusted for the display. Restarting REW helped...
I'll try to recreate the issue and post the data file and procedure which led to the glitch.
 

jtalden

Active Member
Joined
May 22, 2017
Messages
627
Location
Arizona, USA
My AV System  
Preamp, Processor or Receiver
Marantz AV7705 Pre/Pro
Main Amp
Rotel RMB-1066 6 chnl P-amp x 2
Additional Amp
Behringer DCX2496 x 2
Universal / Blu-ray / CD Player
OPPO BDP-103 Universal Player
Front Speakers
DIY SEAS H1456/H1212 Spkr x 5
Subwoofers
DIY JBL 2235H 15" SW x 2
Video Display Device
JVC DLA-X790R
Screen
Da-Lite Da-Snap 39105V - 92"
Interesting...
I opened Post-3 file and copied the measurement. I then and set the offered FDW settings to the copy. The FDW copy shifted the frequency trace up by about 1 octave as reported.
After investigating I found that the window settings impacted this. The left window needed to be >2000 ms and right > than 800 ms. The shift occurred at any settings less than this. See below the charts with the FDW window settings applied.

L, R window settings as first opened.
41646


L, R window increased
41647
 

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
4,316
I fixed that FDW bug just after keantoken reported it, the bug was a side effect of changes to allow responses down to 0.1 Hz. The fix is in the next build. I haven't been able to reproduce the bug KSTR saw though.
 

KSTR

Registered
Joined
Jun 7, 2019
Messages
36
I haven't been able to reproduce the bug KSTR saw though.
I've analysed the .WAV header in question and there was a data field mismatch confusing REW.
This was a 88.2kHz float32 (type 3) file with brickwall filter from some internal upsampling, "sample rate" field was set correctly to 88200 but "bytes rate" field was set incorrectly to 705600 rather than 88200*4=352800. The software that produced the mismatch is the one to blame here (it is normally intended to process stereo files).

Strange enough, this also resulted in levels reported at 0.5x (6.02dB less).
corrupt-IR-wav.png


REW seems to use a sound file import library that apparently uses the "byte rate" field instead of the "sample rate" field" to return the sample rate. The latter would seem more correct to me (given its name ;-)
--> Don't fix (as that would be probably hard to do anyway), with correct .WAV files all is fine.
 

KSTR

Registered
Joined
Jun 7, 2019
Messages
36
EDIT: looks like it's more complicated than that, after patching the fields in question the FR still shows up incorrectly.
Attached are original file and a version that was opened and saved with Audition 3.0.
 

Attachments

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
4,316
The WAV file reader is part of the Java runtime, so not much scope for me to alter its behaviour. Sample rate, frame size in bytes, bits per sample and number of channels are the fields the reader looks at, the frame rate in the file is ignored (sample rate is used in its place).
 
Top Bottom