Talk:Proposal 0.4: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
→Coordinate systems: new section |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== |
== Datatype: Complex spectra == |
||
'''Fixed''': Conventions and DataType proposed. |
|||
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 |
|||
Discussion |
|||
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 == |
|||
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: |
A new datatype has been requested, allowing to store complex spectra. While in general quite clear what to do, a few details require clarification: |
||
| Line 21: | Line 9: | ||
* 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. |
* 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 |
|||
The corresponding requester/researcher has been contacted. Waiting for response... |
|||
== Coordinate systems == |
== Coordinate systems == |
||
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?