Mar 05, 2010

The calibrated microphones that I sell each come with a CD that includes the
frequency response files for each individual microphone. The file format
is a space-delimited text file with a frequency [Hz] , level [dB], and
phase [degrees] triplet on each line as
follows:

(Slight digression about microphone phase: I add a value of
“0” for phase for compatibility with the file format, but I don’t
actually measure microphone phase - in fact there’s really not a good way to
measure absolute microphone phase, but that’s another blog entry.)

This text-based file format is understood by most any PC &
Mac-based acoustic measurement package that I’ve come across
(SMAART being
the notable exception). But customers do tend to come across one
compatibility problem: I chose to use the Frequency Response Data (.FRD)
extension because it is a
documented
format. The problem is that
although many software packages can handle the file format itself, they
don’t like the “.FRD” extension - instead many of those programs use a
variety of extensions such as “.txt”, “.mic”, “.cal” and others. The
problem can be resolved by changing the “.FRD” extension to something
that the program recognizes and usually everything will be fine, but this
has been confusing for people. Despite the inclusion of a “Read Me” file
on the discs that include this explanation, I spend a lot of time taking
phone calls and responding to emails to help customers with this
problem.

I really don’t want to go down the road of including files with every
possible extension under the sun as that’s sure to be more troublesome
then it’s worth. Given that most acoustic software packages can handle the
basic format, I think it would really be better for the industry as a
whole if we
would just settle on a common format for calibration data.

To that end, I’ve reached out to the authors of serveral popular
packages to see if we can agree on a common file extensions for
calibration data. As of now,
REW,
Speaker Workshop, and
SoundEasy currently
support “.FRD”. The authors of True RTA
and
ARTA inform me that
their next versions will include support for the “.FRD” extension. I have
unfortunately not heard back from the authors of
FuzzMeasure,
WinMLS or
Aurora. But I am hopeful we
can move foward on standardizing on a file extension for calibration data.
It’s a small thing, but it’s the type of thing that has tripped people up
and we need to get on the same page.

Update, Mar 29, 2010:

I heard back from Chris Liscio of
SuperMegaUltraGroovy - he
informed me that FuzzMeasure does have support for the ".FRD" extension,
but it has a bug where it won't recognize it if the extension is in upper
case. I've changed my workflow to produce files with lower-case extensions
and hopefully this will improve compatibility.