Talk:SOFA conventions - Revision history

Petibub at 16:24, 25 June 2013

2013-06-25T16:24:08Z

← Older revision		Revision as of 18:24, 25 June 2013
Line 2:		Line 2:
	== Headphone transfer functions (HpTFs) ==		== Headphone transfer functions (HpTFs) ==

	No public HpIR databases nor standard HpIR repositories have been proposed to date. One of the purposes of HpIRs recordings is to compute the equalization filter that compensates the headphone starting from the raw HpIRs. ''Question: store the full ~~transmitter~~-receiver matrix or only a one-to-one correspondence?''		No public HpIR databases nor standard HpIR repositories have been proposed to date. One of the purposes of HpIRs recordings is to compute the equalization filter that compensates the headphone starting from the raw HpIRs. ''Question: store the full emitter-receiver matrix or only a one-to-one correspondence?''

	For each pair of headphones, a collection of individual HpIRs and equalization filters are stored with respect to a specific subject. ''SubjectID seems to be required. Saved as equalization filters, the data could have a one-to-one correspondence between ~~transmitters~~ and receivers, i.e., data for each receiver correspond to data for a ~~transmitter~~.'' It is desirable to have a ''foreign key'' to the HRIRs set recorded on the same subject in order to provide data for an individual binaural listening experience.		For each pair of headphones, a collection of individual HpIRs and equalization filters are stored with respect to a specific subject. ''SubjectID seems to be required. Saved as equalization filters, the data could have a one-to-one correspondence between emitters and receivers, i.e., data for each receiver correspond to data for a emitter.'' It is desirable to have a ''foreign key'' to the HRIRs set recorded on the same subject in order to provide data for an individual binaural listening experience.

	For every subject, three data containers - raw, compensated and eq - could be defined. ''The processing state could be defined by the global attribute ProcessingState'':		For every subject, three data containers - raw, compensated and eq - could be defined. ''The processing state could be defined by the global attribute ProcessingState'':
Line 12:		Line 12:

	The following information is required:		The following information is required:
	* headphone model, producer. ''This could correspond to SourceDescription and ~~TransmitterDescription~~''. Specific characteristics of the headphones such as transducer type, acoustic coupling, and design are stored in their data sheet.		* headphone model, producer. ''This could correspond to SourceDescription and EmitterDescription''. Specific characteristics of the headphones such as transducer type, acoustic coupling, and design are stored in their data sheet.
	* eq algorithm, equalization algorithm used. ''ProcessingState could be used as a narrative descriptor.''		* eq algorithm, equalization algorithm used. ''ProcessingState could be used as a narrative descriptor.''

Petibub: informative part removed, attributes proposed

2013-06-25T16:22:01Z

informative part removed, attributes proposed

← Older revision		Revision as of 18:22, 25 June 2013
Line 2:		Line 2:
	== Headphone transfer functions (HpTFs) ==		== Headphone transfer functions (HpTFs) ==

		⚫	No public HpIR databases nor standard HpIR repositories have been proposed to date. One of the purposes of HpIRs recordings is to compute the equalization filter that compensates the headphone starting from the raw HpIRs. ''Question: store the full transmitter-receiver matrix or only a one-to-one correspondence?''
	No public HpIR databases nor standard HpIR repositories have been proposed to date. Typically, small sets of headphones are tested limited to the purpose of reproducing a virtual auditory scene (VAS) for a specific experiment and subject. Recent auralization softwares cluster headphones by type ( i.e. earphones, in-ear headphones, closed-back or open-back circumaural), each capturing common behaviours for a generic listener. However, given H headphone models and L listeners it is possible to measure H x L individual HpIRs. Analyses of headphone-to-external ear transfer functions, ear canal entrance-to-eardrum transfer functions and impedance mismatch need to be carried on in order to understand and control sound artifacts introduced by headphones.

		⚫	For each pair of headphones, a collection of individual HpIRs and equalization filters are stored with respect to a specific subject. ''SubjectID seems to be required. Saved as equalization filters, the data could have a one-to-one correspondence between transmitters and receivers, i.e., data for each receiver correspond to data for a transmitter.'' It is desirable to have a ''foreign key'' to the HRIRs set recorded on the same subject in order to provide data for an individual binaural listening experience.
	These responses need to be methodically stored in specific data structures sharing common features with individual HRIR databases.
	The key observations that guide the design of such discussed convention are:
	* HpIRs are highly sensitive to the positioning of headphones;
	* both closed- and open-ear canal measurements are required for the evaluation of binaural reproduction;
	* how the headphones interact with the external ear is strictly subject-dependent.
	As a matter of fact, the intersubjective variation is particularly marked in the high-frequency range, where important elevation cues generally lie. Thus, an inaccurate compensation likely leads to spectral colorations that affect both source elevation perception and sound externalization

		⚫	For every subject, three data containers - raw, compensated and eq - could be defined. ''The processing state could be defined by the global attribute ProcessingState'':
⚫	~~Indeed,~~ ~~one~~ of the purposes of HpIRs recordings is to compute the equalization filter that compensates the headphone starting from the raw HpIRs.
		⚫	* the raw data from the recordings: ''GLOBAL_ProcessingState = 'raw'?''
⚫	For each pair of headphones, a collection of individual HpIRs and equalization filters are stored with respect to a specific subject. It is desirable to have a ''foreign key'' to the HRIRs set recorded on the same subject in order to provide data for an individual binaural listening experience.
			* the compensated impulse responses: ''GLOBAL_ProcessingState = 'compensated by using xxx algorithm with yyy parameters'?''
		⚫	* the equalization filter (under the form of an impulse response) obtained from the inverse HpIR through one or more techniques, e.g. considering the mean HpIR measurement with respect to all the repositionaments of that device. ''This could be also described by the ProcessingState, e.g., GLOBAL_ProcessingState = 'inverted equ filters by using XXX regularization and YYY averaging technique'.''

		⚫	The following information is required:
⚫	For every subject, three data containers - raw, compensated and eq - could be defined.
		⚫	* headphone model, producer. ''This could correspond to SourceDescription and TransmitterDescription''. Specific characteristics of the headphones such as transducer type, acoustic coupling, and design are stored in their data sheet.
⚫	* the raw data from the recordings
		⚫	* eq algorithm, equalization algorithm used. ''ProcessingState could be used as a narrative descriptor.''
	* the compensated impulse responses
⚫	* the equalization filter (under the form of an impulse response) obtained from the inverse HpIR through one or more techniques, e.g. considering the mean HpIR measurement with respect to all the repositionaments of that device.

⚫	The following information:
⚫	* headphone model, producer ~~included (~~''~~following a similar~~ ~~approach~~ ~~used~~ ~~for~~ ~~anthropometric~~ ~~data~~ ~~(AD)~~''); ~~specific~~ characteristics of the headphones such as transducer type, acoustic coupling, and design are stored in their data sheet.
⚫	* eq algorithm, equalization algorithm used
	The storage of individual headphone compensation filters promotes the personal use of headphones. This is especially true in experimental environments, yet HpIR modeling and cluster analysis would allow the extension of this approach to a commercial domain.

	== Include anthropometric data (AD) ==		== Include anthropometric data (AD) ==

147.162.231.98: /* Headphone transfer functions (HpTFs) */

2013-05-30T10:36:03Z

Headphone transfer functions (HpTFs)

← Older revision		Revision as of 12:36, 30 May 2013
Line 2:		Line 2:
	== Headphone transfer functions (HpTFs) ==		== Headphone transfer functions (HpTFs) ==

			No public HpIR databases nor standard HpIR repositories have been proposed to date. Typically, small sets of headphones are tested limited to the purpose of reproducing a virtual auditory scene (VAS) for a specific experiment and subject. Recent auralization softwares cluster headphones by type ( i.e. earphones, in-ear headphones, closed-back or open-back circumaural), each capturing common behaviours for a generic listener. However, given H headphone models and L listeners it is possible to measure H x L individual HpIRs. Analyses of headphone-to-external ear transfer functions, ear canal entrance-to-eardrum transfer functions and impedance mismatch need to be carried on in order to understand and control sound artifacts introduced by headphones.
	Measured data exist as IRs. More information on metadata and measurement setups required. Corresponding researchers contacted. Waiting for response...

			These responses need to be methodically stored in specific data structures sharing common features with individual HRIR databases.
			The key observations that guide the design of such discussed convention are:
			* HpIRs are highly sensitive to the positioning of headphones;
			* both closed- and open-ear canal measurements are required for the evaluation of binaural reproduction;
			* how the headphones interact with the external ear is strictly subject-dependent.
			As a matter of fact, the intersubjective variation is particularly marked in the high-frequency range, where important elevation cues generally lie. Thus, an inaccurate compensation likely leads to spectral colorations that affect both source elevation perception and sound externalization

			Indeed, one of the purposes of HpIRs recordings is to compute the equalization filter that compensates the headphone starting from the raw HpIRs.
			For each pair of headphones, a collection of individual HpIRs and equalization filters are stored with respect to a specific subject. It is desirable to have a ''foreign key'' to the HRIRs set recorded on the same subject in order to provide data for an individual binaural listening experience.

			For every subject, three data containers - raw, compensated and eq - could be defined.
			* the raw data from the recordings
			* the compensated impulse responses
			* the equalization filter (under the form of an impulse response) obtained from the inverse HpIR through one or more techniques, e.g. considering the mean HpIR measurement with respect to all the repositionaments of that device.

			The following information:
			* headphone model, producer included (''following a similar approach used for anthropometric data (AD)''); specific characteristics of the headphones such as transducer type, acoustic coupling, and design are stored in their data sheet.
			* eq algorithm, equalization algorithm used
			The storage of individual headphone compensation filters promotes the personal use of headphones. This is especially true in experimental environments, yet HpIR modeling and cluster analysis would allow the extension of this approach to a commercial domain.

	== Include anthropometric data (AD) ==		== Include anthropometric data (AD) ==

Petibub: /* Include calibration data */

2013-05-24T17:17:25Z

Include calibration data

← Older revision		Revision as of 19:17, 24 May 2013
Line 30:		Line 30:
	In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.		In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.
	* It seems like we would need to save the IRs from speaker(s) and microphone(s) together with other metadata like levels. Would it be sufficient to store that information in a separate SOFA file? Applications which do not care, would not have this ballast. Researchers who care, could use it to reproduce all post-processing steps. A new SOFA conventions for calibration would do - Does it make sense?		* It seems like we would need to save the IRs from speaker(s) and microphone(s) together with other metadata like levels. Would it be sufficient to store that information in a separate SOFA file? Applications which do not care, would not have this ballast. Researchers who care, could use it to reproduce all post-processing steps. A new SOFA conventions for calibration would do - Does it make sense?
	* Seems like level would be important. ~~Data?~~ ~~What~~ ~~level?~~ ~~Why~~ ~~not~~ ~~simple~~ ~~calculate~~ the level ~~from~~ ~~the~~ data?		* Seems like level would be important. Intermediate results: specifications for the level required, name for the variable required? Then, we could have level as an optional variable in SOFA. Also, some data would be nice

	== Include room pictures ==		== Include room pictures ==

Petibub: /* Include calibration data */

2013-05-21T21:00:07Z

Include calibration data

← Older revision		Revision as of 23:00, 21 May 2013
Line 30:		Line 30:
	In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.		In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.
	* It seems like we would need to save the IRs from speaker(s) and microphone(s) together with other metadata like levels. Would it be sufficient to store that information in a separate SOFA file? Applications which do not care, would not have this ballast. Researchers who care, could use it to reproduce all post-processing steps. A new SOFA conventions for calibration would do - Does it make sense?		* It seems like we would need to save the IRs from speaker(s) and microphone(s) together with other metadata like levels. Would it be sufficient to store that information in a separate SOFA file? Applications which do not care, would not have this ballast. Researchers who care, could use it to reproduce all post-processing steps. A new SOFA conventions for calibration would do - Does it make sense?
			* Seems like level would be important. Data? What level? Why not simple calculate the level from the data?

	== Include room pictures ==		== Include room pictures ==

Ente: Reverted edits by 193.171.195.36 (talk) to last revision by Petibub

2013-05-21T11:41:49Z

Reverted edits by 193.171.195.36 (talk) to last revision by Petibub

← Older revision		Revision as of 13:41, 21 May 2013
Line 2:		Line 2:
	== Headphone transfer functions (HpTFs) ==		== Headphone transfer functions (HpTFs) ==

	Measured data exist as IRs~~<ref>Testing the footnote extension</ref>~~. More information on metadata and measurement setups required. Corresponding researchers contacted. Waiting for response...		Measured data exist as IRs. More information on metadata and measurement setups required. Corresponding researchers contacted. Waiting for response...

	== Include anthropometric data (AD) ==		== Include anthropometric data (AD) ==
Line 39:		Line 39:

	Corresponding researchers contacted, waiting for response...		Corresponding researchers contacted, waiting for response...

	<references />

193.171.195.36 at 10:58, 21 May 2013

2013-05-21T10:58:23Z

← Older revision		Revision as of 12:58, 21 May 2013
Line 2:		Line 2:
	== Headphone transfer functions (HpTFs) ==		== Headphone transfer functions (HpTFs) ==

	Measured data exist as IRs. More information on metadata and measurement setups required. Corresponding researchers contacted. Waiting for response...		Measured data exist as IRs<ref>Testing the footnote extension</ref>. More information on metadata and measurement setups required. Corresponding researchers contacted. Waiting for response...

	== Include anthropometric data (AD) ==		== Include anthropometric data (AD) ==
Line 39:		Line 39:

	Corresponding researchers contacted, waiting for response...		Corresponding researchers contacted, waiting for response...

			<references />

Petibub: /* Include calibration data */

2013-05-18T17:28:37Z

Include calibration data

← Older revision		Revision as of 19:28, 18 May 2013
Line 26:		Line 26:

	Calibration data can hav several forms, depending on the measurement in question. If the measurement is a transfer function, and that it it's intention, then one could provide the measured transfer function of the measurement chain without the measurement object present. In the case of the HRTF, this is the measured transfer function without the head present. As there are various means of removing the effects of the measurement chain (deconvolution, spectral equalizing) the "calibrated" final data may vary between methods. If the object if to provide the data in its most raw form, for other researchers to use, the uncalibrated data, along with necessary calibration files, is of interest. In this way, the frequency response of the key elements, notably the microphone and speakers, can be both examined and taken into account. In the context of HRTF measurements which use multiple speakers, the calibration of each speaker is crucial in order to avoid spectral coloration which is independent of the head response and therefor an artifact of the measurement system. In such a case, impulse responses should be provided for each speaker, with the microphone oriented on-axis to the speaker. This can be performed with the measurement microphones used for the data acquisition, or a calibrated measurement microphone, whose model should be clearly stated. If the second is employed, a microphone measurement file is also necessary, consisting of a calibration measurement for a single speaker and the accompanying impulse response of all 3 microphones (again, in the case of and HRTF measurement). For a truly robust analysis of the data, this calibration measurement is made before and after the measurement session, to ensure no time independence of the measurement system, which is not always the case. In such a case that the before/after data do not correspond, the data should not be utilized. The actual data to be included is therefore a simple impulse response clearly annotated to indicate the microphone/speaker in question. This therefore requires in a multi-speaker measurement condition that each entry in the HRTF set includes a speaker ID. In the event that "un-calibrated", or already calibrated processed data, is provided, then there should be a clear text description indicating the calibration method used, and any addition post-treatment, such as low-frequency interpolated data (how, frequency range), equalization (diffuse field or otherwise), etc. As these different elements are clearly of more interest to researchers, rather than industrial uses, they cannot be "required elements". A simple required tag should be available indicating if the data is "raw" with accompanying calibration data, or is "processed".		Calibration data can hav several forms, depending on the measurement in question. If the measurement is a transfer function, and that it it's intention, then one could provide the measured transfer function of the measurement chain without the measurement object present. In the case of the HRTF, this is the measured transfer function without the head present. As there are various means of removing the effects of the measurement chain (deconvolution, spectral equalizing) the "calibrated" final data may vary between methods. If the object if to provide the data in its most raw form, for other researchers to use, the uncalibrated data, along with necessary calibration files, is of interest. In this way, the frequency response of the key elements, notably the microphone and speakers, can be both examined and taken into account. In the context of HRTF measurements which use multiple speakers, the calibration of each speaker is crucial in order to avoid spectral coloration which is independent of the head response and therefor an artifact of the measurement system. In such a case, impulse responses should be provided for each speaker, with the microphone oriented on-axis to the speaker. This can be performed with the measurement microphones used for the data acquisition, or a calibrated measurement microphone, whose model should be clearly stated. If the second is employed, a microphone measurement file is also necessary, consisting of a calibration measurement for a single speaker and the accompanying impulse response of all 3 microphones (again, in the case of and HRTF measurement). For a truly robust analysis of the data, this calibration measurement is made before and after the measurement session, to ensure no time independence of the measurement system, which is not always the case. In such a case that the before/after data do not correspond, the data should not be utilized. The actual data to be included is therefore a simple impulse response clearly annotated to indicate the microphone/speaker in question. This therefore requires in a multi-speaker measurement condition that each entry in the HRTF set includes a speaker ID. In the event that "un-calibrated", or already calibrated processed data, is provided, then there should be a clear text description indicating the calibration method used, and any addition post-treatment, such as low-frequency interpolated data (how, frequency range), equalization (diffuse field or otherwise), etc. As these different elements are clearly of more interest to researchers, rather than industrial uses, they cannot be "required elements". A simple required tag should be available indicating if the data is "raw" with accompanying calibration data, or is "processed".
			* Seems like we need a good definition of "raw", "processed", and "un-calibrated". Then we could provide an attribute, e.g., ProcessingState. Otherwise, we could use "ProcessingState" in the same way we use "Comments", namely, include a narrative description of the processing steps. Then we could write GLOBAL_ProcessingState = "Deconvolution with exp. sweep, windowing at ..., filtering at..." and so on. Applications which do not care, could ignore it; researchers who care could interpret it.

	In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.		In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.
			* It seems like we would need to save the IRs from speaker(s) and microphone(s) together with other metadata like levels. Would it be sufficient to store that information in a separate SOFA file? Applications which do not care, would not have this ballast. Researchers who care, could use it to reproduce all post-processing steps. A new SOFA conventions for calibration would do - Does it make sense?

	== Include room pictures ==		== Include room pictures ==

Petibub: /* Crosstalk cancellation filters (CTCFs) */

2013-05-18T17:17:12Z

Crosstalk cancellation filters (CTCFs)

← Older revision		Revision as of 19:17, 18 May 2013
Line 12:		Line 12:
	When saving HRTFs, why not save CTCFs? Check and discuss how the representation of CTCFs differs from the representation of HRTFs. It might be that SimpleFreeFieldHRIR is sufficient and the difference between HRTFs and CTCFs is simple the interpretation. Then, a note in GLOBAL_Comment might be sufficient.		When saving HRTFs, why not save CTCFs? Check and discuss how the representation of CTCFs differs from the representation of HRTFs. It might be that SimpleFreeFieldHRIR is sufficient and the difference between HRTFs and CTCFs is simple the interpretation. Then, a note in GLOBAL_Comment might be sufficient.

	At the same time, the calculation and use of CrossTalk cancellation filters goes beyond a general SOFA dataset. One can of course calculate the CTCFs filter if one wants, using various methods, but it is by no means an inherent part of the measured data, and more an application specific post-processing tool for a specific installation. It is, of course, also dependent on the speaker positions of the playback system chosen, and therefore by no ~~means~~ ~~universal~~.		At the same time, the calculation and use of CrossTalk cancellation filters goes beyond a general SOFA dataset. One can of course calculate the CTCFs filter if one wants, using various methods, but it is by no means an inherent part of the measured data, and more an application specific post-processing tool for a specific installation. It is, of course, also dependent on the speaker positions of the playback system chosen, and therefore this information should be stored within SOFA if required.

			It seems like more information from researchers about their requirements is required.

	== Include calibration data ==		== Include calibration data ==

81.65.98.52: /* Include calibration data */

2013-05-18T09:07:31Z

Include calibration data

← Older revision		Revision as of 11:07, 18 May 2013
Line 23:		Line 23:
	Corresponding researchers contacted, waiting for response...		Corresponding researchers contacted, waiting for response...

	Calibration data can hav several forms, depending on the measurement in question. If the measurement is a transfer function, and that it it's intention, then one could provide the measured transfer function of the measurement chain without the measurement object present. In the case of the HRTF, this is the measured transfer function without the head present. As there are various means of removing the effects of the measurement chain (deconvolution, spectral equalizing) the "calibrated" final data may vary between methods. If the object if to provide the data in its most raw form, for other researchers to use, the uncalibrated data, along with necessary calibration files, is of interest. In this way, the frequency response of the key elements, notably the microphone and speakers, can be both examined and taken into account. In the context of HRTF measurements which use multiple speakers, the calibration of each speaker is crucial in order to avoid spectral coloration which is independent of the head response and therefor an artifact of the measurement system. In such a case, impulse responses should be provided for each speaker, with the microphone oriented on-axis to the speaker. This can be performed with the measurement microphones used for the data acquisition, or a calibrated measurement microphone, whose model should be clearly stated. If the second is employed, a microphone measurement file is also necessary, consisting of a calibration measurement for a single speaker and the accompanying impulse response of all 3 microphones (again, in the case of and HRTF measurement). For a truly robust analysis of the data, this calibration measurement is made before and after the measurement session, to ensure no time independence of the measurement system, which is not always the case. In such a case that the before/after data do not correspond, the data should not be utilized. The actual data to be included is therefore a simple impulse response clearly annotated to indicate the microphone/speaker in question. This therefore requires in a multi-speaker measurement condition that each entry in the HRTF set includes a speaker ID.		Calibration data can hav several forms, depending on the measurement in question. If the measurement is a transfer function, and that it it's intention, then one could provide the measured transfer function of the measurement chain without the measurement object present. In the case of the HRTF, this is the measured transfer function without the head present. As there are various means of removing the effects of the measurement chain (deconvolution, spectral equalizing) the "calibrated" final data may vary between methods. If the object if to provide the data in its most raw form, for other researchers to use, the uncalibrated data, along with necessary calibration files, is of interest. In this way, the frequency response of the key elements, notably the microphone and speakers, can be both examined and taken into account. In the context of HRTF measurements which use multiple speakers, the calibration of each speaker is crucial in order to avoid spectral coloration which is independent of the head response and therefor an artifact of the measurement system. In such a case, impulse responses should be provided for each speaker, with the microphone oriented on-axis to the speaker. This can be performed with the measurement microphones used for the data acquisition, or a calibrated measurement microphone, whose model should be clearly stated. If the second is employed, a microphone measurement file is also necessary, consisting of a calibration measurement for a single speaker and the accompanying impulse response of all 3 microphones (again, in the case of and HRTF measurement). For a truly robust analysis of the data, this calibration measurement is made before and after the measurement session, to ensure no time independence of the measurement system, which is not always the case. In such a case that the before/after data do not correspond, the data should not be utilized. The actual data to be included is therefore a simple impulse response clearly annotated to indicate the microphone/speaker in question. This therefore requires in a multi-speaker measurement condition that each entry in the HRTF set includes a speaker ID. In the event that "un-calibrated", or already calibrated processed data, is provided, then there should be a clear text description indicating the calibration method used, and any addition post-treatment, such as low-frequency interpolated data (how, frequency range), equalization (diffuse field or otherwise), etc. As these different elements are clearly of more interest to researchers, rather than industrial uses, they cannot be "required elements". A simple required tag should be available indicating if the data is "raw" with accompanying calibration data, or is "processed".

	In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.		In the case of measurements where the absolute level is of importance, the calibration data is more typically that of a piston/speaker phone which provides a known SPL level. This is of specific interest when distributed microphones are employed to measure the spatial distribution of a sound field. In this instance, the calibration data can either be the noted RMS level of the calibrated source for each microphone (noting of course the model and settings of the calibrated source, and if possible, meterological conditions). To be consistent with the above mentioned HRTF case, the recorded calibration audio file could be provided, again noting the model and settings used.