For a variety of reasons, including:
The scipy chirp is based on:
I looked up Room Eq Wizard's solution, and it starts the sweep an octave below the user's stated low frequency limit, and ends an octave above the user's high frequency limit (Nyquist-limited). I don't love this solution because the sharp corners are retained, and the device under test must withstand a wider bandwidth stimulus than necessary.
So I thought I might extend the chirp signal at the low and high frequency ends with a few cycles of a half-Hann-windowed cosine function, with frequency set to the low and high frequency limits, to smoothly extend the chirp signal and avoid the corners. Is there a reason this is a bad approach? Has the industry already converged on a smarter approach I'm just ignorant of?
I'm a Python newb, and audio hobbyist, so I'm confident I'm ignorant of a huge swath of material that was established ages ago. Patience with that status would be appreciated.
Few
- I'm trying to learn Python
- I'd like to have a very compact speaker measurement script I can integrate with stepper motor controls for a diy Klippel scanner
- Now I'm just curious
The scipy chirp is based on:
cos(phase + (pi/180)*phi)
where phase is the integral (from 0 to t) of 2*pi*f(t). For a log-sweep, f(t) = f0 * (f1/f0)**(t/t1). I'd like to avoid the sharp corners at the beginning and end of this function. They may not be a huge problem in practice, but they're a bit ugly. I looked up Room Eq Wizard's solution, and it starts the sweep an octave below the user's stated low frequency limit, and ends an octave above the user's high frequency limit (Nyquist-limited). I don't love this solution because the sharp corners are retained, and the device under test must withstand a wider bandwidth stimulus than necessary.
So I thought I might extend the chirp signal at the low and high frequency ends with a few cycles of a half-Hann-windowed cosine function, with frequency set to the low and high frequency limits, to smoothly extend the chirp signal and avoid the corners. Is there a reason this is a bad approach? Has the industry already converged on a smarter approach I'm just ignorant of?
I'm a Python newb, and audio hobbyist, so I'm confident I'm ignorant of a huge swath of material that was established ages ago. Patience with that status would be appreciated.
Few