Loudspeaker Design Calculations Toolkit

Technical Note #1: File Formats

Overview
Most loudspeaker measurement and design programs have options to “export to text file” and “import
from text file” which are intended to allow moving data between different programs. However, there is
no standard, universally accepted format for the contents of these files. This is a problem.
LDCT may not be able to load some of these files. This document describes the underlying issues, how
LDCT deals with them, and what you can do if you have problems. The final topic, “LDCT Specifics,”
discusses saving files from LDCT and how the program may help you resolve issues when
exporting/importing files between other programs.

An Unofficial Standard
The FRD Consortium (FRDC) documented a standard format1 for exchanging frequency response data
files (“FRD files”) between programs. Generally, the requirements are2:
• Data is stored in plain text files.
• Comment lines start with an asterisk (“*”) as the first character of the line.
• All comment lines must come before frequency data lines.
• Frequency data is specified with one line per frequency value.
• The frequency value of each line must be greater than the preceding frequency value.
• Each line of frequency data will contain three numeric values:
• The first value specifies frequency in Hertz.
• The second value specifies the magnitude, e.g., SPL or impedance.
• The third value specifies the phase, typically in degrees.
• The values are separated with one or more spaces or tabs.
That's pretty much it. Here is a partial example from the FRDC document:
* Seas T25-001.frd
* Freq(Hz) SPL(db) Phase(deg)
*
10 21.0963 158.4356
10.1517 21.0967 158.4363
10.3056 21.3305 158.7836

Well, that seems simple enough. Unfortunately, there are two kinds of issue: (1) The specification is
incomplete and (2) many programs do not strictly follow the specification. These are discussed below.

1 The site was orphaned at one point and I am uncertain whether it has a permanent home. You can try this Google search
to try to find the document.
2 I am somewhat loosely describing the standard here.

Copyright © 2014 Robert Dunn. All rights reserved.

LDCT Developer Documentation v0.9.17 Page 2 of 5

Incomplete Specification
The specification is incomplete in at least two ways:
• Text file formats differ between OS platforms.
• Number formats differ between locales.
These are described below.

Cross-Platform Text Format Issues

The concept of a “text file” is vague. Sure, it seems obvious; a text file is a sequence of lines, right?
Well, different operating systems define “a line” differently.
• On Microsoft platforms, each line of a plain text file is terminated with a carriage return and
linefeed code pair.
• Unix/Linux platforms use only a linefeed code to terminate a line.
So you cannot just copy a text file from one platform to the other and expect things to work properly.
Some programs may handle this OK but others may not.
Since most audio development tools run on only one platform, users are unlikely to encounter this
problem. But LDCT is quite deliberately cross-platform so this could be an issue.

Locale Dependent Number Formats

Different parts of the world use different number formats. All of the following are one thousand plus
two hundred plus thirty-four plus one-half:
• 1,234.5
• 1.234,5
• 1 234,5 (space between the 1 and 2)
The first is the format used in the US. The second and third are common in Europe.
The grouping separator (between 1 and 2) is not included in any FRD files that I have seen. However,
the specification does not explicitly prohibit it. And, while the FRDC example uses the US convention,
it does not explicitly require it. I have seen FRD files that use the European decimal symbol
convention.
Further, the above number could also be expressed as3:
• +1.2345E+3
• +1,2345E+3
So how can LDCT reliably parse and load the numeric data? Well, LDCT uses pattern matching to try
to infer the correct format. However, this somewhat compromises the “reliable” part as we will see
below.

3 An example of a program that use this scientific notation in exported FRD files appears later in this document.

Copyright © 2014 Robert Dunn. All rights reserved.

LDCT Developer Documentation v0.9.17 Page 3 of 5

Non-Compliant Programs
Many programs do not strictly follow the FRDC specification4. There are two general kinds of issue:
• Comment lines not prefixed with an asterisk.
• Characters other than spaces or tabs between numeric values.
The challenges for LDCT are described below.

Non-Commented Text
Here is an example of the first few lines of a file exported from Audiomatica's Clio measurement
program:
Freq [Hz] Ohm Phase [Deg]
20.00 5.91 2.30
20.28 5.91 2.33

And here is part of a file exported from Dayton Audio's WT-3 program:
* This data was exported from the Dayton Audio WT3 Woofer Tester
*
* Manufacturer:
* Model:
D 0.0 [mm]
Re 0.00 [Ohms]
Fs 0.00 [Hz]
Zm 0.00 [Ohms]
BL 0.00 [N/A]
Qms 0.000
Qes 0.000
Qts 0.000
Vas 0.000 [liters]
L10k 0.00 [mH]
n0 0.00 [%]
dBSPL 0.00 [1W/1m]
Ms 0.00 [grams]
Cms 0.00 [mm/N]
*
*
Freq Impedance Phase
1.029 0.070 -3.768
1.059 0.070 -3.768
1.091 0.070 -3.768

While the Clio file example was not strictly correct, it was manageable. But the WT-3 file is a mess,
combining Thiele-Small parameters and impedance data in the same file. What should LDCT do with
such files?
Well, LDCT could require that the user use a text editor to split the data into two files. That would be
completely and absolutely reasonable – but not very user-friendly.

4 To be fair, program vendors don't generally claim to be “FRDC-compliant.”

Copyright © 2014 Robert Dunn. All rights reserved.

LDCT Developer Documentation v0.9.17 Page 4 of 5

So LDCT takes a different approach. It assumes that a line that contains exactly three validly
formatted numeric values and nothing else is valid data. If it finds anything other than that, the entire
line is ignored. Practical? Yes. Reasonable? Maybe. Perfect? No.

Invalid Delimiters
The final issue we will address is invalid delimiters. The specification requires spaces or tabs between
numeric values.
Here are the first few lines from a file exported from LinearX's LEAP:
* LEAP-CS(TM) 5.2.0.351 Jan/18/2008
* ©1993-2003 LinearX Systems Inc
* Sep 24, 2011 Sat 12:37 pm
* Design=C:\Temp\Testing Clio Imp Calc.lcd
* Curve=Import: U#1 SRef 0.36V 0.0g.txt
* Info1=C:\Speaker Design\SB Acoustics SB15NRXC30-8-UC\Clio Measurements\Unit #1\U#1 SRe
* Info2=File Created: Sep/06/2011 4:47 PM
* Info3=File Imported: Sep 21, 2011 Wed 9:33 am
* Info4=
* DataPoints= 537
* DataUnits= Hz V Deg
+1.000000E+001, +3.184198E-001, +2.686000E+001
+1.014000E+001, +3.191538E-001, +2.651000E+001
+1.029000E+001, +3.202580E-001, +2.619000E+001

In addition to using scientific notation, LEAP inserts commas between values. I mentioned in the
“Locale Dependent Number Formats“ section that LDCT accepts European-style number formatting.
What would happen if LEAP files used that format and, thus, we had commas as decimal separators
and as value delimiters?
Frankly, that could be a problem. And that segues nicely into the next topic.

Solving LDCT Problems

It should be clear from the above that loading FRD files exported from one program into any other
program may not work5. LDCT tries to anticipate all reasonable formats but does so at the risk of
failing to load some or all data.
So what should you do if LDCT cannot load a file? Or if it loads only part of a file?
First, you'll need to open the file in a text editor and look for formatting problems. You should aim to
modify the file to meet the FRDC specification.
If you don't see any problems, consider where the data came from. If it came from a different platform,
consider the “Cross-Platform Text Format Issues” discussed above. If the line terminators on your
platform do not match the source platform, simply re-saving the text file from the text editor on the
target system may correct the problem.

5 Worse, I suspect that the same program could not export a file in one format and import the same file in a locale that
used the other format.

Copyright © 2014 Robert Dunn. All rights reserved.

LDCT Developer Documentation v0.9.17 Page 5 of 5

If none of the above solve the issue, you can post a trouble ticket on the project site at SourceForge.
Please be sure attach a copy of the problem FRD file to the ticket.

LDCT Specifics
After all of the above whining about FRD files exported from other programs, you might rightly
wonder what conventions LDCT follows. Here is an example of a file saved from LDCT:
* File saved by LDCT on Tue Jul 08 15:12:01 CDT 2014
* Source curve name: Imp Woofer 100pts.txt
* [Hz] [Ohms] [Degrees]
20.0 15.89 44.22
21.42 18.38 42.29
22.94 21.63 37.81

By default, LDCT uses the system locale settings to determine which decimal separator character to
use. The above was created on a system configured for the US locale so the decimal separator was a
period.
If you want to use a format different from your system's locale settings, click the small button next to
the Save button on the Curves List tab page. You can choose to use:
• Local Settings (the decimal separator is defined by the system locale settings).
• US Style (the decimal separator is a period).
• European Style (the decimal separator is a comma).
Of course, any FRD file saved from LDCT should load into LDCT without problem regardless of the
choice of number formatting.
LDCT may solve issues when importing data into another program. If you cannot import an FRD file
into a program because the number formatting is incompatible with that program, you can use LDCT
to save a version with the compatible format.

Wrap Up
I hope that this lengthy and excruciatingly-detailed explanation of FRD file problems and LDCT
solutions was helpful. Thanks for your interest in LDCT.

Last Revised July 13, 2014

Copyright © 2014 Robert Dunn. All rights reserved.