BUG: Spike timing in the first batch is not aligned to original signal

[teristam]

Describe the issue:

Hello, I have posted this in another issue but didn't receive a response. Just want to flag it here so that people are aware of this. I have been testing kilosort 4.0.4. I use the sorted spike timing to extract spike waveform from the original binary file (bfile). I find the spike timing in the first batch is offset by bfile.nt, while that for the other batches seem to be correct.

I used the following code to extract spikes directly from the bfile

clu_id = 3
s = []

chan_best = (templates**2).sum(axis=1).argmax(axis=-1)
chan_best = chan_map[chan_best]

cb = chan_best[clu_id]

spk_t = st[clu==clu_id]

for i in range(300):
    t = spk_t[i] 
    s.append(bfile[(t-bfile.nt//2):(t+bfile.nt//2+1),:])
s = np.stack(s)

I noticed the extracted waveforms are mixed:

but when I subtract bfile.nt from the spike time, it works:

And then spike time from the 2nd batch onward don't seem to need this time shift:

Reproduce the bug:

No response

Error message:

No response

Version information:

4.0.4

Context for the issue:

No response

Experiment information:

No response

[jacobpennington]

Thanks, we'll take another look at the special cases for the first batch.

[jacobpennington]

There was a bug introduced with a previous change, it's been reverted now with version 4.0.7. Please let us know if you still see this behavior with the new version.