MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007439ardourbugspublic2017-08-03 03:492017-10-11 00:56
Reporterjohmue-eo 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version5.X git (version in description) 
Target VersionFixed in Version 
Summary0007439: Attack and release behavior of a-comp questionable.
DescriptionCurrently a-comp implements attack and release by the following two lines in a-comp.c:503

Ly1 = fmaxf(Lxl, release_coeff * acomp->old_y1+(1.f-release_coeff)*Lxl);
Lyl = attack_coeff * acomp->old_yl+(1.f-attack_coeff)*Ly1;

where Ly1 is the gain reduction without attack and release taken into account. Lyl is the GR with attack and release. old_y1 is the GR of one sample in the past.

So the first line slows down the decrease of the GR by the release coefficient whereas the second line slows down *any* change in GR, regardless if it's an increase or decrease.

So this means that the current a-comp's attack parameter also affects the release behavior. According to my understanding this shouldn't be like that.

The attack and release behavior described in wikipedia (https://en.wikipedia.org/wiki/Dynamic_range_compression#/media/File:Audio_Compression_Attack_and_Release-2.svg [^]) would look like this.

if (current_gainr < old_gainr) { // Compressor is releasing
    current_gainr = release_coeff*old_gainr + (1.f-release_coeff)*current_gainr;
} else if (current_gainr > old_gainr) { // Compressor is attacking
    current_gainr = attack_coeff*old_gainr + (1.f-attack_coeff)*current_gainr;
}

I have made these changes to a-comp.c and pushed them to https://github.com/johannes-mueller/ardour/commits/a-expander [^] so that the differences can be tested.

IMHO this behavior is more logical than the one a-comp currently does. Maybe I'm wrong and the current behavior is intended for good reason.

(The a-expander branch also includes a new a-expander plugin – hence the name. Implementing a-exp based on a-comp I came across this issue.)


So if this is considered a bug we can eventually merge the a-expander branch, when it's ready. If it's considered a feature or a wontfix bug (in order not to change existing mixes), I will drop the commit in a-expander. In the letter case I will probably release a johmue-comp outside of Ardour for those who prefer this kind of behavior.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0019975)
magnetophon (reporter)
2017-08-14 11:09

I totally agree: release should be independent of attack.
Quite often you want a slow attack and a fast release.
(0020051)
zamaudio (reporter)
2017-10-11 00:14

I consider this report valid as a bug in the original compressor algorithm from zam-plugins. I will be pushing out a new release of zam-plugins with the fixed algorithm. Thank you for noticing and reporting this. I think we should also fix it in a-comp (?)
(0020052)
johmue-eo (reporter)
2017-10-11 00:56

I have a branch in ardour here: https://github.com/johannes-mueller/ardour/pull/1 [^]

Unfortunately I am busy now with other stuff but I will file this PR in a couple of weeks. One important question is if we change the URI because the fix will change existing sessions.

- Issue History
Date Modified Username Field Change
2017-08-03 03:49 johmue-eo New Issue
2017-08-14 11:09 magnetophon Note Added: 0019975
2017-10-11 00:14 zamaudio Note Added: 0020051
2017-10-11 00:56 johmue-eo Note Added: 0020052


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker