Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Spectogram plugin cuts out half of the canvas
See original GitHub issueI noticed it when working with 44.1kHz files (in your examples you are using 22k ones and it works just fine).
This is what I get:
this is the same file in audacity (notice the 0-11k range):
this is the same file in audacity with range 0-22k
I changed line 46 in wavesurfer-js/plugins/wavesurfer/spectogram.js (granted this breaks things for 22k files and most likely in other cases)
from: this.height = this.fftSamples/2;
to:
this.height = this.fftSamples;'
and I got as a result:
my code:
<head>
<script src="wavesurfer.js/dist/wavesurfer.min.js"></script>
<script src="wavesurfer.js/plugin/wavesurfer.spectrogram.js"></script>
</head>
<body>
<div id="waveform"></div>
<div id="wave-spectrogram"></div>
<script type="text/javascript">
var wavesurfer = WaveSurfer.create({
container: '#waveform',
});
wavesurfer.on('ready', function () {
var spectrogram = Object.create(WaveSurfer.Spectrogram);
spectrogram.init({
wavesurfer: wavesurfer,
container: "#wave-spectrogram",
});
});
wavesurfer.load('music_file.mp3')
</script>
</body>
</html>
music file that I used: https://github.com/arirusso/d3-audio-spectrum/blob/master/public/media/sweep.mp3
Issue Analytics
- State:
- Created 7 years ago
- Comments:21 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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. 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:
Notice that the fundamental frequency is incorrectly labeled at 8kHz. Changing the heightFactor = 1 fixed things. I also specified an audioContext with “audioContext: new AudioContext({sampleRate: 16000})”. 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. This is the result with the changes:
Notice that the original demo.wav file has a sample rate of 22050hz and yet the demo implies there is frequency content above nyquist.
The issue appears not to be with the FFT/spectrogram but with that heightFactor. Does anybody know why it was originally set to something other than 1?
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.
Without understanding what the heightFactor is for, I wonder if it can be removed. I guess that would change the look of everyone’s spectrograms if they’re used to seeing only half of the spectrogram Thoughts? Alternatively, assuming heightFactor has a useful purpose, could we make it explicitly programmable in the Spectrogram’s params?
maybe we should use an external spectrogram library for this plugin instead, e.g. https://github.com/vlandham/spectrogramJS