The .frd format isn't really complete for speaker modeling (I'm the guy who got .frd and .zma established ages ago, btw). I tried to get an enhanced .frd format going, to also include information of the effective delay related to the phase response, relative to the plane of the mounting plane of each driver. And to also include sensitivity dB offset information (relative to 1m away and driven with 2.83V, for the measured value at 1kHz). Those haven't caught one so far, I'm hoping to get some changes to omnimic software and hardware to include those and maybe other measuring systems and simulation software would also use them? Another easy enhancement would be the measurement angle (relative to on-axis being 0 degrees), which can be easy done in the file naming of the frd file. Parts Express and Dayton Audio have been using these in their published data for drivers but so far even xsim doesn't really use it all. Maybe someday.
At least .zma is about as complete as it would ever need to be (unless someone wanted to do it also at different test levels, but that would be kind of perverting the meaning of "small signal data)
At least .zma is about as complete as it would ever need to be (unless someone wanted to do it also at different test levels, but that would be kind of perverting the meaning of "small signal data)
That is all really good data. I work in open source software and communities. This type of proposal usually takes place in RFC, posted in a prominent public forum where interested parties can comment. Has anything like this taken place? Are there common places where manufacturers and software writers can co-own an idea like this? This is one of the types of processes I am anticipating right now in some of my work.
The frd files work well enough for some of the prototyping I am working on. I can at least start prototyping proof of concept material. But at some point, better methods for transferring meaningful data has to emerge if there is any interest in propogating methods and sharing work.
The frd files work well enough for some of the prototyping I am working on. I can at least start prototyping proof of concept material. But at some point, better methods for transferring meaningful data has to emerge if there is any interest in propogating methods and sharing work.
Is there any "standard" for frd/zma?
I have seen many different characters for comments and even "," as decimal separator.
Not a formal standard (I did write up some rules some time ago, not sure where that doc is at the moment).
Calling it a "standard" is a bit over-the-top, though, FRD and ZMA are pretty much what would be obvious for text-based arrays. Just frequency, mag (dB or Z), and angle (degrees, optional), one set one each line, ended with CRLF. Frequencies must be in ascending order with no repeated values. Any line that starts with a non-numeric character is ignored. Scientific notation is allowed and should be read correctly. Some programs accept the engineering units (like "k" for thousands), but some don't so probably not a good idea.
A good tool reads comma, space or tab as value separators, such as between frequency and magnitude. Decimal separators SHOULD be ".". A comma is dangerous though since in some countries comma is used as decimal separator. But comma is allowed as a value separator because some early spreadsheets and sim programs could only export text values as "comma separated values --".csv" files.
Sorry for not going through the proper committees on these, They were decided after about 20 seconds thought when I needed a simple way to transfer and export data some 26 years ago on the IMP system (when it was still just one box in my basement!).
Calling it a "standard" is a bit over-the-top, though, FRD and ZMA are pretty much what would be obvious for text-based arrays. Just frequency, mag (dB or Z), and angle (degrees, optional), one set one each line, ended with CRLF. Frequencies must be in ascending order with no repeated values. Any line that starts with a non-numeric character is ignored. Scientific notation is allowed and should be read correctly. Some programs accept the engineering units (like "k" for thousands), but some don't so probably not a good idea.
A good tool reads comma, space or tab as value separators, such as between frequency and magnitude. Decimal separators SHOULD be ".". A comma is dangerous though since in some countries comma is used as decimal separator. But comma is allowed as a value separator because some early spreadsheets and sim programs could only export text values as "comma separated values --".csv" files.
Sorry for not going through the proper committees on these, They were decided after about 20 seconds thought when I needed a simple way to transfer and export data some 26 years ago on the IMP system (when it was still just one box in my basement!).
Hi Bill
There was a bit of discussion in the DIY Klippel scanner thread about this.
It's not completely easy if you don't have circular symmetry, say for a complete speaker rather than just a driver.
Then you need both Theta and Phi values, and with reasonable resolution that leads to hundreds of files for each measurement.
That is doable but seems pointlessly clumsy to me, I'd rather have the values in the file.
Pretty easy to add the data into the file itself, and more consistent, not some data in the file and other data embedded in the file name.
As the creator of FRD this seems an ideal opportunity to ask you - what do you think?
Best wishes
David
VituixCAD tries to be quite flexible. Test material for txt/frd/zma files, column separator space or tab (mixed), data rows in red:
Code:
* Comment line or header (REW)
# Comment line (HOLM Impulse default)
" Comment line (XSim default)
Smoothed Frequency Response (Arta)
Resolution = 1/6 octave (Arta)
Numpoints = 720 (Arta)
SamplingRate = 48000 Hz (Arta)
Frequency(Hz) Magnitude(dB) (Arta)
Freq [Hz] dBSPL Phase [Deg] (CLIO)
Freq Mag Phase (justMLS)
Freq dB Phase (LspLAB)
f[Hz] Uncompensated level [dB} Uncompensated phase [dB} (Edge)
CurveFormat = 5; (Klippel)
TDelayRemovedTRF = -0.0548333333333333; (Klippel)
SourceDesc = 'H(f) + Minimal phase'; (Klippel)
%[Hz] [V/A] [deg] (Klippel)
Curve = [ (Klippel)
FFT AudioTools v10.12.5 iOS10pro battery 46 % 11.03.18, 19:14 Umik - 1 Gain: 18dB L Mic 2
[COLOR="Red"]5 80 90
20.0 70.0 -90.0
30,0 80,0 90,0[/COLOR]
spaces in the beginning and end:
[COLOR="red"] 40.0 70.0 -90.0
50,0 80,0 90,0 [/COLOR]
scientific notation:
[COLOR="red"]1E3 7E1 -9E1
+2.0E3 8.0E1 9.0E1
.3E4 7,0E1 -9,0E1
4.0e003 8e001 9.0e001
5.0E+03 7E+01 -9.0E+01 [/COLOR]
klippel curve ends with ];
[COLOR="red"]40000.0 80.0 90.0];[/COLOR]
overall dB 109,9 dB
decay Mittelwert
averaging 1 / 6 Oktave
source Umik - 1 Gain: 18dB L Mic 2
latitude 48,199
longitude 11,374
saved 11.03.18, 19:14
peak 13404.0HzThis is readable without errors (rev 2.0.5.1). No warning if Phase column is missing in .mic and .cal files. Other file types produce warning but files are read with Phase=0.
In addition, LMS exports need special file extension (.lms) or some AI due to mixture of commas and periods:
Code:
* LMS(TM)
* (C)opyright 1993-2000 by LinearX Systems Inc
* Info1=
* DataPoints= 539
* DataUnits= Hz dBSPL Deg
10.000, 52.9746, 177.9131
10.145, 53.2070, 176.7848
10.293, 53.4246, 175.6674
...- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.