1
$\begingroup$

I've got a 3D time-frequency sound intensity vector that I've derived from Ambisonic b-format signals. W acts as the sound pressure P, and x,y,z acts as the particle velocity U vector for the respective Cartesian axes. The intensity vectors are then derived using I = P*U. I then derive the direction of arrival estimation vector by taking the opposite of the intensity vector so D = - I.

I'm looking to normalise these to between [-1,1] for the purposes of using them as target outputs for a machine learning algorithm. The normalisation (should) make it easier for the algorithm to converge and the output is still in Cartesian space.

However, due to the time varying nature of data I can't figure out the best way to normalise them.

I have already tried normalising using the max and min of the collective I matrix/vectors. But then converting from Cartesian to Spherical as a sanity check, I'm presented with different results when compared to transforming the raw intensity values. Specifically, it causes many of the results to be squeezed down to the same value when working to 5 decimal places.

My intuition is because the pressure for each time-frequency step can be drastically different so it's not appropriate to globally normalise them as P can be different for each time-frequency tile and thus U can also contain drastically different ranges of values as well.

Any suggestions? My only other thought is to maybe normalise each vector individually according to the timestep and frequency. Which in code would look something like this:

for timestep in range(timesteps):
   for freq_bin in range(num_bins):
      D_norm = normalise(I[batch, timestep, freq_bin, D])

This also seemed to produce different results when trying to transform into Spherical coordinates.

$\endgroup$

1 Answer 1

1
$\begingroup$

You have a few different options here.

Don't normalize, but calibrate. If your pressure is in $Pa$ and your particle velocity is in $m/s$ than your intensity will be in actual $W/m^2$ which is the physical truth and you can always compare measurements made at different times and different places.

Anything else would be dependent on signal properties and what specific features you are after. You can normalize an entire track to something like "mean energy is 50dBSPL at 1kHz" or "$L_{EQ}$ is 80dB(A)". That would preserve the level difference between consecutive frames and still allow to normalize between tracks.

If the duration of your features is equal or smaller than a frame, you can normalize frames individually to something like "total energy is 0 dB" .

You can normalize either in the time domain or the frequency domain. Since you have 3D vector, it would be best to normalize the magnitude, i.e.

$$M = \sqrt{p_x^2+p_y^2+p_z^2}$$

$\endgroup$
3
  • $\begingroup$ In my case though (and I should have made this clearer in the question so I will go back and edit, apologies) I'm taking the intensity vector, then flipping the polarity so it becomes a DOA estimation for each time-frequency tile in cartesian space. I can then use this to get an azimuth and elevation value. So all I really need to do is normalise the raw values to between [-1,1]. But it's how to do this and still end up with the same azimuth and elevation results from both raw and normalised data. $\endgroup$
    – Molem7b5
    Commented Dec 7, 2021 at 15:52
  • $\begingroup$ It would help to understand what exactly you are trying and what your "normalization" is supposed to achieve. Normalize over what? Space, time, energy, frequency ? $\endgroup$
    – Hilmar
    Commented Dec 7, 2021 at 19:05
  • $\begingroup$ @Molem7b5 Is there anything wrong if the same azimuth and elevation result from both raw and normalized data? They have the same direction and of course result in the same azimuth and elevation. Have you tried to use decibel unit, does it help your model to converge without normalizing? $\endgroup$
    – ZR Han
    Commented Dec 8, 2021 at 1:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.