Frequency dependent window shifts all frequencies to the right

[keantoken]

Attached are measurements with and without FDW and the measurement

 

[John Mulcahy]

Not for me. The measurement was not included, please post it.

 

[keantoken]

Ah, it didn't upload because it was too large. This should work.

 

[KSTR]

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.

 

[John Mulcahy]

I'll try to recreate the issue and post the data file and procedure which led to the glitch.

That would be great, thanks.

 

[jtalden]

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.

L, R window increased

 

[John Mulcahy]

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]

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).

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]

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.

 

[John Mulcahy]

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).