Talk:Proposal DC Management

Discussion
Koz wrote: I want to subtract a feature. I want Audacity to not pass DC. Ever.

I've seen the analysis coating the blackboard of why you need audio to respond all the way down to DC, but I'm here to tell you that it causes far more problems than it cures. DC is not sound and never has been.

I had to do some audio production in the field without my Cool Edit license, so naturally I fired up my Audacity. I got as far as adding silent stretches to the production and couldn't do it. It turned out, quite a bit later, that my show had a significant DC level on it and the silence generator didn't. I'm not in the habit of looking for non-audio signals in my audio show. It was a nasty surprise and should not have happened.

It could be argued that scientists use Audacity for its ability to manage data signals. Terrific. There can be a data version for those six people.

Stevethefiddle wrote: That is really something that your sound card should do (or rather, not do).

I guess it would be quite easy to implement by passing all new audio (recorded or imported) through a low frequency high pass filter, but there would (inevitably?) be some processing time overhead involved, so is it fair to impose this overhead on everyone just because some users have faulty hardware?

Koz wrote: the number of times this comes up, I'm betting a lot of people have local offset problems and either just haven't complained about it, or don't realize it's broken. No, people, effects are not supposed to pop, thump, and click when you apply them.

And audio programs are not supposed to pass out-of-band energy--either direction. I'm perfectly happy to have a preference where you can force Audacity to pass everything from DC to 100KHz, but it's not an audio editor in that case. Hewlett-Packard, Fluke, and other manufacturers call those signal generators and amplifiers, not audio products.

Waxcylinder wrote: Perhaps it should be a Preferences setting - but if so, the default should definitely be "Do not pass DC".

Gale Andrews wrote: I suspect from memory of responses made in the past we'd not want to get involved modifying a recorded signal in this way, even if it were technically possible (and I don't know enough about this kind of thing to comment in detail)... I know it doesn't stop the loss of headroom occurring, but a Feature Request for automatic removal of DC offset after recording (rather than just as an option in Normalize) might have more chance of being implemented).

Gale 13Jan10: As well as processing time, what about people who use Audacity exclusively to test (correctly generated) signals? Looks to me like this ought to be a preference, even if default is to filter.

Peter 24Feb10: Implementing this proposal would have a key advantage of removing control of DC Offset from the Normalize dialog box. I have never thought it should belong there, it always looks out of place and confusing.

Transferring from Pending FRs a comment that Koz made on the forum: DC isn't audio--ever--and has no business in an audio channel. That's a work-around and should probably have its own tool. That will make it easier delete when it isn't needed any more. But back to business. The design center for "Normalize" is simplicity. All selected audio tracks are changed so the hottest peak arrives at one selected value either A) using the hottest one, or B) independently. Default is A. If you select B, you are given a warning about damaging the musical stereo image. That's it. One sentence. Any decisions or requirements above that are the providence of Amplify or other effects tools. This business of trying to explain that to Normalize what a lot of people consider "correctly" requires the Amplify tool is a work-around.


 * Steve: A square wave with a frequency in the audio range is most certainly "audio", but contains periods of "DC" (constant voltage). If high-pass filtering was used on all input, then it would be impossible to record a square wave and have it look like a square wave. I'm strongly in favour of "linked stereo" as the default behaviour in the Normalize effect.