== Description ==

FreeFieldDirectivityTF is a convention for storing directivity of acoustic sources (instruments, loudspeakers, singers, talkers, etc) in the frequency domain for multiple musical notes. We consider free-field directivites only, i.e., assuming that a potential room has no effect on the data. We consider musical notes as a parameter directly addressing musical instruments. The applications can be:

* '''Musical acoustics:''' When measuring of directivity of instruments, this convention can be used for storing the directivity data, which then can be used for general research in musical acoustics.
* '''Room-acoustic simulations:''' When rendering acoustic scenes combined with simulations of the room acoustics, this convention can provide the directivity data for more realistic auralizations.

A simple setting assumes that the acoustic source under consideration is surrounded by many microphones capturing the signal emitted by the source from different spatial directions. To this end, we define the following:

* '''Source''' represents the acoustic source under consideration.
* '''Emitters''' represent a more detailed structure of the Source. In a simple settings, a single Emitter is considered that is collocated with the source.
* '''Receivers''' represent the microphones capturing the sound from the acoustic source
* '''Listener''' represents the array of microphones. In a simple setting, the position of the Listener is collocated with the position of the Source.
* '''Data''' stores the captured signals. The data is saved as complex numbers in Data.Real and Data.Imag at the N spectral frequencies for R receivers and M measurements.
* '''TuningFrequency''' describes the tuning frequency the instrument is tuned to (in Hertz).
* '''MIDINote''' describes the note the acoustic source was playing. The note is specified as MIDI notes according to the [https://www.midi.org/specifications-old/item/the-midi-1-0-specification MIDI specification, version 1.0]. Note that a note of 69 refers to A4, which corresponds to the frequency specified by TuningFrequency. Note also that both TuningFrequency and MIDINote can be omitted when not required, e.g., for atonal sources such as loudspeakers.
* '''Measurement''' captures a modification of the directivity condition:
** Modified orientation of the microphone array during the measurement? The ListenerView and ListenerUp will change.
** Another musical note played during the measurement? The MIDINote will change.
** Another direction of the directivity required for auralization? Search for the proper ReceiverPosition (in a postprocessed dataset with a single ListenerView) or for a spatial superposition of ListenerView, ListenerUp, and ReceiverPosition (in a dataset with raw measurements).

'''Examples for the data representation of musical sources:'''
* '''Full spectrum and atonal instrument:''' The directivity of a cymbal, saved as a discrete single-sided spectrum for equidistant frequencies between 0 Hz and the Nyquist frequency. The played notes refer to different playing styles of the cymbal (different strength or hitting locations). Data.N represents the frequencies which are identical for each Measurement such as played note and direction.
* '''Full spectrum and tonal instrument:''' Signal of a violin (single tones, scales, or complete pieces), saved as a discrete single-sided spectrum for equidistant frequencies between 0 Hz and the Nyquist frequency. Data.N represents the frequencies which are identical for each measured condition. Such data are raw data from which directivities can be computed in a post-processing step.
* '''Harmonic spectrum:''' The directivity of a violin, saved for each harmonic frequency beginning with the fundamental frequency and ending at (N-1)th overtone of each played note. Data.N represents the index to a harmonic frequency with respect to the fundamental frequency described by MIDINote and TuningFrequency.
* '''Fractional octave spectrum:''' The directivity of a violin, with the spectrum represented by a few N fractional octaves. Data.N represents frequencies which are identical for each Measurement such as played note and direction. The data are post processed such that the spatial parameters of the Source and Listener are constant and the directivity is encoded in ReceiverPosition only. This format is intended to be used by room-acoustic simulations. Note that is might simplify the original representation of the measurement.
* '''Moving instrument:''' The influence of the musician on the directivity of the musician and/or the instrument. To this end, the spatial relation between the musician/instrument (=Source) and the microphones (Listener/Receivers) is important and thus represented in the metadata. The data can be captured by repeated recordings of the same note/scale/piece for different positions of the listener/instrument. Note that this is a complex scenario and thus yield a complex representation.
In all the above cases, there is no connection between the number of emitters and measurements. The number of emitters will most likely be e=1, but can have other values, for example if the positions where a cymbal was hit should be described in detail.

'''Examples for the data representation of loudspeakers:'''
* '''Two-way loudspeaker:''' Combined directivity of a two-way speaker, i.e., the low-frequency unit (emitter) and mid/high-frequency unit are measured together. In this case, the number of emitters should be e=2. The number of measurements is most likely m=1. It could have other values, for example if the directivity is specified for different input levels, which can be specified in Description.
* '''Two-way loudspeaker:''' Separate directivities of the low-frequency unit (emitter) and mid/high-frequency unit (emitter) of a loudspeaker. In this case the number of emitters and measurements should be '''e=m=2'''. Although it is possible to have multiple measurements for each emitter, this is not recommended.

Additional metadata is considered to more coherently describe the dataset:
* '''SourcePosition:Reference''', '''SourceView:Reference''', and '''SourceUp:Reference''' provide a narrative description about the spatial reference of the source, e.g. for the trumpet, 'The bell', 'Viewing direction of the bell', and 'Along the keys, keys up' for SourcePosition:Reference, SourceView:Reference, and SourceUp:Reference, respectively. Mandatory in order to provide a reference across different instruments.
* '''Description''' provides a narrative description of each measurement, which is highly recommend for documenting the data. This might be the note, the musical dynamic (pp., ff., etc.), the string on which the note was played, the playing style (pizzicato, legato, etc.), or the location at which a cymbal was hit. NoteDescription is optional and can be provided individually for each Measurement when required.
* '''GLOBAL:Musician''' provides a narrative description of the musician such as position, behavior, or personal data if not data-protected.

== Version 0.2 ==
This version uses the more general Object metadata (instead of NoteDescription).

{| border="1"
!Name
!Default
!Flags
!Dimensions
!Type
!Comment
|-
|GLOBAL:Conventions||<nowiki>SOFA</nowiki>||rm||||attribute||
|-
|GLOBAL:Version||<nowiki>1.0</nowiki>||rm||||attribute||
|-
|GLOBAL:SOFAConventions||<nowiki>FreeFieldDirectivityTF</nowiki>||rm||||attribute||This conventions stores directivities of acoustic sources (instruments, loudspeakers, singers, talkers, etc) in the frequency domain for multiple musical notes in free field.
|-
|GLOBAL:SOFAConventionsVersion||<nowiki>0.2</nowiki>||rm||||attribute||
|-
|GLOBAL:APIName||<nowiki></nowiki>||rm||||attribute||
|-
|GLOBAL:APIVersion||<nowiki></nowiki>||rm||||attribute||
|-
|GLOBAL:ApplicationName||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:ApplicationVersion||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:AuthorContact||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:Comment||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:DataType||<nowiki>TF</nowiki>||rm||||attribute||We store frequency-dependent data here
|-
|GLOBAL:History||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:License||<nowiki>No license provided, ask the author for permission</nowiki>||m||||attribute||
|-
|GLOBAL:Organization||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:References||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:RoomType||<nowiki>free field</nowiki>||m||||attribute||The room information can be arbitrary, but the spatial setup assumes free field.
|-
|GLOBAL:Origin||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:DateCreated||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:DateModified||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:Title||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:InstrumentType||<nowiki></nowiki>||m||||attribute||Narrative description of the acoustic source, e.g., 'Violin' or 'Human'
|-
|GLOBAL:InstrumentManufacturer||<nowiki></nowiki>||m||||attribute||Narrative description of the manufacturer of the source, e.g., 'Stradivari, Lady Blunt, 1721'
|-
|GLOBAL:Musician||<nowiki></nowiki>||m||||attribute||Narrative description of the musician such as position, behavior, or personal data if not data-protected, e.g., 'Christiane Schmidt sitting on the chair', or 'artificial excitation by R2D2'.
|-
|ListenerPosition||<nowiki>[0 0 0] </nowiki>||m||IC, MC||double||Position of the microphone array during the measurements.
|-
|ListenerPosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|ListenerPosition:Units||<nowiki>metre</nowiki>||m||||attribute||
|-
|ListenerView||<nowiki>[0 0 1]</nowiki>||m||IC, MC||double||Orientation of the microphone array
|-
|ListenerView:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|ListenerView:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|ListenerUp||<nowiki>[0 90 1]</nowiki>||m||IC, MC||double||Up vector of the microphone array
|-
|ListenerUp:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|ListenerUp:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|ReceiverPosition||<nowiki>[0 0 0]</nowiki>||m||rCI, rCM||double||Positions of the microphones during the measurements (relative to the Listener)
|-
|ReceiverPosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|ReceiverPosition:Units||<nowiki>metre</nowiki>||m||||attribute||
|-
|SourcePosition||<nowiki>[0 0 0] </nowiki>||m||IC, MC||double||Position of the acoustic source (instrument)
|-
|SourcePosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|SourcePosition:Units||<nowiki>metre</nowiki>||m||||attribute||
|-
|SourcePosition:Reference||<nowiki></nowiki>||m||||attribute||Narrative description of the spatial reference of the source position, e.g., for the trumpet, ‘The bell’. Mandatory in order to provide a reference across different instruments
|-
|SourceView||<nowiki>[0 0 1]</nowiki>||m||IC, MC||double||Orientation of the acoustic source (instrument)
|-
|SourceView:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|SourceView:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|SourceView:Reference||<nowiki></nowiki>||m||||attribute||Narrative description of the spatial reference of the source view, e.g., for the trumpet, ‘Viewing direction of the bell’. Mandatory in order to provide a reference across different instruments
|-
|SourceUp||<nowiki>[0 90 1]</nowiki>||m||IC, MC||double||Up vector of the acoustic source (instrument)
|-
|SourceUp:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|SourceUp:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|SourceUp:Reference||<nowiki></nowiki>||m||||attribute||Narrative description of the spatial reference of the source up, e.g., for the trumpet, ‘Along the keys, keys up’. Mandatory in order to provide a reference across different instruments
|-
|EmitterPosition||<nowiki>[0 0 0]</nowiki>||m||eCI||double||A more detailed structure of the Source. In a simple settings, a single Emitter is considered that is collocated with the source.
|-
|EmitterPosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|EmitterPosition:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|MIDINote||<nowiki></nowiki>||||I, M||double||Defines the note played by the source during the measurement. The note is specified a MIDI note by the [https://www.midi.org/specifications-old/item/the-midi-1-0-specification MIDI specifications, version 1.0]. Not mandatory, but recommended for tonal instruments.
|-
|Description||<nowiki></nowiki>||||IS, MS||attribute||Narrative description of a measurement (recommend for documenting the data), e.g., the note, the musical dynamic (pp., ff., etc.), the string on which the note was played, the playing style (pizzicato, legato, etc.), or the location at which a cymbal was hit.
|-
|TuningFrequency||<nowiki></nowiki>||||I, M||double||Defines the frequency (in Hertz) the instrument is tuned to during the measurements corresponding to the note A4 (MIDINote = 69).
|-
|Data.Real||<nowiki>0</nowiki>||m||mRn||double||The real part of the complex-valued spectrum
|-
|Data.Imag||<nowiki>0</nowiki>||m||MRN||double||The imaginary part of the complex-valued spectrum
|-
|N||<nowiki>0</nowiki>||m||N||double||Frequencies of the considered spectral bands
|-
|N:LongName||<nowiki>frequency</nowiki>||m||||attribute||
|-
|N:Units||<nowiki>Hertz</nowiki>||m||||attribute||Unit of the values given in N
|}

== Version 0.1 ==
This version uses SOFA 1.0 which reflects the AES69-2015 standard.

{| border="1"
!Name
!Default
!Flags
!Dimensions
!Type
!Comment
|-
|GLOBAL:Conventions||<nowiki>SOFA</nowiki>||rm||||attribute||
|-
|GLOBAL:Version||<nowiki>1.0</nowiki>||rm||||attribute||
|-
|GLOBAL:SOFAConventions||<nowiki>FreeFieldDirectivityTF</nowiki>||rm||||attribute||This conventions stores directivities of acoustic sources (instruments, loudspeakers, singers, talkers, etc) in the frequency domain for multiple musical notes in free field.
|-
|GLOBAL:SOFAConventionsVersion||<nowiki>0.1</nowiki>||rm||||attribute||
|-
|GLOBAL:APIName||<nowiki></nowiki>||rm||||attribute||
|-
|GLOBAL:APIVersion||<nowiki></nowiki>||rm||||attribute||
|-
|GLOBAL:ApplicationName||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:ApplicationVersion||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:AuthorContact||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:Comment||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:DataType||<nowiki>TF</nowiki>||rm||||attribute||We store frequency-dependent data here
|-
|GLOBAL:History||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:License||<nowiki>No license provided, ask the author for permission</nowiki>||m||||attribute||
|-
|GLOBAL:Organization||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:References||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:RoomType||<nowiki>free field</nowiki>||m||||attribute||The room information can be arbitrary, but the spatial setup assumes free field.
|-
|GLOBAL:Origin||<nowiki></nowiki>||||||attribute||
|-
|GLOBAL:DateCreated||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:DateModified||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:Title||<nowiki></nowiki>||m||||attribute||
|-
|GLOBAL:InstrumentType||<nowiki></nowiki>||m||||attribute||Narrative description of the acoustic source, e.g., 'Violin' or 'Human'
|-
|GLOBAL:InstrumentManufacturer||<nowiki></nowiki>||m||||attribute||Narrative description of the manufacturer of the source, e.g., 'Stradivari, Lady Blunt, 1721'
|-
|GLOBAL:Musician||<nowiki></nowiki>||m||||attribute||Narrative description of the musician such as position, behavior, or personal data if not data-protected, e.g., 'Christiane Schmidt sitting on the chair', or 'artificial excitation by R2D2'.
|-
|ListenerPosition||<nowiki>[0 0 0] </nowiki>||m||IC, MC||double||Position of the microphone array during the measurements.
|-
|ListenerPosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|ListenerPosition:Units||<nowiki>metre</nowiki>||m||||attribute||
|-
|ListenerView||<nowiki>[0 0 1]</nowiki>||m||IC, MC||double||Orientation of the microphone array
|-
|ListenerView:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|ListenerView:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|ListenerUp||<nowiki>[0 90 1]</nowiki>||m||IC, MC||double||Up vector of the microphone array
|-
|ListenerUp:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|ListenerUp:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|ReceiverPosition||<nowiki>[0 0 0]</nowiki>||m||rCI, rCM||double||Positions of the microphones during the measurements (relative to the Listener)
|-
|ReceiverPosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|ReceiverPosition:Units||<nowiki>metre</nowiki>||m||||attribute||
|-
|SourcePosition||<nowiki>[0 0 0] </nowiki>||m||IC, MC||double||Position of the acoustic source (instrument)
|-
|SourcePosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|SourcePosition:Units||<nowiki>metre</nowiki>||m||||attribute||
|-
|SourcePosition:Reference||<nowiki></nowiki>||m||||attribute||Narrative description of the spatial reference of the source position, e.g., for the trumpet, ‘The bell’. Mandatory in order to provide a reference across different instruments
|-
|SourceView||<nowiki>[0 0 1]</nowiki>||m||IC, MC||double||Orientation of the acoustic source (instrument)
|-
|SourceView:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|SourceView:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|SourceView:Reference||<nowiki></nowiki>||m||||attribute||Narrative description of the spatial reference of the source view, e.g., for the trumpet, ‘Viewing direction of the bell’. Mandatory in order to provide a reference across different instruments
|-
|SourceUp||<nowiki>[0 90 1]</nowiki>||m||IC, MC||double||Up vector of the acoustic source (instrument)
|-
|SourceUp:Type||<nowiki>spherical</nowiki>||m||||attribute||
|-
|SourceUp:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|SourceUp:Reference||<nowiki></nowiki>||m||||attribute||Narrative description of the spatial reference of the source up, e.g., for the trumpet, ‘Along the keys, keys up’. Mandatory in order to provide a reference across different instruments
|-
|EmitterPosition||<nowiki>[0 0 0]</nowiki>||m||eCI||double||A more detailed structure of the Source. In a simple settings, a single Emitter is considered that is collocated with the source.
|-
|EmitterPosition:Type||<nowiki>cartesian</nowiki>||m||||attribute||
|-
|EmitterPosition:Units||<nowiki>degree, degree, metre</nowiki>||m||||attribute||
|-
|MIDINote||<nowiki></nowiki>||||I, M||double||Defines the note played by the source during the measurement. The note is specified a MIDI note by the [https://www.midi.org/specifications-old/item/the-midi-1-0-specification MIDI specifications, version 1.0]. Not mandatory, but recommended for tonal instruments.
|-
|MIDINoteDescription||<nowiki></nowiki>||||IS, MS||attribute||Narrative description of a note (recommend for documenting the data), e.g., the musical dynamic (pp., ff., etc.), the string on which the note was played, the playing style (pizzicato, legato, etc.), or the location at which a cymbal was hit.
|-
|TuningFrequency||<nowiki></nowiki>||||I, M||double||Defines the frequency (in Hertz) the instrument is tuned to during the measurements corresponding to the note A4 (MIDINote = 69).
|-
|Data.Real||<nowiki>0</nowiki>||m||mRn||double||The real part of the complex-valued spectrum
|-
|Data.Imag||<nowiki>0</nowiki>||m||MRN||double||The imaginary part of the complex-valued spectrum
|-
|N||<nowiki>0</nowiki>||m||N||double||Frequencies of the considered spectral bands
|-
|N:LongName||<nowiki>frequency</nowiki>||m||||attribute||
|-
|N:Units||<nowiki>Hertz</nowiki>||m||||attribute||Unit of the values given in N
|}

Fbrinkmann: /* Single subject vs multiple subjects */

==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 and compensated IRs (Merged) : they share the same representation, except the information used to obtain the compensated signals from the raw ones.
**Raw: data from the recordings.
**Compensated: inverse filtering of the stimulus plus free-field/diffuse-field compensation in order to extrapolate the impulse response. It can be approximately seen as DTFs from HRTFs.
* Equalization: we can think of storing equalization filters for different techniques. For a specific headphone model, we could have these equalization filters:
**a one-to-one correspondence between transmitters and receivers (e.g. single measurement equalization)
**a one-to-all repetitions for a specific subject (e.g. mean equalization)
**a one-to-all repetitions for all the available subjects and, in the further development, grouping similar headphones (e.g. machine learning approach)
* 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.
** PM: It seems to me like the "inverted HpIR" is not a HpIR but a filter used for filtering sounds. So, I suggest to not use SingleHeadphoneIR for storing filters. Instead I suggest 1) for the moment to use GeneralFIR and 2) later define new conventions which clearly state what is special on that filters.
** 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.

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.
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 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?

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).

MG: Fabian’s observation sounds very desirable. Following his suggestion, the focus moves from headphones to subjects/group of headphones which is fine for me but conceptually merits a different convention. Let’s call it something similar to ''GroupHeaphoneIR''.

PM: Agreed: then, we should call these conventions ''SingleHeadphoneIR''.

MG2: further steps… (a rough sketch)

''MultipleHeadphoneIR'': one headphones --> many subjects

''GroupHeaphoneIR'': one subject --> many headphones

PM2: one subject --> many headphones is equivalent to one subject --> repeated measurements of any headphones. Thus, I suggest to consider this case as measurement repetition. I further propose to change the name to ''SimpleHeadphoneIR'', because ''Single'' is ambiguous (it is not clear to what single refers to: subject or measurement, and it implies single headphones, which is definitely not the case). But we have conventions ''SimpleFreeFieldHRIR'' which also always consider a single subject and repeated measurements. Thus ''SimpleHeadphoneIR'' directly corresponds to ''SimpleFreeFieldHRIR''. I already created a short description on the main page. I hope that you agree...

FB: agree

==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.
**MG: I’ve suggested so far to store repetition on Obj.Data.IR = NaN(M,R,N); M repetitions, R channels and N samples.
** PM: Agreed.

*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.
**MG: Practically speaking, I agree with Fabian but we lose generality. One subject could perform several recording sessions made in different days and years. Subjects change their ear shape over time providing different acoustic contribution to HpIRs.
**PM: MeasurementDate (sorry, it's called Date, not Time, my mistake) save the date and the time using the number of seconds from 1970-01-01 00:00:00. So the actual time will be provided anyway. If you agree, we define MeasurementDate to be optional.
**MG2: Agreed. One can manage timestamps as he/she prefers.

*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.
**MG: the use of several MeasurementDescription leads to a huge amount of redundant data because the setup usually does not change, as Fabian said. Different consideration should be noted with the case of single subject and different headphones which produces my comment on section ''single subject vs. multiple subject''
** PM: guys, so what I don't understand then, is the following: we'll have many measurements in the file, but we do not provide any information (but the MeasurementDate) about what is different in the measurements? How do I know distinguish between the measurements then?
** MG2: I’ve got the point! What actually changes among measurements (with same setup) is the emitter positions. Following this observation we might move here at repetition-level the discussion on Tracking. Do you agree with me?
** PM2: Agreed. So, which attributes would you like to have as global attributes, i.e., one entry per file; and which as measurement-specific attributes, i.e., for each measurement a separate entry?

Measurement-specific attributes:
* MeasurementDate (measurement has been just repeated)
* EmitterPosition (headphones have been repositioned)
* SourceManufacturer (headphones changed)
* SourceModel (headphones changed)
* SourceURI (headphones changed)

Tracking: 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.
* MG: In principle, I agree. Simple labels have been proposed due to the challenging issue, i.e. tracking headphones position. But of course, the quantitative data could be stored in EmitterPosition.
* MG: The latter comment seems to be misleading after reading the one related to Tracking headphones position. Could you clarify your opinion on that?
* PM: Please define Tracking.
* 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?

==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
***PM: Agreed.

* 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]
*** PM: Agreed on your agreement :-).

MG: Let's consider the case of QU_KEMAR_anechoic_SennheiserHD25_0.5m.mat HRTFs from TU-Berlin; SourcePosition can be also seen as virtual position, e.g. previously measured without headphones at 0.5 m away from the listener, i.e. SourcePosition = [0 0 0.5]. Following the latter observation plus ListenerPosition=SourcePosition=[0 0 0] (always in the current convention), it's hard to describe EmitterPosition related to SourcePosition. I propose to anchor both Receiver- and Emitter- Position to ListenerPosition and use SourcePosition for the description of fictive sound sources.

Summarizing my observation:
* ListenerPosition = [0 0 0];
* SourcePosition = [0 0 0]; (no dimensions) / SourcePosition = [x y z]; (virtual sources)
* ReceiverPosition = [0 -0.09 0; 0 0.09 0];
* EmitterPosition = [0 -0.09 0; 0 0.09 0];

What do you think about it?

PM: I don't understand the statement "SourcePosition can be also seen as virtual position, e.g. previously measured without headphones at 0.5 m away from the listener". When measured without headphones, then we measure HRTFs, not HpIRs, right? So, at the moment, I agree with Fabian and vote for providing the actual positions of the headphones and the listener. But maybe I just did not understand the concept of "virtual position" - try to explain, please. In the meantime, I go for the actual positions...

MG2: What I would like to define with ''virtual position'' is the follow scenario: one can employ HRTFs as stimuli, e.g. the QU_KEMAR_anechoic_SennheiserHD25_0.5m.mat. I usually perform the convolution between HpIR and HRIR, separately, but my main concern regards the loss of generality of SingleHeadphoneIR convention.
Another issue that is currently coming into my mind, just to be clarified: what happens if the actual SourcePosition is coming from a loudspeaker and the listener is wearing headphones? We should consider a specific setup for a SimpleFreeFieldHRIR, shouldn’t we?

PM2: An HRTF measurement with wearing headphones is similar to an HRTF measurement with wearing a hut :-). Thus, these data will have the same format as those from an usual HRTF measurement and I suggest to use ''SimpleFreeFieldHRIR'' to store them. Also, ListenerDescription should contain something like "Listener was sitting in the center of the loudspeaker arc, was wearing the headphones XXXX and a sombrero.". Agreed?

== Headphone related attributes ==

The naming of the headphone related attributes needs to be clarified.

In general, all attributes considering the headphones have the prefix Source. The attributes on which we agreed so far are:
* SourceManufacturer: manufacturer name, optional.
* SourceModel: model name from manufacturers, optional.

The attributes proposed and currently being under discussion so far are (t.b.d.: to be defined):
* FormFactor: Circumaural, Supra-aural, Earphones, etc. ''(MG: see my comment at the end of this list)''.
** FBrinkmann: What do you mean by this?
** PM: I think that this is redundant information as already given by the SourceModel. What do you think?

* EarcupDesign: Closed, Open, etc. ''(MG: see my comment at the end of this list)''.
* Technology: Transducer technology, e.g. Dynamic ''(MG: see my comment at the end of this list)''
** FBrinkmann: What do you mean by this?
* Sensitivity: t.b.d
** 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
** PM: Please define Sensitivity.
** PM2: I see that in our AES proceedings, the sensitivity was defined as "electroacoustic transducer sensitivity (transfer factor) in mV/Pa". Can you tell me, if this is a value which is supposed to be measured or is this just the value from the specs given by the manufacturer?

MG: New attributes (w.r.t version 0.1) want to facilitate the relationship between product design attributes and acoustic responses of headphones. I feel that headphone characteristics (e.g. form factor, ear-cup design, etc.) have to be considered like the anthropometry for HRIRs. We should follow some standards in order to define these labels. Have you any strong feelings on this issue?

PM: If you think that you need those attributes: OK, no problem. Please define them, particularly paying attention to avoid redundancy (information provided already by the SourceModel).

MG2: All these attributes are somehow redundant once SourceModel is considered with an available product sheet. But anyway, we have to answer to the following question: why might it be important to perform a meta-analysis on model characteristics?

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.

* the stimulus type (e.g. sine sweep): t.b.d
** 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.

* qualitative data about microphone/receiver position, e.g. blocked ear canal, open ear canal, at the eardrum
** MG2: Optional (when tracking data are not available).
** Because such an information is not clearly defined yet, in SimpleFreeFieldHRIR, we use the attribute Comments for storing that information. I suggest to use that information for the headphones as well.

----

The attributes which as the result of our discussion, won't be considered are so far:
* FrequencyResponse: declared (from the manufacturer) frequency range, e.g. 12-20000 Hz
** FBrinkmann: IMHO not needed
** MG: I agree that this is not mandatory nor useful.
** PM: Agreed, attribute won't be considered.

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.
** MG: I proposed GLOBAL_HeadphonesXXX in order to characterize this convention. Now, I realize that GLOBAL_SourceXXX should be the most adequate for headphones. SOFA API already has the field GLOBAL:SOFAConventions, thus users are able to know that a “.sofa” file belongs to a HeadphoneIR convention and to automatically distinguish between typologies of Source and characteristic attributes.
** PM: Agreed. We will use SourceXXX as much as possible.

Talk:SimpleHeadphoneIR

2014-06-23T13:07:36Z

Fbrinkmann: