Call Overlap in Detection Logs (Negative Time Difference)

[scanjack]

Call Overlap in Detection Logs (Negative Time Difference)

GitHub Issue Body:
Hi Oisín,

Thank you for prompting me to create an official Issue.

I've continued testing using my automated pipeline (which processes TeensyBat recordings) and have observed an irregularity in how timestamps are logged by BatDetect2.

1. Issue: Negative Time Difference/Overlap in Sequential Logs
   I have found that the end time (end_time) of a logged bat call is occasionally later than the start time (start_time) of the immediately following call. This results in a negative time difference between consecutive entries.

Impact: Although the overlap is very brief (only a few milliseconds), this violation of sequential time order causes issues when processing and sequencing the detections in downstream analyses.

Example (See linked file below):

Call Index 15: Ends at 1.1716 s

Call Index 16: Starts at 1.1675 s

Overlap: -0.0041 seconds

2. Question on Design Intent
   Is this behavior intentional? We suspect this might correctly reflect the detection of two simultaneously occurring, overlapping bat calls in the recording.

We need clarification because the negative difference in the timestamp columns breaks the assumption of sequential processing. Is this the intended interpretation, or is this a bug in how the time boundaries are logged?

Attachments and Environment
Sample File (Proof for Call Overlap):

JSON Log: https://my.hidrive.com/lnk/YDmbCiGm1

The original WAV file can be provided upon request.

Environment:

BatDetect2 Version: v 1.3.0.

Operating System: Windows 11 plus Anaconda python

Thank you for clarifying this point. Please let me know if I can assist further with debugging!

Best regards,

Jochen Roth

[mbsantiago]

Hi @scanjack!

Thanks a lot for pointing this out.

The model is trained to predict the bounding-box width and height, and I suspect that in some rare cases it may be producing a negative width. I don’t think the current code checks for this edge case, and fixing it should be straightforward. I’ll patch a quick solution if this turns out to be the cause.

Cheers,
Santiago