Filtering a data block usually results in more data than fits in the size of the block. If you throw away this added data, that will produce artifacts across blocks.
For FIR filters, you need to pad each chunk or block with at least the length of the impulse response of your filter before filtering (>= N+M-1). Then use overlap-add or overlap-save (FFT ...
The cone of confusion is based on a very simple approximation: a sphere with two microphones.
Real humans do have a fair bit of vertical localization ability using pinna cues, shoulder reflection, binaural asymmetries and dynamic cues: i.e. change in interaural differences for very small head rotations.
Computer models can operate the same way, depending ...
My understanding is that a spectrum analyzer is a graph of frequency vs magntiude and a spectrogram is a heatmap of frequency vs time. It might help to clarify which one you're after.
For audio, 1024 - 4096 is an adequate frame size to yield good results at 44.1kHz and extremly fast to compute. You will almost certainly need to window each frame.
For a ...
Cuts can simply be derived from boosts like so: p2 = 1 / p1
This is intuitive as this is how you would invert a bandshelf.
However, I'm not sure it leads to an elegant equation as inverting the sum of filters and recovering a rational filter expression might be messy, so there's potential a better way.
I can't run your code since one function is missing.
In general, parallel EQs are a not a great idea. Since you add the responses, the exact phase responses of either boost or cut need to be carefully controlled, otherwise you see cancellation (as you probably do here).
It's much easier to parametric EQs in series instead. If the gain is 0, there is no ...
There is (at least) one error in your routine. It concerns the definition of alpha. The correct formula is
However, you implemented
But that shouldn't influence the function of the filter as a high pass filter; it just implements the inverse of the given $Q$ value.
Human voice has the same frequencies as other noises, it is not possible to filter it with dumb algorithm. It is possible to filter based on temporal patterns like spectral subtraction, but this way you can only filter static noise, not background speech/bable noise. Pocketsphinx already has spectral subtraction.
To filter noise reliably you need an ...
Changing the volume abruptly always causes a click in the audio. Most DAC chips change volume on next zero crossing (or after a timeout if it takes too long). In this situation it would be best to use the MIDI volume as the target volume, and slide from current volume to target volume over many samples, either with linear or exponential ramp.
You are changing the volume in discrete steps, applied at random points in the audio signal.
If the signal happens to be close to zero, you won't hear much of anything.
If the signal is close to a peak, then you will get a "step" change in the signal. This audible.
When you roll the volume up and down that way, you get a kind of "zipper" sounding noise.
Your question is at the heart of a still-current topic in signal processing or image analysis, often under the names phaseless recovery or phase retrieval.
For instance, in January 2019, Yoshiki Masuyama et al. published a paper on phase recovery from amplitude spectrograms: Griffin-Lim like phase recovery via alternating direction method of multipliers (...
In general the whole complex Fourier transform is needed to reconstruct the time domain signal.
However, it's possible to reconstruct a real signal it from its Fourier transform magnitude alone (or phase alone) by using some iterative techniques, or very large matrix solutions.
Have a look at the papers by Monson Hayes...
You can do this very thing in some audio editors. Some let you change the sampling rate without resampling the audio - it literally just changes the marker that says "sampling rate 44100Hz" to "sampling rate 22050Hz."
It does indeed change the play time, and as you expect it doubles the play time when going from 44100Hz to 22050Hz.
It also lowers the ...
So, first of all, please call your "blocks of data" audio samples; in the context of audio file formats, we also call them frames, but it's really not a "block of data", but simply: a sequence of 44100 numbers per second. Nothing more, nothing less.
Is this a valid strategy to produce a new .wav file?
We need to make a difference between the signal and ...