kyle_neuron
Active Member
- Joined
- Jun 18, 2021
- Messages
- 149
- Likes
- 256
That would be interesting. I don’t think there’s likely to be a significant benefit to exporting the data using a more dense angular resolution than every ten degrees on the main horizontal and vertical axes to generate your Spinorama plots. It’s only in relation to the process of calculating the balloon from the data stored within the GLL.It doesn't cost much to generate all angles. I will check if the generated data is different aka freq response at 10 deg with precision set to 2.5, 5 or 10.
In many cases, the speaker was likely measured using 5-degree reduction as this is commonly considered to be ‘good enough’ for the majority of more simple two-way or three-way point source style boxes.
However, for the purposes of scripting an automation which applies to all speakers with zero or minimal user-input before each each run, it’s best to go as high as possible. My laptop uses a four-year old ultraportable class CPU and still manages to breeze through a balloon calculation in around 30 seconds using the 2.5-degree resolution setting in GLL Viewer.
That’s no problem, so long as GLL Viewer is taking the phase into account when extrapolating the response to an arbitrary distance in space, which it does.Note that the spinorama has not been designed for this kind of speakers. It doesn't even take phase into consideration only frequency data.
The choice & verification of suitable angular and frequency resolution data is a problem for the person capturing the data used to create the GLL balloon file is complex in the first place.
If we can trust that has been done properly, then there’s no issue to use only the magnitude response for generating a Spinorama plot.
It absolutely is, and this is crucial when considering a major benefit of the GLL data type in comparison to AFMG’s older (and more readable) SPK format.I didn't know this two and will read them. But it is clear that phase is important when combining sources since that would be the case for 2 functions of complex numbers.
A GLL can contain high-resolution complex data for each individual radiating source within a given loudspeaker "box" or "cluster" and then combine them with arbitrary filtering to produce a response at any position in 3D space for any combination of those sources.
Tools like VituixCAD now offer this on the primary two axes for free, but this complex multi-source modelling method was seriously impressive stuff 15 years ago!
I think the M-Noise/AES2022 testing process documentation might include some data on the correlation between THD and the stop condition thresholds for coherence & magnitude deviation, but it's not explicitly logged as part of those tests or the MIV one due to the use of steady-state noise stimuli, sadly.Agreed. Estimated max SPL is important for venues but for this forum, I am not sure that's super relevant. People always want bigger and louder but they are more
in the 120 dB SPL max why PA speakers are more 130+. If I can generate a max SPL curve for a given % of distorsion that would be nice.
I looked through the metadata file but hadn't swapped to the develop channel at that time, as I wasn't aware the live publicly-accessible site was pulling data from there instead of the default master channel of the repository.the metadata file have the information.
It would still be nice to show the provenance on the website page if possible. I think quite a few folk may find the spin plots via Google searching, as I did, and not know where the information came from.
Thanks for the detailed answer. I wish there was a published API to the GLL file format.
You & me both, and I presume many others. AFMG probably wouldn't sell so many €4000 licenses for EASE software if their file format and tools worked with open-source acoustic modelling tools such as i-Simpa, though
Many manufacturers also provide their data as CLF files, which is a more open standard. AFMG SpeakerLab will export CLF data at the same time as generating the GLL. It looks like the Klippel NFS generates CLF, too. There are also lots of speakers with CLF data for download right on the CLF Grouo website, as well as the individual manufacturer’s own websites.
The format has lower angular & frequency resolution than GLL files can handle, and third-octave smoothed magnitude probably isn't sufficient to assess anything more than general trends in a Spinorama:
That said, CLFv2 is seen as 'good enough' for ODEON room acoustics modelling software, which is used for concert halls, stadia and the like.CLF v1 supports two data resolutions. A CLF Type 1 file contains Octave/10 degree data, a CLF Type 2 file contains Third Octave/5 degree data. Two resolutions are used to support legacy data that is only available in the lower resolution format. Authors are encouraged to publish data in the 'as measured' format so that end users know what they are using.
CLF2 v2 supports optional phase, filters and multipart files (for modeling multi-way loudspeakers and improved array modeling)
You need to contact the CLF Group to obtain permission to use the compiled binary files in your own software, but that might be worth doing if it can expand your database while avoiding more GUI-scraping http://clfgroup.org/
There's also the Spatially Oriented Format for Acoustics aka SOFA standard. That is actually open-source, and the conventions can accurately describe sources & receivers with lots of detail. It's seen widespread industry adoption for storing and distributing things like binaural HRTF data, but the loudspeaker directivity convention hasn't seen the same level of uptake despite appearing to be comprehensive:
FreeFieldDirectivityTF - Sofaconventions
www.sofaconventions.org
Which is a shame, because it doesn't seem like it would be too difficult to generate a SOFA FFD-TF file if a manufacturer or testing lab still has the original measurement IRs & associated metadata. There's even a nice little balloon data viewer application available on their wiki, and the data can be easily pulled out of the SOFA database for use in other stuff.
It might be a useful method to store your own data sets in a common format, though. Fewer folders full of ASCII data to sync with GitHub.
Last edited: