0
$\begingroup$

i need to apply a STFT to some music audio files but i can't understand if i should remove the mean or not. I know that for stochastic signals that is a must and that sometimes also necessary for deterministic ones but i can't figure out whether it's a proper procedure or not for audio signals.

To be more specific i'm referring to the average of a window at a particular time t, not of the whole signal since (correct me if i'm wrong) it doesn't make any sense to me to remove that since it's time dependent. Also, if i were to not remove the mean, wouldn't that cause spectral leakage since there is a minimum retrievable frequency for the FFT?

Thanks in advance

$\endgroup$
1
  • $\begingroup$ in my opinion, it's good to run audio through a DC-blocking filter before any processing. but in the processing that follows, do nothing more to remove DC (like from the spectrum in the STFT). $\endgroup$ Dec 30, 2020 at 8:52

1 Answer 1

1
$\begingroup$

What are you planning to do with the STFT?

The time-domain mean of the signal is the DC component and this should usually be close to zero for audio. Any DC offsets or low frequencies below the threshold of hearing (eg. around 20Hz, give or take) are generally considered defects and usually removed by filtering during production if present to a significant degree, since they usually serve no purpose other than wasting some dynamic range. Microphones don't record it and speakers don't reproduce it. In fact most commercial music is typically high-pass filtered closer to 40-50Hz as few consumer systems can reproduce meaningfully below that.

Windowing of the STFT will usually still give you a slightly non-zero value in the DC bin, but this is usually quite small, at least if we the window size is reasonable compared to the wavelengths of the frequencies present. For algorithms such as fast convolution it's important to preserve and processes this value as-is such that frames align correctly. This is also true for any spectral processing that works with windows that are shorter or similar to the wavelengths involved (eg. less than 100ms or so), yet seeks to reconstruct the original signal.

For typical audio analysis duties there is usually no need to explicitly remove it, since it's presence can just as well be ignored. If you are working with very short windows, then spectral leakage might be an issue, but often in audio one is stuck working with fairly large windows (to get some sort of resolution at the lower end of hearing) and/or window functions with good dynamic range (to deal with the more significant spectral leakage at frequencies actually present), so spectral leakage from DC is usually essentially irrelevant (or alternative the apparent spectral leakage around DC is more likely to come from side-bands of the actual desired low frequency content).

So in general I would say "no" with the caveat that the possible applications of STFT in audio are quite varied and you likely need to evaluate each specific application separately, especially when working with short windows, where as with longer windows it usually doesn't make a whole lot of difference, because the expectation is that the mean is zero.

Clarification on common formats based on the comment:

Logically the audio signals are usually treated as normalized values in range [-1,+1] where $\pm1$ are the clipping thresholds (ie. 0dB "full scale"). In floating point formats the values are usually stored as such, while in integer formats the values are treated as fixed point such that the minimum value is treated as -1 and the maximum value as one quantization step below +1 (though especially in software the maximum positive value is sometimes treated as +1 and the minimum value as one quantization step below -1, but this is generally not very significant as long as one is consistent).

For bit-depths of 16-bits or higher, the values are usually (eg. WAV) stored as signed, but 8-bit samples are sometimes (eg. WAV again) stored as unsigned. When stored as unsigned, the values still logically represent bipolar signals such that the designated mid-point (eg. usually 128 for 8-bit unsigned) represents the logical value of zero; in this case the signed fixed point value is simply biased into the unsigned range and should be reverse-biased back into a signed value before processing.

Hope this helps.

$\endgroup$
5
  • $\begingroup$ Thanks. The goal is similar to onset detection so i was planning to use 10-100 ms windows as common in literature. That aside i can't understand how can the mean be zero on long windows, since the data (wav) is always positive the mean should be >=0 for every window size... do i need to remove the total mean of the audio to center it on 0? but even then the window size in this case is too low so i guess for this application doesn't matter $\endgroup$ Dec 30, 2020 at 0:40
  • $\begingroup$ Wav-files can store data in a lot of formats, but assuming linear PCM if it's 16-bits or more (including floats) it's actually stored signed with a zero-mean. This is also what most audio processing APIs on computers expect. For 8-bits it's stored unsigned with 128 as the midpoint value, but for processing purposes this midpoint should be treated as zero (ie. convert to signed format first). $\endgroup$
    – myzz
    Dec 30, 2020 at 5:55
  • $\begingroup$ Added some more clarification about formats into the answer. $\endgroup$
    – myzz
    Dec 30, 2020 at 6:36
  • $\begingroup$ Thanks a bunch that was really helpful $\endgroup$ Dec 31, 2020 at 0:28
  • $\begingroup$ is this about onset detection or is it about removing the well-defined DC component in an offset-binary WAV file? if it's an 8-bit WAV file, you must subtract 0x80 or 128 from every 8-bit unsigned value to get the bipolar value intended. but in 16-bit (or more) WAV files, the samples are stored as 2's complement and there is no offset to remove. but that is not the same problem as the general case of removing DC in audio files and when that is needed. if you're doing onset detection, you do generally want to remove DC with a DC-blocking filter. but onset detection is more than that. $\endgroup$ Dec 31, 2020 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.