#141 Equalizer APO parses 123.456 Hz as 100,000.00 Hz

[Etienne Dechamps]

When confronted with the following configuration file:

Filter: ON PK Fc 1234.56 Hz Gain 1 dB Q 1
Filter: ON PK Fc 123.456 Hz Gain 1 dB Q 1
Filter: ON PK Fc 12.3456 Hz Gain 1 dB Q 1

Equalizer APO 1.2.1 correctly parses 1234.56 Hz and 12.3456 Hz, but 123.456 Hz is surprisingly parsed as 100 kHz. See attached file.

[Peter Verbeek]

Does Equalizer APO correctly process the peak filter on 123.456?

Equalizer APO is (initially) built for importing filters from Room EQ Wizard. But this app has a flaw. It exports with the local formatting signs for decimals and thousands. For example in my case (Dutch) it exports 999,999.999 as 999.999,999. That's fine but it leaves Equalizer APO guessing (and Peace for that matter) on what kind of system (language-wise) the export is done. So 123.456 is processed as being an export on a system where the decimal sign is a comma and the thousand sign is a point. It's a best guess but in this case wrong. But fortunately using decimals for frequencies isn't that useful. So I think rounding the frequencies could do the trick.

[Etienne Dechamps]

Well that's unfortunate.

For context: I ran into this problem as I was writing a small script to convert Multi-Sub Optimizer "filter reports" to Equalizer APO configuration. It looks like I can work around the problem by always adding a bunch of zeroes at the end, e.g. 123.456000 Hz parses fine.

[Peter Verbeek]

I have similar issues when importing a filter file of REW into Peace. Not only the frequency could present a problem but also the gain. So be sure that the gain is also in the right format. Perhaps rounding everything to an integer value? Although adding zeros might be fine but I'm not sure. I haven't looked into the programming code of Equalizer APO. I'm not an expert on the code.

Just curious what you're doing. What's your small script all about?

[Etienne Dechamps]

I have similar issues when importing a filter file of REW into Peace.

I'll talk to John (the REW author). Maybe he can fix the REW export to always use an unambiguous representation. This would be progress.

I haven't looked into the programming code of Equalizer APO. I'm not an expert on the code.

I took a look. The relevant code is in BiQuadFilterFactory.

First it matches on the following regex: \\s+Fc\\s*([-+0-9.eE\u00A0]+)\\s*H\\s*z (ECMAScript regex with C++ escapes)

Then it calls getFreq() and this is where things get interesting. Apparently, if the number is more than 5 characters, and the fourth-to-last character is ., then it multiplies the number by 1000. The string 123.456 matches these criteria, so Equalizer APO ends up parsing that number as 123456 (which I presume is then truncated to 100000 down the line) instead of 123.456. 12.3456 and 1234.56 are fine because . is in a different position.

It would be nice if this behavior could be improved - it's very brittle and can result in subtle corruption of filter configuration since this peculiar behavior will only trigger on some subset of numbers. It's a very good way to give users nasty surprises, especially for those people such as myself who are generating Equalizer APO configs from a source that is not REW (or even just writing config files without the GUI).

Not only the frequency could present a problem but also the gain. So be sure that the gain is also in the right format.

It doesn't look like that logic is applied to gain values though. Gain values appear to be parsed in a straightforward manner, according to the code.

Just curious what you're doing. What's your small script all about?

I'm experimenting with Multi Sub Optimizer and Equalizer APO. MSO can be used to generate banks of Parameteric EQ filters and those are quite tedious and error-prone to copy by hand into Equalizer APO. I'm writing a small shell script that takes one of the MSO plain text export formats and turns it into an Equalizer APO filter config to expedite the process.

[Etienne Dechamps]

I just talked to John (REW author) and he had this to say:

The filter export text format uses dot as decimal delimiter and no digit grouping. That change was made in December 2016.

Peter: you said "in my case (Dutch) it exports 999,999.999 as 999.999,999". Can you still reproduce this behavior with the latest REW beta version?

If it's really been fixed on the REW export side since 2016, then maybe Equalizer APO could be updated to remove the brittle, surprising parsing edge cases.

[Peter Verbeek]

Looking at my code for the import feature of the Peace equalizer (Are you familiar with it?) I already seem to take this issue into account. Depending on lower or higher than REW version 5.17 I act accordingly. Anyway, the latest 5.19 version does give the (proper) decimal point output. As I'm able to check this, Equalizer APO could also (if anyone would care to change the code). In other words, I agree with your statement. Btw. thanks for the detailed explanation of the code.

Gain values appear to be parsed in a straightforward manner, according to the code.
I was under the impression this wasn't the case when I was creating the Peace import feature back in 2016. But I could be mistaken.

Though I'm not quite understanding the goal about having multiple subwoofers, I do understand there can be issues related to lower frequencies like seat position. But I'm a noob on this subject. Anyway, creating a script for exporting to Equalizer APO is very logical thing to do. It's what Peace does (realtime): Creating (filter) commands so Equalizer APO is doing the audio processing.