Proposal 0.4 - Revision history

Petibub: Closing 0.4

2013-08-20T13:36:02Z

Closing 0.4

← Older revision		Revision as of 15:36, 20 August 2013
Line 1:		Line 1:
	'''Only changes compared to the last version are listed here!!!'''		'''Only changes compared to the last version are listed here!!!'''

	'''Please discuss the proposal by using the "Discussion" function of Wiki.'''

Petibub: Renamed ComplexSpectrum to TF

2013-06-29T15:30:46Z

Renamed ComplexSpectrum to TF

← Older revision		Revision as of 17:30, 29 June 2013
Line 157:		Line 157:
	\|}		\|}

	=== New: ~~ComplexSpectrum~~ ===		=== New: TF ===

			Useful to describe a transfer function by a sparse number of frequencies. The guys from BEM simulations like it.

	{\| border="1"		{\| border="1"

Petibub: /* Mandatory metadata */

2013-06-25T16:44:34Z

Mandatory metadata

← Older revision		Revision as of 18:44, 25 June 2013
Line 47:		Line 47:
	\|GLOBAL_Title\|\|\|\|\|\|\|\|\|\| A succinct description of what is in the dataset		\|GLOBAL_Title\|\|\|\|\|\|\|\|\|\| A succinct description of what is in the dataset
	\|-		\|-
	\|GLOBAL_References\|\|\|\|\|\|\|\| \|\| Published or web-based references that describe the data or methods used		\|GLOBAL_References\|\|\|\|\|\|\|\| \|\| Published or web-based references that describe the data or methods used to produce it
	to produce it
	\|-		\|-
	\|GLOBAL_Comment\|\|\|\|\|\|\|\| \|\|		\|GLOBAL_Comment\|\|\|\|\|\|\|\| \|\|

Petibub: /* Can datatypes change within conventions? */

2013-05-28T16:10:49Z

Can datatypes change within conventions?

← Older revision		Revision as of 18:10, 28 May 2013
Line 109:		Line 109:
	* APIVersion: clearly separated from the rest.		* APIVersion: clearly separated from the rest.

	=== ~~Can~~ ~~datatypes~~ ~~change~~ within ~~conventions~~? ===		=== Allow various DataTypes within a single SOFAConventions? ===
	If yes, any application would have either to implement all possible datatypes or to check if the supported datatype is given within the conventions.

			* Fixed DataType:
	Thus, no, until we will have so many conventions with only the datatype changing that we decide to change this decision.
			** Pro: very simple for applications: they just have to check the conventions and the data type is known.
			** Con: separate conventions for each DataType required even though the measurement setup might have not changed.

			* Arbitrary DataType allowed:
			** Pro: less conventions, we will have conventions which do not consider the datatype.
			** Con: Each application has either to provide '''all''' datatypes and branch while processing between the different algorithms, or to check both Conventions '''and''' DataType on loading.

			At the moment we have 1 stable and 2 proposed SOFA Conventions. This number is rather low, thus we wait until we'll have more conventions and then decide if we want to allow to separate DataType from SOFAConventions.

	=== Fix the coordinate systems within conventions? ===		=== Fix the coordinate systems within conventions? ===

Petibub: /* Mandatory metadata */

2013-05-28T16:03:10Z

Mandatory metadata

← Older revision		Revision as of 18:03, 28 May 2013
Line 6:		Line 6:
	== Mandatory metadata ==		== Mandatory metadata ==

	~~The metadata mandatory in all SOFA conventions have not been fixed yet.~~ We propose ~~to have~~ the following metadata mandatory in all SOFA conventions:		We propose the following metadata to be mandatory for '''all''' SOFA conventions. Following rules must be fulfilled:
			* Mandatory because without this metadata '''any''' conventions will fail
			* Or, mandatory because users might forget it, resulting in inconsistencies for '''all''' conventions

Petibub at 16:01, 28 May 2013

2013-05-28T16:01:21Z

Petibub: /* Datatypes */

2013-05-28T15:38:46Z

Datatypes

← Older revision		Revision as of 17:38, 28 May 2013
Line 122:		Line 122:
	At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables. If provided, use also attributes to describe the LongName and Units.		At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables. If provided, use also attributes to describe the LongName and Units.

	== ~~Datatypes~~ ==		== DataType ==
	=== New: IIRBiquad ===		=== New: IIRBiquad ===

Petibub at 15:38, 28 May 2013

2013-05-28T15:38:29Z

← Older revision		Revision as of 17:38, 28 May 2013
Line 122:		Line 122:
	At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables. If provided, use also attributes to describe the LongName and Units.		At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables. If provided, use also attributes to describe the LongName and Units.

	== ~~New datatype: IIRBiquad~~ ==		== Datatypes ==
			=== New: IIRBiquad ===

	{\| border="1"		{\| border="1"
Line 147:		Line 148:
	\|}		\|}

	== New ~~datatype~~: ComplexSpectrum ==		=== New: ComplexSpectrum ===

	{\| border="1"		{\| border="1"
Line 170:		Line 171:
	Note that the dimensional variable N is mandatory, must be of dimension N, and must provide the frequency values.		Note that the dimensional variable N is mandatory, must be of dimension N, and must provide the frequency values.

	== Update ~~of datatype~~ FIR ==		=== Update: FIR ===

	The standard committee agreed that the broadband delay should be provided in any case. Thus, we propose to add a new field, Delay to the FIR type.		The standard committee agreed that the broadband delay should be provided in any case. Thus, we propose to add a new field, Delay to the FIR type.

Petibub: /* RoomType */

2013-05-28T15:37:18Z

RoomType

← Older revision		Revision as of 17:37, 28 May 2013
Line 191:		Line 191:

	== RoomType ==		== RoomType ==

			We propose the following RoomTypes. Note that any other RoomType than freefield means that reverberation is expected to be in the data.

			=== freefield ===

			* Meaning: Data measured under assumed freefield conditions.
			* Usage: Used for the most of the HRTF databases.
			* Parameters:
			** RoomDescription: optional, narrative description of the anechoic chamber used.


			=== reverberant ===

			* Meaning: don't know, don't care
			* Usage: Default value.
			* Parameters:
			** RoomDescription: optional, narrative description of the room


			=== shoebox ===

			* Meaning: Rectangular room for which the size is known. Can be used as a first-order approximation of the room.
			* Usage: BRIRs from Oldenburg measured in Office II are using that RoomType.
			* Parameters:
			** RoomCornerA: mandatory, [C], defines the first room corner. Provide Type and Units as well.
			** RoomCornerB: mandatory, [C], defines the second room corner. Provide Type and Units as well.
			** RoomDescription: optional, narrative description of the room.

			=== link ===
			* Meaning: Quantitative room description is provided in a separate file. This RoomType was "DAE" in previous SOFA versions, but I think that "link" is more general.
			* Usage: Not used yet.
			* Parameters:
			** GLOBAL_RoomLink: mandatory, provides a link to the file. More details must be defined on the first appearance of usage.
			** RoomDescription: optional, narrative description of the room.

Petibub at 15:21, 28 May 2013

2013-05-28T15:21:52Z

← Older revision		Revision as of 17:21, 28 May 2013
Line 189:		Line 189:
	\|Data.SamplingRate_Units\|\|hertz\|\| \|\| \|\|		\|Data.SamplingRate_Units\|\|hertz\|\| \|\| \|\|
	\|}		\|}

			== RoomType ==

← Older revision		Revision as of 18:01, 28 May 2013
Line 99:		Line 99:
	'''Dimensional variables (coordinate variables)''': At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables.		'''Dimensional variables (coordinate variables)''': At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables.

			== Various issues ==
	== Versioning of SOFA and conventions ==		=== Versioning of SOFA and conventions ===

	Three version types:		Three version types:
Line 106:		Line 107:
	* APIVersion: clearly separated from the rest.		* APIVersion: clearly separated from the rest.

	== Can datatypes change within conventions? ==		=== Can datatypes change within conventions? ===
	If yes, any application would have either to implement all possible datatypes or to check if the supported datatype is given within the conventions.		If yes, any application would have either to implement all possible datatypes or to check if the supported datatype is given within the conventions.

	Thus, no, until we will have so many conventions with only the datatype changing that we decide to change this decision.		Thus, no, until we will have so many conventions with only the datatype changing that we decide to change this decision.

	== Fix the coordinate systems within conventions? ==		=== Fix the coordinate systems within conventions? ===
	Until now, Conventions support just a single coordinate system per variable and each application must use conversion functions if required.		Until now, Conventions support just a single coordinate system per variable and each application must use conversion functions if required.

	== Naming of the units ==		=== Naming of the units ===
	lowercase, the rest is not clarified yet.		lowercase, the rest is not clarified yet.

	== Include strings as variables ==		=== Include strings as variables ===

	== Role of dimension variables ==		=== Role of dimension variables ===
	At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables. If provided, use also attributes to describe the LongName and Units.		At the moment, we consider the dimension variables (or coordinate variables) as not mandatory, i.e., optional. Depending on the datatype and conventions, some of them might be mandatory, though. We suggest the type "double" for the dimensional variables. If provided, use also attributes to describe the LongName and Units.