Without understanding what the heightFactor is for, I wonder if it can be removed. In an ideal world the spectrogram plugin could determine the original sampling rate and so something with that information (such as create an audioContext with the same sampling rate) so that it doesn't resample and create that empty space, but I guess in the case of compressed audio this might be trickier. So setting this.height this.fftSamples is mathematically wrong. The spectrogram only contains positive frequencies, hence its width is half the number of FFT bins (fftSamples). Does anybody know why it was originally set to something other than 1? FFT returns a symmetric representation of a signal, half of all FFT bins is negative frequency, which is the mirror version of the other half. The issue appears not to be with the FFT/spectrogram but with that heightFactor. Notice that the original demo.wav file has a sample rate of 22050hz and yet the demo implies there is frequency content above nyquist.
This proved important when displaying waveforms with more frequency content if their sampleRate was low since the default audioContext seems to resample things pretty high (44.1 or 48kHz) and this results in a lot of black space at the top of the spectrogram. I also specified an audioContext with "audioContext: new AudioContext()". Changing the heightFactor = 1 fixed things.
Notice that the fundamental frequency is incorrectly labeled at 8kHz. To demonstrate what I was seeing, we replaced the demo.wav file with a file that contains a 4kHz square wav (wav file with 16kHz sampling rate) and this is what I saw: My coworker came across this bug report when he searched around after we discovered that the spectrogram frequency content was mislabeled and half of what we expected it to be.
0 kommentar(er)
