Talk:SimpleHeadphoneIR - Revision history

Geronazzo.michele: /* Headphone related attributes */

2014-08-25T22:18:41Z

Headphone related attributes

← Older revision		Revision as of 00:18, 26 August 2014
Line 164:		Line 164:
	*FB: Agreed to PM3.		*FB: Agreed to PM3.
	*[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:24, 6 August 2014 (CEST): Agreed re:PM3.		*[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:24, 6 August 2014 (CEST): Agreed re:PM3.
			* MG3: smart choice, agreed. I’ve noticed that in the proposed SimpleHeadphoneIR there isn't SourceURI at measurement level, but only GLOBAL:SourceURI.


Line 171:		Line 172:
	**[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:28, 6 August 2014 (CEST) Also if you're using sine-sweeps and want to store the harmonic distortion products along with the impulse response, it would be useful to know the type of signal. But maybe that's not a common enough occurrence to worry about for these purposes.		**[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:28, 6 August 2014 (CEST) Also if you're using sine-sweeps and want to store the harmonic distortion products along with the impulse response, it would be useful to know the type of signal. But maybe that's not a common enough occurrence to worry about for these purposes.
	** PM3: I agree with Bbboren. For storing data other than IRs, I suggest to create an other datatype which would be able to store freqency-sweep responses. Then, we could create conventions which use that datatype for headphones (or maybe even for any kind of electro-acoustic device). For SimpleHeadphoneIR, I suggest to stick to IR. Agreed?		** PM3: I agree with Bbboren. For storing data other than IRs, I suggest to create an other datatype which would be able to store freqency-sweep responses. Then, we could create conventions which use that datatype for headphones (or maybe even for any kind of electro-acoustic device). For SimpleHeadphoneIR, I suggest to stick to IR. Agreed?
			** MG3: Agreed. Furthermore, just to have a clear view of the naming philosophy, you are going to call such conventions without “IR” suffix, correct?

	* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum		* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum
Line 177:		Line 179:
	** FB: I think this should be stored in GLOBAL:ReceiverDescription rather than in GLOBAL:Comments, and could provide any information found to be useful (eg. simple specification as microphone type, or publication etc.)		** FB: I think this should be stored in GLOBAL:ReceiverDescription rather than in GLOBAL:Comments, and could provide any information found to be useful (eg. simple specification as microphone type, or publication etc.)
	** PM: Agreed to FB. ReceiverDescription seems to be the perfect place. MG: do you agree?		** PM: Agreed to FB. ReceiverDescription seems to be the perfect place. MG: do you agree?
			** MG3: Agreed with both of you.

	----		----

Geronazzo.michele: /* Handling of SOFA-obligatory data */

2014-08-25T22:14:20Z

Handling of SOFA-obligatory data

← Older revision		Revision as of 00:14, 26 August 2014
Line 128:		Line 128:

	FB2: Agreed to PM2.		FB2: Agreed to PM2.

			MG3: Perfect, olè! ;)
			Just to finish this section, uff… the joint usage of HpIR+HRIR (such QU_KEMAR_anechoic_SennheiserHD25_0.5m.mat) has not to be encouraged, agree with me?

	== Headphone related attributes ==		== Headphone related attributes ==

Geronazzo.michele: /* Measurement repetition */

2014-08-25T22:10:32Z

Measurement repetition

← Older revision		Revision as of 00:10, 26 August 2014
Line 96:		Line 96:
	* MG2: I try to propose a new repetition-level attribute related to Tracking which should be quantitative and optional, of course: ''DeltaEmitterPosition'': spatial deviation from the global EmitterPosition		* MG2: I try to propose a new repetition-level attribute related to Tracking which should be quantitative and optional, of course: ''DeltaEmitterPosition'': spatial deviation from the global EmitterPosition
	* PM2: another level of spatial relation is not defined in SOFA (EmitterPosition is already in the local coordinates of SourcePosition). But that's not a problem: The mechanism you would like to see is already considered by allowing to vary EmitterPosition for each M. Agreed?		* PM2: another level of spatial relation is not defined in SOFA (EmitterPosition is already in the local coordinates of SourcePosition). But that's not a problem: The mechanism you would like to see is already considered by allowing to vary EmitterPosition for each M. Agreed?
	• MG3: Agree with PM2		* MG3: Agree with PM2

	==Handling of SOFA-obligatory data==		==Handling of SOFA-obligatory data==

Geronazzo.michele: /* Measurement repetition */

2014-08-25T21:46:23Z

Measurement repetition

← Older revision		Revision as of 23:46, 25 August 2014
Line 75:		Line 75:
	** PM3: It's not a problem. If you don't know the exact position of Emitters, just leave it at default. When repeating the measurement, the time will only change. In the comments, you still can describe if and how the repositioning was done. Agreed?		** PM3: It's not a problem. If you don't know the exact position of Emitters, just leave it at default. When repeating the measurement, the time will only change. In the comments, you still can describe if and how the repositioning was done. Agreed?
	** FB3: Agree to PM3		** FB3: Agree to PM3
			** MG3: Agreed

	Measurement-specific attributes:		Measurement-specific attributes:
Line 95:		Line 96:
	* MG2: I try to propose a new repetition-level attribute related to Tracking which should be quantitative and optional, of course: ''DeltaEmitterPosition'': spatial deviation from the global EmitterPosition		* MG2: I try to propose a new repetition-level attribute related to Tracking which should be quantitative and optional, of course: ''DeltaEmitterPosition'': spatial deviation from the global EmitterPosition
	* PM2: another level of spatial relation is not defined in SOFA (EmitterPosition is already in the local coordinates of SourcePosition). But that's not a problem: The mechanism you would like to see is already considered by allowing to vary EmitterPosition for each M. Agreed?		* PM2: another level of spatial relation is not defined in SOFA (EmitterPosition is already in the local coordinates of SourcePosition). But that's not a problem: The mechanism you would like to see is already considered by allowing to vary EmitterPosition for each M. Agreed?
			• MG3: Agree with PM2

	==Handling of SOFA-obligatory data==		==Handling of SOFA-obligatory data==

Geronazzo.michele: /* Single subject vs multiple subjects */

2014-08-25T21:45:15Z

Single subject vs multiple subjects

← Older revision		Revision as of 23:45, 25 August 2014
Line 26:		Line 26:
	For other issues, see the following sections.		For other issues, see the following sections.

			==Subject/Headphone correspondences==
	==Single subject vs multiple subjects==
	At the moment, all SOFA files are for a single subject, i.e., one subject --> one file. For HpIRs, it makes sense to have a file containing data from several subjects, i.e., many subjects --> one file. What do you think? How would you like to deal with that issue?		At the moment, all SOFA files are for a single subject, i.e., one subject --> one file. For HpIRs, it makes sense to have a file containing data from several subjects, i.e., many subjects --> one file. What do you think? How would you like to deal with that issue?

Line 45:		Line 45:

	FB: agree		FB: agree

			MG3: Now, with string-array support, things become easier. Agreed.
			Moreover, we can define "one headphones --> many subjects" with different ListenerShortName and ListenerDescriptions (not GLOBAL:). What do you think about it?

	==Measurement repetition==		==Measurement repetition==

Geronazzo.michele: /* General */

2014-08-25T21:32:14Z

General

← Older revision		Revision as of 23:32, 25 August 2014
Line 17:		Line 17:
	** MG2: I agree with you. The better solution should be b) a new convention. Moreover, I feel that this convention is tightly connected with what we called: ''equalization filters for a one-to-one correspondence between transmitters and receivers''. Am I correct? Thus I suggest for the future something similar to ''EqSingleHedphoneFIR''.		** MG2: I agree with you. The better solution should be b) a new convention. Moreover, I feel that this convention is tightly connected with what we called: ''equalization filters for a one-to-one correspondence between transmitters and receivers''. Am I correct? Thus I suggest for the future something similar to ''EqSingleHedphoneFIR''.
	** PM2: I understand MG2. My suggestion: Let's define the headphones conventions and then discuss the difference between the equ IRs and the HpIRs.		** PM2: I understand MG2. My suggestion: Let's define the headphones conventions and then discuss the difference between the equ IRs and the HpIRs.
			** MG3: Absolutely agreed.

	At the moment, the simple case is to have one-to-one correspondence. We could work on that first, and then think about multiple subjects in a file for both measured, inverted and equalized filters. We would need a clear and consistent definition for HeadphoneIR first.		At the moment, the simple case is to have one-to-one correspondence. We could work on that first, and then think about multiple subjects in a file for both measured, inverted and equalized filters. We would need a clear and consistent definition for HeadphoneIR first.

Petibub: /* Headphone related attributes */

2014-08-11T09:50:05Z

Headphone related attributes

← Older revision		Revision as of 11:50, 11 August 2014
Line 161:		Line 161:
	** PM2: In SimpleFreeFieldHRIR, we store impulse responses.		** PM2: In SimpleFreeFieldHRIR, we store impulse responses.
	**[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:28, 6 August 2014 (CEST) Also if you're using sine-sweeps and want to store the harmonic distortion products along with the impulse response, it would be useful to know the type of signal. But maybe that's not a common enough occurrence to worry about for these purposes.		**[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:28, 6 August 2014 (CEST) Also if you're using sine-sweeps and want to store the harmonic distortion products along with the impulse response, it would be useful to know the type of signal. But maybe that's not a common enough occurrence to worry about for these purposes.
			** PM3: I agree with Bbboren. For storing data other than IRs, I suggest to create an other datatype which would be able to store freqency-sweep responses. Then, we could create conventions which use that datatype for headphones (or maybe even for any kind of electro-acoustic device). For SimpleHeadphoneIR, I suggest to stick to IR. Agreed?

	* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum		* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum

Bbboren: /* Headphone related attributes */

2014-08-06T16:28:35Z

Headphone related attributes

← Older revision		Revision as of 18:28, 6 August 2014
Line 153:		Line 153:
	PM3: With manufacturer and model, a meta analysis can be performed by using the headphone specs provided by the manufacturer. I'm afraid that including too much information on the headphone specs in the SOFA files (which actually should contain IRs only) will lead to an inconsistency. Further, attributes like EarCup or FormFactor must be optional, because we cannot ensure that everybody will have these data or know what would be the appropriate values. By storing the manufacturer and the type in the SOFA file, the link to the corresponding specs will be unique anyway. So providing more information than manufacturer/model does not help. I thus suggest to store specs and IRs in separate files. If you think that it is not clear what specs are describing the measured headphones, we could provide a link to the particular specs file. For example, for the specs of Sennheiser HD 520 II, we could store SourceURI = 'http://mypdfmanuals.com/user-manual,SENNHEISER,HD%2B520+II,3708267.pdf '. This way, we would avoid inconsistencies because the meta data would always correspond to those given by the manufacturer. And, in the case of having specs which differ from the manufacturer specs, one could provide a link to a custom-made specs file. Note that you still can provide more attributes, however, they don't have to be defined in conventions.		PM3: With manufacturer and model, a meta analysis can be performed by using the headphone specs provided by the manufacturer. I'm afraid that including too much information on the headphone specs in the SOFA files (which actually should contain IRs only) will lead to an inconsistency. Further, attributes like EarCup or FormFactor must be optional, because we cannot ensure that everybody will have these data or know what would be the appropriate values. By storing the manufacturer and the type in the SOFA file, the link to the corresponding specs will be unique anyway. So providing more information than manufacturer/model does not help. I thus suggest to store specs and IRs in separate files. If you think that it is not clear what specs are describing the measured headphones, we could provide a link to the particular specs file. For example, for the specs of Sennheiser HD 520 II, we could store SourceURI = 'http://mypdfmanuals.com/user-manual,SENNHEISER,HD%2B520+II,3708267.pdf '. This way, we would avoid inconsistencies because the meta data would always correspond to those given by the manufacturer. And, in the case of having specs which differ from the manufacturer specs, one could provide a link to a custom-made specs file. Note that you still can provide more attributes, however, they don't have to be defined in conventions.

	FB: Agreed to PM3.		*FB: Agreed to PM3.
		⚫	*[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:24, 6 August 2014 (CEST): Agreed re:PM3.

⚫	[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:24, 6 August 2014 (CEST): Agreed re:PM3.


Line 161:		Line 160:
	** MG2: This attribute is useless if we consider the IR. But, if I want to store raw data, i.e. recordings without processing, we need to specify the stimulus type, e.g. a sine sweep response. How have you handled this issue in the SimpleFreeFieldHRIR convention? I’m probably missing something here...		** MG2: This attribute is useless if we consider the IR. But, if I want to store raw data, i.e. recordings without processing, we need to specify the stimulus type, e.g. a sine sweep response. How have you handled this issue in the SimpleFreeFieldHRIR convention? I’m probably missing something here...
	** PM2: In SimpleFreeFieldHRIR, we store impulse responses.		** PM2: In SimpleFreeFieldHRIR, we store impulse responses.
			**[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:28, 6 August 2014 (CEST) Also if you're using sine-sweeps and want to store the harmonic distortion products along with the impulse response, it would be useful to know the type of signal. But maybe that's not a common enough occurrence to worry about for these purposes.

	* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum		* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum

Bbboren: /* Headphone related attributes */

2014-08-06T16:24:32Z

Headphone related attributes

← Older revision		Revision as of 18:24, 6 August 2014
Line 155:		Line 155:
	FB: Agreed to PM3.		FB: Agreed to PM3.

			[[User:Bbboren\|Bbboren]] ([[User talk:Bbboren\|talk]]) 18:24, 6 August 2014 (CEST): Agreed re:PM3.

Fbrinkmann: /* Measurement repetition */

2014-07-30T12:19:29Z

Measurement repetition

← Older revision		Revision as of 14:19, 30 July 2014
Line 70:		Line 70:
	** FB2: I understand your point, but I don't see how we can determine the exact EmitterPosition as it is defined now (with respect to the ListenerPosition = interaural center) and I did not find a solution to this in the Tracking section. I would have two practical workarounds to this: either add some random numbers to the (assumed) emitter position [0 -0.09 0; 0 0.09 0] (not elegant?), or further specification in GLOBAL:comment : singe subject, single/multiple headphone/s with/without repositioning.		** FB2: I understand your point, but I don't see how we can determine the exact EmitterPosition as it is defined now (with respect to the ListenerPosition = interaural center) and I did not find a solution to this in the Tracking section. I would have two practical workarounds to this: either add some random numbers to the (assumed) emitter position [0 -0.09 0; 0 0.09 0] (not elegant?), or further specification in GLOBAL:comment : singe subject, single/multiple headphone/s with/without repositioning.
	** PM3: It's not a problem. If you don't know the exact position of Emitters, just leave it at default. When repeating the measurement, the time will only change. In the comments, you still can describe if and how the repositioning was done. Agreed?		** PM3: It's not a problem. If you don't know the exact position of Emitters, just leave it at default. When repeating the measurement, the time will only change. In the comments, you still can describe if and how the repositioning was done. Agreed?
			** FB3: Agree to PM3

	Measurement-specific attributes:		Measurement-specific attributes: