DecayCore — Free FIR room correction with temporal decay control, automatic optimization and measurement workflow

[Kali-]

the phase alignment (sub_delay) is gone?

 

[VilhoValittu]

the time alignment (sub_delay) is gone?

No, it's crucial part of bass integration.

 

[Kali-]

i had it in older version (<=1.2.2) and with the same measurement is missing in >=1.2.7 (didn't tested middle version)

 

[VilhoValittu]

i had it in older version (<=1.2.2) and with the same measurement is missing in >=1.2.7 (didn't tested middle version)

Calculated delay is informed at Results page on Bass Integration sections and summary.txt file.

Or what do you mean excatly? I'm little confused.

 

[SoundsGood64]

From a REW measurement standpoint, how do we assess improvements in phase and group-delay, following implementation of DecayCore FIR?

Consider some examples in post 185 above of 3 dips on the SPL vs frequency plots of SL (surround left) and Center at:

SL 101hz
SL 200hz
C 181hz

To review the context, this is a 7.1 system, single sub, DecayCore generating independent linear-phase FIR filters per channel group (L-R, Center-Center, SL-SR, BL-BR, LFE-LFE) against a Harman 8dB target. Sub integration (crossover, sub gain/delay, LF time-alignment of Center/Surround/LFE into the sub bus) was done *before* generating DC filters. I later found DC's filters shift phase near each channel's own crossover by a non-trivial amount (not a software bug), which threw off the original sub-bus timing — and re-measuring/correcting that timing is what the earlier post was about. In this post, I want to consider what DecayCore might have done to result in improvements of the above 3 dips, with respect to phase and group-delay.

So here are some closer looks at SL and C plots of SPL, phase, and group delay (negative slope of phase), each as a function of frequency: 1) Green is after the first sub integration, the measurement done for input into DC (before DC), 2) Blue is after DC with the original (pre-DC) sub-bus delays, and 3) Red is after DC, with re-corrected sub-bus delays (second time alignment).

Surround Left (SL): SPL, phase, and group delay plots

Center SPL, phase, and group delay plots

First, the observation. For each of the 3 peaks: pre-DC (1, green) and post-DC-only (2, blue), there's a magnitude dip in SPL paired with a rapid group-delay swing at the same frequency. After the DC FIR and the corrected sub-bus delay (second alignment) are both applied, the SPL dip largely closes, the phase slope smooths out, and the GD trace flattens to a constant slope through that region (3, red). One aspect that I hinted on the post 185 above is that the disappearance of the SPL dip probably depends on BOTH the DC FIR and the second alignment of the sub-bus.

What are the underlying physics and/or engineering driving this observation? What was it that DecayCore did to help out with this, that wasn't enough by itself, but when combined with the second sub-bus alignment, resulted in removing these 3 huge dips? Again, if it was just the sub bus alignment, that should have been fixed before DC and we should never have seen these dips on the #1 green plots.

From the DC summaries (see post 183), TDC was applied to the 101hz SL peak, and the 181hz Center peak, but TDC was not applied to the 200hz SL peak. So I don't think it would be TDC because that explanation doesn't cover all 3 peaks. Or maybe it is TDC? Could a TDC-driven improvement at 101hz somehow also benefit 200hz, perhaps something to do with 1st and 2nd harmonics? I couldn't find anything else in the DC summaries that might explain what DC contributed here, but it certainly looks like it did from this analysis.

This is one example that I highlight toward the larger question, which is how do we assess DC or FIR-based improvements in phase and group delay using measurements?

 

[Kali-]

v1.2.2

=== DSP SETTINGS TO ENTER IN YOUR DSP ===
Main HPF: 61.4 Hz / 24 dB/oct
Sub LPF: 153.4 Hz / 24 dB/oct
Sub delay: 9.670 ms
Main delay L/R: L 0.000 ms, R 0.000 ms
Sub polarity: INVERTED
Sub gain trim: -2.803 dB
Bass allpass: OFF

v1.2.8

=== DSP SETTINGS TO ENTER IN YOUR DSP ===
Main HPF: 80.0 Hz / 24 dB/oct
Sub LPF: 80.0 Hz / 24 dB/oct
Sub delay: 0.000 ms
Main delay L/R: L 0.000 ms, R 0.000 ms
Sub polarity: NORMAL
Sub gain trim: 0.000 dB
Bass allpass: OFF

same measurement

 

[VilhoValittu]

v1.2.2


v1.2.8


same measurement

Can you share that measurement?
Have you tried clear DC's caches from About DecayCore section top of page?

 

[Kali-]

Can you share that measurement?
Have you tried clear DC's caches from About DecayCore section top of page?

Both cache and config
enabled Bass integration and selected L,R and Sub1

this is me, and also this issue is back

1.2.1 issues · Issue #3 · VilhoValittu/DecayCore

i just enabled bass integration v4, selected L, R and Sub Measurement but sub is missing in exported filter (i have attached one of the summary files), but after rerun without changing anything Dec...

github.com

i shared my measurement if you deleted i can reshare them
and if you prefer we can continue to github which i guess is the better place to discuss that

 

[VilhoValittu]

Both cache and config
enabled Bass integration and selected L,R and Sub1

this is me, and also this issue is back

1.2.1 issues · Issue #3 · VilhoValittu/DecayCore

i just enabled bass integration v4, selected L, R and Sub Measurement but sub is missing in exported filter (i have attached one of the summary files), but after rerun without changing anything Dec...

github.com

i shared my measurement if you deleted i can reshare them
and if you prefer we can continue to github which i guess is the better place to discuss that

Oh, sorry, it's you. I just re-opened issue but I cannot replicate that kind of behaviour.

 

[VilhoValittu]

From a REW measurement standpoint, how do we assess improvements in phase and group-delay, following implementation of DecayCore FIR?

Consider some examples in post 185 above of 3 dips on the SPL vs frequency plots of SL (surround left) and Center at:

SL 101hz
SL 200hz
C 181hz

To review the context, this is a 7.1 system, single sub, DecayCore generating independent linear-phase FIR filters per channel group (L-R, Center-Center, SL-SR, BL-BR, LFE-LFE) against a Harman 8dB target. Sub integration (crossover, sub gain/delay, LF time-alignment of Center/Surround/LFE into the sub bus) was done *before* generating DC filters. I later found DC's filters shift phase near each channel's own crossover by a non-trivial amount (not a software bug), which threw off the original sub-bus timing — and re-measuring/correcting that timing is what the earlier post was about. In this post, I want to consider what DecayCore might have done to result in improvements of the above 3 dips, with respect to phase and group-delay.

So here are some closer looks at SL and C plots of SPL, phase, and group delay (negative slope of phase), each as a function of frequency: 1) Green is after the first sub integration, the measurement done for input into DC (before DC), 2) Blue is after DC with the original (pre-DC) sub-bus delays, and 3) Red is after DC, with re-corrected sub-bus delays (second time alignment).

Surround Left (SL): SPL, phase, and group delay plots
View attachment 556468

View attachment 556467

View attachment 556466

Center SPL, phase, and group delay plots

View attachment 556471

View attachment 556470
View attachment 556469


First, the observation. For each of the 3 peaks: pre-DC (1, green) and post-DC-only (2, blue), there's a magnitude dip in SPL paired with a rapid group-delay swing at the same frequency. After the DC FIR and the corrected sub-bus delay (second alignment) are both applied, the SPL dip largely closes, the phase slope smooths out, and the GD trace flattens to a constant slope through that region (3, red). One aspect that I hinted on the post 185 above is that the disappearance of the SPL dip probably depends on BOTH the DC FIR and the second alignment of the sub-bus.

What are the underlying physics and/or engineering driving this observation? What was it that DecayCore did to help out with this, that wasn't enough by itself, but when combined with the second sub-bus alignment, resulted in removing these 3 huge dips? Again, if it was just the sub bus alignment, that should have been fixed before DC and we should never have seen these dips on the #1 green plots.

From the DC summaries (see post 183), TDC was applied to the 101hz SL peak, and the 181hz Center peak, but TDC was not applied to the 200hz SL peak. So I don't think it would be TDC because that explanation doesn't cover all 3 peaks. Or maybe it is TDC? Could a TDC-driven improvement at 101hz somehow also benefit 200hz, perhaps something to do with 1st and 2nd harmonics? I couldn't find anything else in the DC summaries that might explain what DC contributed here, but it certainly looks like it did from this analysis.

This is one example that I highlight toward the larger question, which is how do we assess DC or FIR-based improvements in phase and group delay using measurements?

Thanks for the detailed measurements. This is an interesting observation. I want to investigate it more closely rather than speculate, and I’ll return to this topic once I have some controlled test data.

 

[Kali-]

Oh, sorry, it's you. I just re-opened issue but I cannot replicate that kind of behaviour.

this is very odd...
Can be related to OS ? i'm running ubuntu 26.04

 

[VilhoValittu]

this is very odd...
Can be related to OS ? i'm running ubuntu 26.04

DC is currently developed with Ubuntu 26.04.

Do you have any legacy CamillaFIR config's at your system? Memory leak can be long..

Launch program with DECAYCORE_LOG_LEVEL=INFO DECAYCORE_AUTO_PROFILE=1 ./run.sh > bi_debug.txt 2>&1 and then go to http://127.0.0.1:8080/ and run Bass Integration run.
Send .txt to me so I can check what might be the problem.

 

[VilhoValittu]

I’ve decided to release my own developing tool for analyzing FIR filters.
FIR Compare lets you inspect the technical characteristics of FIR filters stored in WAV format.
Only 48khz samplerate is supported.

FIR Compare

 

[amitajitr]

Hey Vilho-thanks again for the amazing work
Am a beginner- i was trying to run DC on Auto mode for my 2.1 system. Each time it fails and returns delays as 0ms saying phase at XO freq ~ 20ms. Is there anyway to force decaycore to generate filters regardless

 

[VilhoValittu]

Hey Vilho-thanks again for the amazing work
Am a beginner- i was trying to run DC on Auto mode for my 2.1 system. Each time it fails and returns delays as 0ms saying phase at XO freq ~ 20ms. Is there anyway to force decaycore to generate filters regardless

Hi,

send me your measurement files to [email protected] with info of your OS and DecayCore's version number.

Is there anyway to force decaycore to generate filters regardless

No, I have to adjust limits.

 

[VilhoValittu]

Hi all,

I need feedback of new UI ( Modern @ DC ). You can test it in version --> v1.3.3

 

[archeoamp]

I prefer new look (but I never really liked the old one)
When I click on red button right down (Power Off) whole screen gets flooded with repeated
....
NetworkError when attempting to fetch resource.
NetworkError when attempting to fetch resource.
warnings
(running aarm64 version on RPI5)

 

[VilhoValittu]

I prefer new look (but I never really liked the old one)
When I click on red button right down (Power Off) whole screen gets flooded with repeated
....
NetworkError when attempting to fetch resource.
NetworkError when attempting to fetch resource.
warnings
(running aarm64 version on RPI5)

I know, I have to shutdown warnings, until ALL the bugs in new UI-motor are cleared.

But this program is like "use once and forget" so those warnings doesn't harm outcome.

 

[mkusan]

Version 1.3.5 installed, unlike older version this one can be accessed only from local machine for some reason. Visually it is a step up.

 

[VilhoValittu]

Version 1.3.5 installed, unlike older version this one can be accessed only from local machine for some reason. Visually it is a step up.

You should still be able to access it from another device on the same network by using the **edit** (change 127.... adress to your local ip) I will fix this issue to version 1.3.6 full address shown in the console. I’ll look into why this is less straightforward than it was in the previous version.

The program now uses a native Rust-based web transport instead of NiceGUI. This also reduces the package size by approximately 20 MB.