Talk:SimpleHeadphoneIR

General

We actually want to store headphone IRs. Here is the summary of the discussion until now about the general way how can we represent measurements with headphones in SOFA:

• Unmerged: When measuring headphones, we have two headphones (=two transmitters, T1 and T2) and we have two mics places in the ears (=two receivers, R1 and R2). For the first measurement: T1-->R1,R2; next measurement: T2-->R1, R2. So, the IRs T1-->R1 and T2-->R2 are the interesting ones and are usually further processed. But we also have the uninteresting IRs T1-->R2 and T2-->R1. They represent the cross-talk data, which we actually do not use, but we store them! And we could use SOFA for storing them. This could be covered by the conventions GeneralFIR.
• Merged: Now, for any further processing purposes, we are usually interested just in two IRs: #1: T1 --> R1 and #2: T2 --> R2. Thus, the number of receivers (here: 2) defines the number of IRs and transmitters, with a strict one-to-one correspondence between transmitters and receivers. I think that this could be the main property of HeadphoneIR: a strict one-to-one correspondence between transmitters and receivers.
• Raw: I think that that's the "merged", is it?
• Equalization: Maybe this means that frequency responses of recording microphones were equalized?
• Inverted: In most cases, the merged HeadphoneIR data is used to design a headphone filter by inverting the HeadphoneIRs. This filter is then used for equalizing (cancelling out) the transfer function of the headphone during auralization. It might be good to store the inverted HeadphoneIRs because (a) the inversion itself is not trivial and others could use the filters without having to think about the proccesing, (b) documentation of an inversion method in conjunction with Matlab/C/Java-code -> reproducable research. There are two possibilities in dealing with the inverted IRs (a) storing merged and inverted Data in the same SOFA object and (b) storing them in separate objects. (a) might be difficult to handle because there usually is only one headphone filter altough there might be many HeadphoneIRs. Both, merged and inverted IRs could be saved in Data.IR and meta data could be used to tell what IR is inverted. This, however might be confusing. (b) can be achieved by matching subject IDs and description across objects holding merged and inverted data, wich can easily be done.

It seems like the one-to-one correspondence is the major property which clearly defines our HeadphoneIR conventions. So, this is how I see HeadphonesIR:

• How is a headphone represented in HeadphoneIR? The headphones as the product is represented by the Source, the individual headphones' drivers are represented by the Emitters.
• What is special on HeadphoneIR compared to, say, GeneralFIR? It is the one-to-one correspondence between the Emitters and the Receivers.

For other issues, see the following sections.

Single subject vs multiple subjecs

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?

FBrinkmann: Note that the above mentioned case is the most common, but there might also be the case that we want to save HeadphoneIRs for one subject but different types of headphones (For example when trying to find headphone filters best matching a set of different headphone types).

Measurement repetition

Usually, when a measurement is repeated, something in the measurement setup changes. For example, for HRTF measurements, we change the direction of the source and repeat the measurement. In the SOFA file, this is noted as a different entry in SourcePosition.

Now, for HpIR, we have multiple measurements, which are just repetitions, i.e., the subjects put the HP on, we measure, the subjects takes the HP down, put it on again, we re-measure, and so on. What changes it the time, and the counter of the performed measurement. Neither the subject changes nor the Source, Emitter, Listener, Receiver attributes.

My question:

• do you also have this issue? How do you deal with that? How would you like to consider that in SOFA conventions?
  • FBrinkmann: At the moment we store our IRs as separate wav/mat files with consecutive numbering - wich is not an option for SOFA.

• At the moment, I suggest to have a variable called MeasurementTimeCreated in which, for each measurement, the date/time of the corresponding measurement would be stored.
  • FBrinkmann: I would suggest to save identical MeasurementTime Created for HeadphoneIRs measured on the same day and subject. This makes the data look somehow simpler, and I don't see a large advantage in saving exact times for each IR.

• Further, a variable called MeasurementDescription, in which, for each measurement, a string containing description of the corresponding measurement, would be stored. Note that we'd need string arrays in such a case, a feature currently not implemented in the Matlab API.
  • FBrinkmann: I think MeasurementDescription is already covered by the GLOBAL variables suggested in the HeadphoneIR convention version 0.1 - or do I miss something? In most cases it might be sufficient to specify these meta data entries once because the setup usually does not change. In this case we won't need string arrays. However having string arrays available (without knowing about the amount of work this would take) would make things way more flexible. This would for example make it possible to save IRs for one subject but different types of headphones.

Handling of SOFA-obligatory data

• SourcePosition:
  • Suggestion 1: a fictive sound source position (example given: 0.5 m in front of the listener). The definition of the virtual position is unclear yet. The choice for the distance needs to be defined.
  • Suggestion 2: the actual position of the headphones, usually congruent with ListenerPosition
    • FBrinkmann: I prefer 2
• EmitterPosition:
  • Suggestion 1: the actual position of the headphone drivers, according to SOFA rules must be relative to the SourcePosition.
    • FBrinkmann: I agree. I think this is already included in the conventions 0.1 draft -> EmitterPosition = [0 -0.09 0; 0 0.09 0]

Headphone related attributes

The naming of the headphone related attributes needs to be clarified. The attributes proposed so far are (t.b.d.: to be defined):

• Producer:
• Model: t.b.d
• FormFactor: t.b.d.
  • FBrinkmann: What do you mean by this?
• EarcupDesign: t.b.d.
• Technology: t.b.d
  • FBrinkmann: What do you mean by this?
• FrequencyResponse: t.b.d.
  • FBrinkmann: IMHO not needed (see comment below)
• Sensitivity: t.b.d
• the stimulus type (e.g. sine sweep): t.b.d
• qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum
• Tracking headphones position, once put on, is a challenging issue, but sometimes it's possible to give a label to the each repositionament e.g. simple labels: comfortable, not comfortable. t.b.d
  • FBrinkmann: It might be hard to establish comparability of the suggested labels (comfortable, not comfortable...) across subjects and research institutes (what does comfortable mean, where does not comfortable start?). Moreover, I'm not sure about the relevance of these labels: What does it tell us about the IR if the position was comfortable (I think most headphones available are comfortable to wear)? In my opinion the goodness of the headphone position is best reflected by the repeatability: Good positioning means little variance across repeated measurements of the same subject. I thus tend to dismiss this attribute.

These attributes should be defined, and also the ambiguity should be reduced. For example, what does "FrequencyResponse" tell when we store the IRs in the numeric way in the same file anyway. When we provide the same information twice, which overrides which?

FBrinkmann: I find the attributes suggested in the draft 0.1 to be very reasonable already, and would suggest to use them and maybe add Sensitivity and Tracking of headphone position

Further, the structure of the attributes should be defined as well: Candidates (with XXX being one of the above-stated attributes):

• Headphones.XXX does not work because SOFA does not allow nested structures.
• GLOBAL_HeadphonesXXX is allowed, but the difference to SourceXXX should be clearly defined then.
• In SOFA, the headphones are represented by the object Source. Thus, we could use GLOBAL_SourceXXX.
  • FBrinkmann: I am in favour of this.