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

[Julf]

i think an option to store (and maybe restore) configuration and measurement in computed filter zip can be useful
also, the 352800 and 384000 rate over 192000 can be useful (i have few track with that, probably DSD ones)

That would be a rather odd conversion from DSD (as I assume the files are actually PCM, but converted from DSD).

 

[Kali-]

ofc, source are DSD (i think 64) converted by Volumio to PCM and passed to CamillaDSP plugin, and i got this value from the GUI
can't check now but i'm almost sure... ill confirm later

edit:
chatgpt confirm what i remember:

DSD64 has a sampling rate of 2.8224 MHz (64 × 44.1 kHz). When converted to PCM, the most common output rates are:

• 24-bit / 176.4 kHz (16:1 decimation)
• 24-bit / 88.2 kHz (32:1 decimation)
• 24/32-bit / 352.8 kHz (DXD) for professional processing and editing

The most common conversion for playback is DSD64 → PCM 24-bit/176.4 kHz, because it maintains an exact mathematical relationship with the original DSD sampling frequency.

 

[Julf]

ofc, source are DSD (i think 64) converted by Volumio to PCM and passed to CamillaDSP plugin, and i got this value from the GUI
can't check now but i'm almost sure... ill confirm later

I find DSD files a real hassle (a format that has to be converted to PCM for any sort of use and has very poor metadata support), considering the material has gone through PCM conversion in the studio processing anyway, so I store DSD-orginated stuff as PCM.

chatgpt confirm what i remember:

Chatgpt is a good first cut, but always requires verification - it does hallucinate quite a bit.

DSD64 has a sampling rate of 2.8224 MHz (64 × 44.1 kHz). When converted to PCM, the most common output rates are:

• 24-bit / 176.4 kHz (16:1 decimation)
• 24-bit / 88.2 kHz (32:1 decimation)
• 24/32-bit / 352.8 kHz (DXD) for professional processing and editing

The most common conversion for playback is DSD64 → PCM 24-bit/176.4 kHz, because it maintains an exact mathematical relationship with the original DSD sampling frequency.

88.2 also maintains an "exact mathematical relationship" (and even better, a decimating factor that is a power of 2 - Pretty much any two numbers have an "exact mathematical relationship").

 

[Vl_Po]

i think an option to store (and maybe restore) configuration and measurement in computed filter zip can be useful

Yes, that would be good.

 

[Kali-]

i know well AI can allucinate, but it just confirm that 352.8 kHz is not my allucination
i have to verify if Volumio have some kind of option to handle this conversion diffently

 

[Julf]

i know well AI can allucinate, but it just confirm that 352.8 kHz is not my allucination

Indeed, that is the sample rate used by DXD, the intermediate PCM format used to process DSD in the studio.

 

[VilhoValittu]

Measurement dither leak fix. V1.1.4_beta

Also small change : DC now remember if you change theme to light. Config is saved when START is pressed.

 

[landco1]

also, the 352800 and 384000 rate over 192000 can be useful (i have few track with that, probably DSD ones)

Audiophilia, senseless and merciless

 

[VilhoValittu]

i think an option to store (and maybe restore) configuration and measurement in computed filter zip can be useful
also, the 352800 and 384000 rate over 192000 can be useful (i have few track with that, probably DSD ones)

DecayCore already writes a Summary_*.txt file into the export ZIP, and that file records the effective values used by the program for the run in both manual and automatic modes, so the export is not missing run traceability today.

A fully restorable config/measurement bundle is a separate feature. That would move the ZIP from being an export package toward being a project/session bundle, which has its own compatibility and size implications.

For sample rates, 352800 and 384000 are valid edge-case targets, but they are not common enough to include in the default multi-rate set lightly. They fit better as optional advanced export rates above 192 kHz than as default outputs. I will add this to my todo-list.

 

[VilhoValittu]

DecayCore 1.1.4 is out

a few things worth mentioning.

Bass integration, rebuilt (v2) — The sub/main handoff now chases phase through the crossover instead of obsessing over a perfectly flat magnitude curve. Turns out the bass sounding tight and connected matters more than a graph looking pretty. Who knew. The result is a cleaner transition and better transients where the sub meets the mains.

Higher export rates on multi-rate — Added 352.8 kHz and 384 kHz. Do you need them? Probably not. Can you have them now? Yes. Match your playback chain exactly, no resampling required.

DSP / filtering refinements — More robust −6 dB calculation (more dependable crossover and bandwidth numbers), plus reworked stereo policy and filter generation with new guard thresholds and smoothing. Translation: cleaner filters, fewer edge cases reaching for the pitchforks.

As always — feedback and measurements welcome. If something looks off in your setup, post it here and I'll dig in.

**EDIT** Translated by Gemini from Finnish

 

[Julf]

DecayCore 1.1.4 is out

a few things worth mentioning.

Bass integration, rebuilt (v2) — The sub/main handoff now chases phase through the crossover instead of obsessing over a perfectly flat magnitude curve. Turns out the bass sounding tight and connected matters more than a graph looking pretty. Who knew. The result is a cleaner transition and better transients where the sub meets the mains.

Higher export rates on multi-rate — Added 352.8 kHz and 384 kHz. Do you need them? Probably not. Can you have them now? Yes. Match your playback chain exactly, no resampling required.

DSP / filtering refinements — More robust −6 dB calculation (more dependable crossover and bandwidth numbers), plus reworked stereo policy and filter generation with new guard thresholds and smoothing. Translation: cleaner filters, fewer edge cases reaching for the pitchforks.

As always — feedback and measurements welcome. If something looks off in your setup, post it here and I'll dig in.

Was that text generated by LLM ("AI")?

 

[VilhoValittu]

Was that text generated by LLM ("AI")?

Yes and no, translated from Finnish.

Edit. I will add info when I use translate help from Gemini.

 

[Julf]

Yes and no, translated from Finnish.

Darn, you should have left it in the original Finnish.

It just had the typical structure and typograpy of LLM-generated material (complete with em dashes).

For translation, I usually use DeepL, it is European and doesn't spy on me as much as Google (and I think the DeepL language model is actually better than Gemini for translation).

 

[VilhoValittu]

Darn, you should have left it in the original Finnish.

It just had the typical structure and typograpy of LLM-generated material (complete with em dashes).

For translation, I usually use DeepL, it is European and doesn't spy on me as much as Google (and I think the DeepL language model is actually better than Gemini for translation).

Thanks for tip! I will try this next time.
When I think in my native language, it sound's so stupid in English that I don't know what to do with that elf-language.

 

[Julf]

When I think in my native language, it sound's so stupid in English that I don't know what to do with that elf-language.

Yes, it clearly lives in a different part of the brain. Having lived in Amsterdam for 29 years, and being married to an American (so we speak English at home) I have lost a lot of Swedish (my first language) and pretty much all of my German, but not much of my Finnish. Clearly the Germanic languages overlap in the brain and displace each other, but Finnish has it's own private neural circuits...

 

[VilhoValittu]

Yes, it clearly lives in a different part of the brain. Having lived in Amsterdam for 29 years, and being married to an American (so we speak English at home) I have lost a lot of Swedish (my first language) and pretty much all of my German, but not much of my Finnish. Clearly the Germanic languages overlap in the brain and displace each other, but Finnish has it's own private neural circuits...

Länsirannikolta? Alan tästä eteenpäin laittamaan changelog.md tiedostoon myös alkuperäiset suomenkieliset päivitykset.

 

[Julf]

Länsirannikolta? Alan tästä eteenpäin laittamaan changelog.md tiedostoon myös alkuperäiset suomenkieliset päivitykset.

StadistaHelsingistä.

 

[VilhoValittu]

StadistaHelsingistä.

Kyl stadi on iha buli mesta.

 

[john61ct]

sub/main handoff now chases phase through the crossover instead of obsessing over a perfectly flat magnitude curve. Turns out the bass sounding tight and connected matters more than a graph looking pretty.

Sorry if OT, but

Do you think delays / timing tuning / phase alignment should all be done at the same time, with one toolset?

I would like my crossovers to be in an "infrastructure layer" kept fixed as the system is mobile, DRC kept separate, even presets for outdoors.

But different physical spacing requires different acoustic Time of Arrival (TOA) adjustments

and I'm now suspecting "phase alignment" is inextricably intertwined with that, So maybe everything in the Time domain needs re-doing at a new setup location?

 

[VilhoValittu]

Do you think delays / timing tuning / phase alignment should all be done at the same time, with one toolset?

In an ideal world, yes. But no program is perfect..

So maybe everything in the Time domain needs re-doing at a new setup location?

If you want a "perfect" result, then yes.
I'm pretty sure you'll find default settings that work 99% of the time. That way, you won't have to readjust the system every time.

OT: In my opinion, the DSP should handle crossover frequencies, such as the HPF, but the software still offers the option to bake the HPF into the fir-filter. The HPF consumes a huge amount of taps, which are then unavailable elsewhere. Of course, this isn’t a problem if the DSP is computer-based. But if you’re using a hardware DSP—which usually has a very limited number of taps—it’s better to use IIR filters and reserve FIR filters solely for phase correction.

This is how DecayCore's bass integration works. The user must set the delays, HPF, and LPF filters in their own DSP. The program only provides optimal values based on measurement data. CamillaDSP users will receive a pre-configured settings file, but they will likely need to modify it, since I cannot know the users’ internal routing order.

Translate help by DeepL