Skip to main content
Fix
Source Link
Jon Nordby
  • 251
  • 1
  • 4

Adding more wind samples to the "non-scooter" / ambient noise class is probably the best solution (your first suggestion). That will make your existing model strictly better at these cases, without needing other pre- or post-processing steps.

But, it might be difficult to get enough samples to really make the network / training process take those into account. If that is the case, there are some tricks that you can do:

  • Use sample weighting during training to make these samples get higher priority. In Tensorflow/Keras this can be done by passing the sample_weight argument to the fit() method.
  • Use data-augmentation as a data balancing strategy (upsampling). Creating multiple samples with slight variations for the problematic/challenging cases.
  • Use audio-mixing of event sounds (such as the wind noise) onto background samples, at different SNR to create more challenging background samples. Can be done using tools like Scaper.
  • If you have a lot of simple/repetitive samples represented in the dataset, consider dropping some of them, to allow more focus on the simpletricky cases. This is a data balancing strategy based on undersampling.

Note that the particular failure-mode that you have identified (wind noise being used for), might be a symptom of a wider issue. It might be that your model is just be looking at (any kind of) soundlevel variation, or spectrogram variation - and decide that means "snow-scooter".

To diagnose and prevent that, consider including also other "event like" sound into (besides the wind noise) into your dataset. Preferably, things that could plausibly occur in your deployment scenario.

Adding more wind samples to the "non-scooter" / ambient noise class is probably the best solution (your first suggestion). That will make your existing model strictly better at these cases, without needing other pre- or post-processing steps.

But, it might be difficult to get enough samples to really make the network / training process take those into account. If that is the case, there are some tricks that you can do:

  • Use sample weighting during training to make these samples get higher priority. In Tensorflow/Keras this can be done by passing the sample_weight argument to the fit() method.
  • Use data-augmentation as a data balancing strategy (upsampling). Creating multiple samples with slight variations for the problematic/challenging cases.
  • Use audio-mixing of event sounds (such as the wind noise) onto background samples, at different SNR to create more challenging background samples. Can be done using tools like Scaper.
  • If you have a lot of simple/repetitive samples represented in the dataset, consider dropping some of them, to allow more focus on the simple cases. This is a data balancing strategy based on undersampling.

Note that the particular failure-mode that you have identified (wind noise being used for), might be a symptom of a wider issue. It might be that your model is just be looking at (any kind of) soundlevel variation, or spectrogram variation - and decide that means "snow-scooter".

To diagnose and prevent that, consider including also other "event like" sound into (besides the wind noise) into your dataset. Preferably, things that could plausibly occur in your deployment scenario.

Adding more wind samples to the "non-scooter" / ambient noise class is probably the best solution (your first suggestion). That will make your existing model strictly better at these cases, without needing other pre- or post-processing steps.

But, it might be difficult to get enough samples to really make the network / training process take those into account. If that is the case, there are some tricks that you can do:

  • Use sample weighting during training to make these samples get higher priority. In Tensorflow/Keras this can be done by passing the sample_weight argument to the fit() method.
  • Use data-augmentation as a data balancing strategy (upsampling). Creating multiple samples with slight variations for the problematic/challenging cases.
  • Use audio-mixing of event sounds (such as the wind noise) onto background samples, at different SNR to create more challenging background samples. Can be done using tools like Scaper.
  • If you have a lot of simple/repetitive samples represented in the dataset, consider dropping some of them, to allow more focus on the tricky cases. This is a data balancing strategy based on undersampling.

Note that the particular failure-mode that you have identified (wind noise being used for), might be a symptom of a wider issue. It might be that your model is just be looking at (any kind of) soundlevel variation, or spectrogram variation - and decide that means "snow-scooter".

To diagnose and prevent that, consider including also other "event like" sound into (besides the wind noise) into your dataset. Preferably, things that could plausibly occur in your deployment scenario.

Source Link
Jon Nordby
  • 251
  • 1
  • 4

Adding more wind samples to the "non-scooter" / ambient noise class is probably the best solution (your first suggestion). That will make your existing model strictly better at these cases, without needing other pre- or post-processing steps.

But, it might be difficult to get enough samples to really make the network / training process take those into account. If that is the case, there are some tricks that you can do:

  • Use sample weighting during training to make these samples get higher priority. In Tensorflow/Keras this can be done by passing the sample_weight argument to the fit() method.
  • Use data-augmentation as a data balancing strategy (upsampling). Creating multiple samples with slight variations for the problematic/challenging cases.
  • Use audio-mixing of event sounds (such as the wind noise) onto background samples, at different SNR to create more challenging background samples. Can be done using tools like Scaper.
  • If you have a lot of simple/repetitive samples represented in the dataset, consider dropping some of them, to allow more focus on the simple cases. This is a data balancing strategy based on undersampling.

Note that the particular failure-mode that you have identified (wind noise being used for), might be a symptom of a wider issue. It might be that your model is just be looking at (any kind of) soundlevel variation, or spectrogram variation - and decide that means "snow-scooter".

To diagnose and prevent that, consider including also other "event like" sound into (besides the wind noise) into your dataset. Preferably, things that could plausibly occur in your deployment scenario.