Talk:Proposal 0.4

Fix if datatypes can change within conventions

When we say "conventions" do we mean a fixed data type?

yes: because it will be very easy for applications: they just have to check the conventions and the data type is fixed. On the other hand, we'll need a separate conventions for each datatype even though the measurement setup might have not changed.
no: we will have conventions which do not consider the datatype (=less conventions). On the other hand, each application has either to provide all datatypes or to check two things: conventions and datatype

A new datatype has been requested, allowing to store complex spectra. While in general quite clear what to do, a few details require clarification:

Do data exist? Most of the data are saved as IRs and can be easily transformed to frequency domain on loading by the application. Data natively stored as spectra or special needs for storing data directly as spectra would help.
Most of the measured IRs are real-valued. Complex spectra introduce redundancy for those IRs, resulting in increase of the file size. This disadvantage might be small because of the compression available in SOFA. Another way to handle that would be to store only parts of the spectra. This issue should be clarified.

It seems like saving data for (sparse) discrete frequencies as complex spectra might be interesting for HRTFs coming directly from BEM simulations. New conventions and its needs in general SOFA specs are being discussed
Fixed: Conventions and DataType proposed.

Need to fix a few details: