Problem with frequency display

[tcli]

Hi,
I imported in REW the following impulse response :
0 0.16667 -0.66667 1.00000 -0.66667 0.16667 0
It's the impulse response of a transfer function having four zeros at unity.

If I compute its Fourrier transform in Octave and draw a loglog graph, I got the expected result :

A constant 24db/o slope going to -infinity at 0Hz.

But in REW I got that :

Where do this zero at 800Hz come from ?
I tried different parameters without any changes ....

 

[John Mulcahy]

Can you attach the file?

 

[tcli]

Seems that this forum don't want to attach .wav ...

 

[tcli]

OK , so if I append lots of zeros before and after the impulse in the wav file it's largely better :

 

[John Mulcahy]

Perhaps a problem with coefficient truncation, since that is a 16-bit WAV. Could try saving it as float WAV to see if that helps, I suspect the result may be quite sensitive to sample resolution. Could test that in Octave I guess by adjusting the values to the equivalent 16-bit truncated equivalents.

 

[John Mulcahy]

OK , so if I append lots of zeros before and after the impulse in the wav file it's largely better :

Shouldn't make any difference, REW pads the data with zeroes either side anyway.

 

[tcli]

But it does make a difference.
Perhaps a problem in REW with the import of very short impulse response.
As it's absolutely not the normal usecase for REW and that it works by padding with zeros in the wav file , it's fine for me.
Thanks for your great sotfware .

 

[John Mulcahy]

Can you attach the padded file?

 

[tcli]

zero4l.wav : padded file and zero4.mdat REW file with the two impulses.
You will see the two same exact impulses and different frequency responses.

By the way, I use REW on Linux , if it makes a difference .

 

[John Mulcahy]

The values in the files are different.

zero4:
Sample 1555 value 0.16665649
Sample aaab value -0.66665649
Sample 7fff value 0.99996948
Sample aaab value -0.66665649
Sample 1555 value 0.16665649

zero4l:
Sample 1555 value 0.16665649
Sample aaac value -0.66662598
Sample 7ffe value 0.99993896
Sample aaac value -0.66662598
Sample 1555 value 0.16665649

 

[tcli]

hum yes .. I padded the original impulse with octave , reading the 16 bits file and then write the padded one.
Result : double conversion : int16 to double + double to in16 ....

Anyway, I recompute the impulse and save it in int32 format and, you were right, there is no more problem
I'm confuse now to have fall in this very classical precision trap

Thanks for the help and for REW.