Implement a database wrapper to be able to exploit azimuth localization symmetry
Currently, for each individual, each azimuth in [0,360[°, and each elevation, we have a pair of (HRIR_L, HRIR_R). Instead of that structure, we can use a wrapper where we have a new column "side" where a value of: -1 indicate a sound from the left, 0 indicate a sound from front or rear, 1 indicate a sound from the left.
Then, instead of (HRIR_L, HRIR_R) we have (HRIR_CONTRA, HRIR_IPSI), that is when the sound source is located on right, HRIR_CONTRA=HRIR_L, HRIR_IPSI=HRIR_R, the data is left unchanged, but when the sound source is located on the left, HRIR_CONTRA=HRIR_R, HRIR_IPSI=HRIR_L.
When the sound is located in the middle, the problem is undefined: I suggest to keep the data as it is, or to do randomization, i.e. permute HRIR_L or HRIR_R with 50% chance...
This wrapper will allow to train a model M2, that tries to locate the azimuth of a sound source, always located on the middle or the right side, being given (HRIR_CONTRA, HRIR_IPSI) as input.
It will also allow to train a model M1, that tries to locate the side of a sound source, being given (HRIR_L, HRIR_R) as input.
It is important to note that the 2 models will be trainable independantly, and in parallel.
A composition of the 2 models will then allow to obtain a model that is able to do azimuth regression in [0,360[° (or [-180,180[°, but with 2 times less computational requirements and a better ability to generalize to new data (at least, in theory).
The composition may be as follow: M1 predicts the side, M2 is feeded with input permutated or not depending on M1 result, then azimuth outputted from M2 for a right located sound source is simply multiplied by -1, 0, or 1 depending on M1 output.
Wanna do it @ageneres ?