Nyquist sampling rate fix problem

[mark-pob]

In the fix the code: results = convert_results( file_id=os.path.basename(audio_file), time_exp=config.get("time_expansion", 1) or 1, duration=audio_full.shape[0] / float(sampling_rate), params=config, predictions=predictions, spec_feats=spec_feats, cnn_feats=cnn_feats, spec_slices=spec_slices,

    nyquist_freq=orig_samp_rate / 2,

may be incorrect. The sample rate for nyquist checks should be the lower of the two "target_sample_rate"(256Khz) or "orig_samp_rate"

[mbsantiago]

Hello @mark-pob, appreciate you raising this issue. I acknowledge your concern regarding potential issues when target_sample_rate is less than orig_sample_rate. If a detection falls between the nyquist limits of these rates, the current filters might fail to exclude them, which is indeed a problem since they shouldn't be considered valid due to containing frequencies beyond what can be inferred from the audio – where "audio" specifically refers to the model's perspective, i.e., the resampled audio.

That said, my understanding is that the processing pipeline should inherently prevent the generation of detections above the nyquist limit of target_sample_rate. This is because all detections are derived from the input spectrogram, and that spectrogram is capped at the nyquist limit of target_sample_rate. I'll verify this to ensure its accuracy. If the pipeline indeed functions as expected, there might not be an issue with the current implementation.

However, I'm open to your insights on this matter and I'm keen to hear your thoughts.

[mark-pob]

Hi,

I appreciate your rapid response. I only mentioned it because I noticed it was a fix to a problem someone else highlighted. So far it has not caused me any problems in my particular application, so I can't say if it would cause a problem.

Thanks,

Mark

On Fri, Jan 12, 2024 at 2:58 PM Santiago Martinez Balvanera < @.***> wrote:

Hello @mark-pob https://github.com/mark-pob, appreciate you raising this issue. I acknowledge your concern regarding potential issues when target_sample_rate is less than orig_sample_rate. If a detection falls between the nyquist limits of these rates, the current filters might fail to exclude them, which is indeed a problem since they shouldn't be considered valid due to containing frequencies beyond what can be inferred from the audio – where "audio" specifically refers to the model's perspective, i.e., the resampled audio.

That said, my understanding is that the processing pipeline should inherently prevent the generation of detections above the nyquist limit of target_sample_rate. This is because all detections are derived from the input spectrogram, and that spectrogram is capped at the nyquist limit of target_sample_rate. I'll verify this to ensure its accuracy. If the pipeline indeed functions as expected, there might not be an issue with the current implementation.

However, I'm open to your insights on this matter and I'm keen to hear your thoughts.

— Reply to this email directly, view it on GitHub https://github.com/macaodha/batdetect2/issues/24#issuecomment-1889436305, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGAHCOSB4AO26K7676GDLYOFFQ5AVCNFSM6AAAAABBYHTR4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBZGQZTMMZQGU . You are receiving this because you were mentioned.Message ID: @.***>