Blog logo, you're not missing much
AudioAcoustics

Serving the Acoustics Community Since 1994

Cross-Spectrum Labs offers Sound & Vibration Consulting Services

March
Sun Mon Tue Wed Thu Fri Sat
  5
     









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:

5 -14.04 0
6.3 -9.90 0
8 -6.933 0
10 -4.732 0
12.5 -3.16 0
16 -2.06 0
[...]

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


permanent link