silence_periods() might have an issue at the very end of a recording
Hello everyone!
I have run into an error with silence_periods (in the process of running peak_detection) which only occurs for at least one concatenation of recordings, but appears consistently. the troublesome line is:
" traces[onset:offset, :] = noise[onset:offset]"
Within the "get_traces" function of silence_periods.py
The size of the noise ends up being too small to fit in traces... This happens only for the very last chunk of recording, and in this specific case, it seems to be off by exactly one sample, as shown below.
My recording object, importantly with sample count:
The "end_frame"
I plan to experiment with "just clipping off the errant sample since it is one sample at the end of the recording anyway"; whether this is sufficient will depend on whether the error crops up again.
In any case, thought I might report it! Let me know what can be done to clarify, though the hack solution of:
try:
traces[onset:offset, :] = noise[onset:offset]
except Exception as e:
noiseSize = np.shape(noise)[0]
tracesSize = np.shape(traces)[0]
offset = min(noiseSize,tracesSize)
traces[onset:offset, :] = noise[onset:offset]
is doing okay for now.
Thanks,
Jeff Boucher
Thanks @JeffreyBoucher. We are in the process of trying to fix the last issue you discovered. See #4071. I'll ping @samuelgarcia and @yger since they were helping with the silence_periods in the other PR so they can look at it too.
Could it be because of concatenation, and rounding of num_samples? Because I do not see any obvious reason why, the end_frame should not be the same. Can you give me a minimal script to reproduce the error? Is it systematic?
Hello!
Unfortunately I don't think I'll have time in the near-future to make a minimal script for this one, particularly as I don't know exactly what the root of the problem is. It seems like the bug is not too big a deal (for me) now that I've added my hack solution, so I would call it low priority... And hopefully others who run into the bug can find this thread...
Anyway, yes it is systematic, it occurs reliably on given sets of sessions.
I've also found another session it happens with, and so learned it doesn't have to happen at the end of a recording object:
If I learn enough more about it that I think it'll be easy to make a simplified example, I will post it here.
Thanks!
Jeff Boucher
Tiny update, I discovered that the bug happens with non-concatenated files. This should also maybe make it much easier to make a reduced version, involving some of my data. I'll try and do that at some point in the next few months.