Open nick-parslow opened 2 years ago
Have you tried with different frameSize/frameStep settings to see for which you get the described behaviour? I would also check which of the three values (Nsrc
, nWin
and Ndst
) becomes 1 and traceback in source where that value comes from.
The problem is defo 'Ndst' (or the logic of using it in that line), the other 2 get set to the correct values
I just tried with : frameSize = 0.01, frameStep = 0 (so will match frameSize) - no change, Nsrc and Nwin are 160, Ndst is 1 for all windows frameSize = 0.1, frameStep = 0 (so will match frameSize) - no change, Nsrc and Nwin are 1600, Ndst is 1 for all windows frameSize = 1, frameStep = 0.5 - no change, Nsrc and Nwin are 16000, Ndst is 1 for all windows
Unfortunately I haven't worked out where the Ndst is being set, I'm assuming there's a loop over the windows set up with frameSize and frameStep and because there's just one output value, Ndst ends up as 1. likely candidates I guess are: ./src/core/winToVecProcessor.cpp ./src/dspcore/windower.cpp but not sure atm.
Hi, I was toying around with the intensity/loudness calculations and I noticed that if I make a standard config with frame step 0.1s and frame width of 0.25s:
then Ndst always seems to have value 1, so the line:
long safeN = MIN(Nsrc,MIN(nWin,Ndst));
is always 1 (while Nsrc and nWin will usually be 400 for 16kHz) and so only the first datapoint in the frame is used (and the hamming window is effectively just a scaling value).
This looks like a bug but maybe I'm just mis-interpreting or mis-using the code (?) Is there maybe a way to get Ndst to behave better or maybe is this expected?