Difference between revisions of "Proposal DC Management"

From Audacity Wiki
Jump to: navigation, search
m (DC Management moved to Proposal DC Management: More family pages)
(No difference)

Revision as of 11:21, 12 December 2009

This page contains detailed discussion about better management of DC offset, which is asked for on Feature Requests.

What is this about?

DC offset is an offsetting of a signal from zero. On the Audacity waveform it would mean that the waveform in default view appears not to be centred on the 0.0 horizontal line.

  • A sound that has DC offset will not be at its loudest possible volume when normalized (because the offset consumes headroom). This problem can possibly extend to the mix as a whole, since a sound with DC offset and a sound without DC offset will have DC offset when mixed.


  • DC offset can cause inaudible low level distortion (which becomes audible when other filters are applied or if the sound is compressed upon export)


  • It can cause audible clicks at the start and end of tracks when played back (even without editing)
Left and right channels of a recording displaying serious DC offset

The cause is almost always a fixed voltage offset before the analogue signal is converted to digital values. This voltage is known as a DC offset, and is normally so small as to not be noticeable, but with defective or poor quality hardware it may become big enough to to be a problem. This can also happen if another piece of equipment in the audio chain is defective and producing a large voltage with is being fed through to the computer.

A waveform with DC offset should be corrected at once by running Effect > Normalize with the option checked "Remove any DC offset (center on 0 vertically)". Uncheck the "Normalize maximum amplitude..." box unless you want to run Normalize as well - see here for what Normalize does and when to use it.

Note: Removing offset via this effect does not reinstate the loss of headroom, so you should still correct the DC problem at source.


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).