I have been working with my EARS rig for a while now, and have figured out some of the quirks and oddities it presents.
The compensation files you are presented seem to be an average of several results. The problem with this when using EARS vs an open-air mic is that the measurements will vary wildly from headphone to headphone, or when measuring a speaker in a room, from angle to angle. The interactions with the silicone ears changes things a lot.
I tested this by measuring a speaker on-axis without the ear on, and then again after putting the ear over the mic. What surpeised me is that the Q of the resonant peak is super narrow, but the calibration file corrects it with a very very wide dip by comparison. The result is that you get two deep valleys on either side of a narrow spike in the final graph.
The reason this is happening is that the exact frequency of this spike will move up and down depending on the headphone and placement, and so you can't pin down or predict where it will appear.
If there was a way to use the EQ window's predicted graph code in the main window, you could use this either instead of or in addition to an actual calibration file. You would do the measurement and move the narrow Q band up to where that peak appears for that measurement, and you'd get a more accurate compensation instead of a very generalized one that tries to push the entire problematic range down.
The compensation files you are presented seem to be an average of several results. The problem with this when using EARS vs an open-air mic is that the measurements will vary wildly from headphone to headphone, or when measuring a speaker in a room, from angle to angle. The interactions with the silicone ears changes things a lot.
I tested this by measuring a speaker on-axis without the ear on, and then again after putting the ear over the mic. What surpeised me is that the Q of the resonant peak is super narrow, but the calibration file corrects it with a very very wide dip by comparison. The result is that you get two deep valleys on either side of a narrow spike in the final graph.
The reason this is happening is that the exact frequency of this spike will move up and down depending on the headphone and placement, and so you can't pin down or predict where it will appear.
If there was a way to use the EQ window's predicted graph code in the main window, you could use this either instead of or in addition to an actual calibration file. You would do the measurement and move the narrow Q band up to where that peak appears for that measurement, and you'd get a more accurate compensation instead of a very generalized one that tries to push the entire problematic range down.
