Talk:Proposal 0.4: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
| Line 1: | Line 1: | ||
== Fix mandatory metadata == |
|||
The table is in the main page. I used the following rules: |
|||
* Mandatory because without this metadata '''any''' conventions will fail |
|||
* Or, mandatory because users might forget it, resulting in inconsistencies for '''all''' conventions |
|||
In other words, my suggestion represents the minimal version of any conventions. Let's see if this is consistent... |
|||
== Fix versioning of SOFA and conventions == |
== Fix versioning of SOFA and conventions == |
||
For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!) |
For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!) |
||
Revision as of 17:02, 28 May 2013
Fix versioning of SOFA and conventions
For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!)
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
Datatype: Complex spectra
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.
Coordinate systems
Need to fix a few details:
- In "spherical": Elevation angle vs. Zenith angle
- Quaternions?