Output volume
Opened this issue · 6 comments
It appears that the output volume is significantly less that the original volume? Is this by design? I don't understand the math enough to know if this is by design or if the volume is being lost somewhere in the computations.
Yeah it seems to be a consequence of the processing, what I have unscientifically found to work best is to boost the volume using pre- and post-GainNodes both set to a value of 1.6.
I can understand why it's there in the handleOutputBuffersToRetrieve function where it divides by the number of overlaps. Logically, the same signal added to itself nbOverlap times should be divided back down. But from my experience with digital audio, mixing signals usually doesn't require a shift down.
I'm not scientifically or mathematically inclined, but from a logical standpoint, would it makes sense to maybe keep something like an RMS value for each WEBAUDIO_BLOCK_SIZE window, and then normalize each block as it goes out to about what it was when it came in? I may give that a try, but I wonder if the perceived volume would jump too much and be too perceptible to the human ear?
Honestly crunching all these numbers in pure JS is so cpu intensive as it is, I wouldn't want to pile on any further computation, which is why I settled on using a simple pregain/postgain to compensate.
Sorry, one more question if you don't mind. The fft and ifft, are those standard? I'm porting this to c++. Could I substitute something like fftw instead? From some basic profiling, it looks like transform4 and realTransform4 are really taking the bulk of the time.
Full disclosure, I'm not a maintainer of this project just a tinkerer who forked it. I'm not sure why you would want to port this to c++ as there are surely better existing implementations (Rubber Band comes to mind), this is just a rough implementation using web standards within the limits of current browsers. But yeah, in theory you should be able to use a better/faster existing FFT library, not sure how much of a drop in replacement it would be.
Yea, I've looked at Rubber Band but it has commercial licensing restrictions. I just need something for a media player/karaoke app, but since I might make mine commercial also, I need something less restrictive with licensing. Also, I really just want to understand more of how it all works, so I'm a fellow tinkerer as well. I appreciate the discourse though.