New Audiolense releases

Thank you, great report. I’ll look onto this at first convenience.
 
Today I started using version 0.7. First I aligned the microphone as best as possible. I measure with a Motu UltraLite mk5, so no hassle with 2 devices.

The first measurement of my active 3-way speakers was disappointing. The first screenshot shows that the right tweeter and midrange have no delay compared to each other. The left channel shows the delay as I am used to. To check, I also measured with version 6.29. That looks good.

I repeated the measurements a few times and reinstalled 7.0. No change. If I delete the al.ini file, it does show a delay in the right channel in the first measurement, but not as precise as with the 6.29 version. The following measurements then show 0 delay again.

I don't know if this is a bug, or just ignorance on my part. Hopefully someone knows a solution.
 

Attachments

  • 2025-06-04.png
    2025-06-04.png
    47.6 KB · Views: 90
  • Schermopname (4).png
    Schermopname (4).png
    40.7 KB · Views: 89
Yes, that doesn’t look right. Could be only the numbers, though. How do the pulses look? Do they have the anticipated delay?
 
Hi Bernt,

Hopefully what I did is correct. First I filtered the measurement with the 7.0 version and then I zoomed in on the tweeter and midrange impulses on the filtered measurement. The result is visible on the enclosed screenshot. I hope this is useful to you.

Cornelis
 

Attachments

  • pulses.png
    pulses.png
    428.9 KB · Views: 77
In addition:

If I compare the measurement between version 6.29 and 7.0, the difference between right tweeter and midrange is at 7.0 (31ms) and 6.29 (127ms)
 
I think you should proceed with these measurements. I believe they are good. The first negative peak is interpreted as the peak of the midranges here, that's why the mids are interpreted to arrive earlier than the tweeters.

For a TTD correction the peak finding has no consequence unless you edit the timing manually. For a frequency correction there's a risk that the mids are interpreted as having negative polarity here. However, things may change after the crossover has been applied.

Anyway I recommend that you disable the automatic polarity correction from the measurement menu. When you have done that, you should enter the measurement module and change one of the delay values. This will make the "reset delay" button visible. So press that button, resave the measurement and send it to the main form.

I do not understand the milliseconds you mention in your most recent post. Your screen shots shows 0.08 ms delay for the 7.0 measurement...
 
Hi Bernt,

You were absolutely right. With the automatic polarity check disabled, the measurements for both 6.29 and 7.0 were identical. The tweeters are now set to a delay of 0 and the midwoofers to 0.05. Yesterday's measurements looked quite messy. I live next to a busy road and the attic where I measure is far from quiet. At night it is a lot better.

Once again, many thanks for your explanation.

Cornelis
 
[20 june 2025] (beta)

Audiolense 7.1 (64 bit)
Audiolense 7.1 (32 bit)

  • Speeded up additional processes with parallel processing.
  • Fixed a bug where low pass was omitted on subwoofers if they were not also used to bass offloading.
Known issues: There are errors in the progress reporting. Sometimes, on broken measurements, the measurement quality report is not displayed. But you can still examine the actual measurement.
 
[22 jun 2025]

Audiolense convolver 1.10.exe



  • Fixed a few minor gui display issues.
  • Implemented the improved resampler that has been in use in Audiolense for a while
  • Implemented support for the revised AL correction format, needed to supppport very high channel count.
  • This version is back-compatible with older corrections.
And I’ve changed the required file extension on the license file back to: *.license.
 
[27 june 2025]

Audiolense 7.2 (64 bit)
Audiolense 7.2 (32 bit)

  • Brought back the measurement quality report on unsuccesful measurements
  • Eliminated a minor bug in the measurement that could lead to unhandled exception.
  • Fixed improper initialisation related to the speaker connection check.
  • Ignored the first recorded buffer in the measurement because it’s a dummyu.
Known issues: There are still errors in the progress reporting.
 
[22 aug 2025]



Audiolense 7.3 (64 bit)
Audiolense 7.3 (32 bit)

  • Multi seat correction had not been properly prepared for multithreading, which has now been fixed.
  • All tests look good, and the subject code has been investigated and modified to be thread safe. Nevertheless, for now, it is recommended to examine the simulated results and look for anomalies.
 
[22 aug 2025]



Audiolense 7.3 (64 bit)
Audiolense 7.3 (32 bit)

  • Multi seat correction had not been properly prepared for multithreading, which has now been fixed.
  • All tests look good, and the subject code has been investigated and modified to be thread safe. Nevertheless, for now, it is recommended to examine the simulated results and look for anomalies.
The download is triggering a false positive in Microsoft Defender for virus Win32/Wacapew.C!ml
Thinks it's making changes to settings without permission being granted
 
The download is triggering a false positive in Microsoft Defender for virus Win32/Wacapew.C!ml
Thinks it's making changes to settings without permission being granted
No, it's just because Windows Defender does a lot of its actions on name recognition. If something has been falsely flagged as potentially dangerous, it seems to be flagged more or less for every new release. And unfortunately, afaik, there's no way for me to pre-empt this flag unless I get a security certificate (which I intend to do eventually, but not right now). There has been a number of warnings and blocks throughout the years, but there has never been any virus involved.
 
No, it's just because Windows Defender does a lot of its actions on name recognition. If something has been falsely flagged as potentially dangerous, it seems to be flagged more or less for every new release. And unfortunately, afaik, there's no way for me to pre-empt this flag unless I get a security certificate (which I intend to do eventually, but not right now). There has been a number of warnings and blocks throughout the years, but there has never been any virus involved.
I realize it's a false positive, and I suppose most who download AL know there is not really an issue, but this time Defender is sandboxing the "virus" so you have to tell defender to make an exception (instead of simply telling the browser to "keep anyway").
 
I just noticed that in release 6.24 there was this note:

A small rounding error on the peak finder was discovered, the fix may lead to improved alignments in some setups.

Does it refer to the changes made in 6.22?
 
In 6.24 the peak finder has new usage, related to resampling of filters. And it didn't work as intended with that usage. So I took a closer look at everything. And found a small rounding error. Mostly a minor technical improvement and far more important for the revised resampling than the original correction.
 
Back
Top