Talk:Proposal 0.4: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
Created page with "== Fix mandatory metadata == == 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..." |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== |
== Datatype: Complex spectra == |
||
'''Fixed''': Conventions and DataType proposed. |
|||
== 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!) |
|||
Discussion |
|||
== Fix if datatypes can change within conventions == |
|||
When we say "conventions" do we mean a fixed data type? |
|||
A new datatype has been requested, allowing to store complex spectra. While in general quite clear what to do, a few details require clarification: |
|||
* 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. |
|||
* 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. |
|||
* 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 |
|||
* 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 |
|||
== Coordinate systems == |
|||
Need to fix a few details: |
|||
* In "spherical": Elevation angle vs. Zenith angle |
|||
* Quaternions? |
|||
Latest revision as of 17:11, 28 May 2013
Datatype: Complex spectra
Fixed: Conventions and DataType proposed.
Discussion
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
Coordinate systems
Need to fix a few details:
- In "spherical": Elevation angle vs. Zenith angle
- Quaternions?