1
$\begingroup$

This is my first dive in DSP. I would like to familiarize myself with frequency analysis. I have two audio tracks which should be digitized at 16bit-44.1kHz and 24bit-192kHz (music, presented as a 24bit-192kHz sample) respectively.

I wanted to identify the effect of the low-pass filter around the Nyquist frequency (22.05kHz and 96kHz respectively).

Edit: I completely reworked the question.


Software used:

I basically estimated the power spectral density using Welch's method as implemented by scipy.signal.welch in the Scipy library of the Python programming language.

Basically, I used a script equivalent to:

import numpy as np
from matplotlib import pyplot as plt
from scipy import signal
from waveio import readwav

# Load data from one channel (#0) for each sample file 
wav192 = readwav("24b-192khz.wav")[:,0]
wav44 = readwav("16b-44khz.wav")[:,0]

# DoE: 2 sample size and two windows types
chunks = [256, 4096]
windows = ["hanning", "boxcar"] # boxcar is rectangular

# Prepare a figure
plt.figure()
# Calculate density spectra and plot
for N in chunks:
    for w in windows:
        f, Pxx44 = signal.welch(wav44, fs=44100, window=w, nperseg=N, nfft=2*N, scaling="density")
        plt.semilogy(f, Pxx44)
plt.legend(["chunk=%d; window=%s"%(c, w) for c in chunks for w in windows])
plt.xlabel("Frequency (Hz)")
plt.ylabel("Density (I$^2$/Hz)")

The power spectral density of the 44.1kHz audio sample:

44100Hz 16bit

Which is basically just as expected:

  • The chunk size, i.e. the number of samples per fft-transform segment in the real domain, does not change the density a lot if a Hann window is used.
  • The chunk size effect is clearly visible with the boxcar (rectangular) window. From what I understand, this is because of spectral leakage which diminishes as the chunk size increases. Is that correct?
  • The low-pass filter effect at the Nyquist frequency (22.05kHz)

So far, so good.


The power spectral density of the 192kHz audio sample:

192kHz 24bit

Good point:

  • Same behaviour in regard to the chunk size and the window. Is spectral leakage really that strong? That's pretty impressive.

Oddities:

  • What the heck is happening?
  • Where is the low-pass filter near the Nyquist frequency?
  • Why are very-high frequencies even increasing? Could that be related to the choice of the windowing function?

From my interpretation, there is no low-pass filter visible because basically no audio system would go above 192kHz and generally, the software/hardware creator are smart enough to apply a low-pass filter designed with regard to the actual output bandwidth of the audio system.

As for the increasing audio signal above 57kHz, I really can't explain it: the original audio sample is some classical music. I wouldn't expect any instrument to generate louder sounds in that range or frequencies. Any idea? Could this be an example of upsampling?

$\endgroup$
  • $\begingroup$ I don't know the implementation details of Audacity (and I guess, most other people here don't either). So it might be a good idea to try to reproduce the result using some tool like Matlab/Octave. Then you know exactly what's going on. $\endgroup$ – Matt L. Jul 11 '15 at 14:09
  • $\begingroup$ as Matt L already commented even though many of us generally have seen the interface of that nice program, programming details are out of scope. Nevertheless, I really cannot understand what you mean by the spectral analysis technique you just described. I have never seen such a technique in any programs/application... that chunk size ? could it be FFT size ? or it seems like a spectrogram/stft in 1 dimension...? $\endgroup$ – Fat32 Jul 11 '15 at 14:19
  • $\begingroup$ In my original question, I said I had a problem with Python. But I identified it, so I will update the question really soon with data finally coming from a decent programming language with all the details included! Sorry for the terms, I'm really new to DSP, and translating to English does not make it any better. The chunk size is the FFT size, indeed. This is what you would call a periodogram. But I'll come back with a working script and comparable data. The window I'm talking about is the filter function used on each of the FFT sample. $\endgroup$ – user13706 Jul 11 '15 at 14:43
  • $\begingroup$ Took some time: Int24 is not a native Python type. But whatever, here is the updated version of my question! :) $\endgroup$ – user13706 Jul 11 '15 at 20:02
0
$\begingroup$

If you look at the Rectangular window the best its rejection gets is about 40 dB. So that behavior, especially obvious in the bottom plot, for the rectangular window is to be expected.

I don't know for sure if this explains everything but look at the level between your peak signal and the high-frequency components. There is almost 60 dB of rejection there. I've always heard that a good rule of thumb is to get 60 dB of rejection from your filters. I know that's not the full 96 dB offered by 16-bit music, but I bet you'd be hard pressed to actually hear that. Of course, there's the silliness of having music at that sample rate. Humans just can't hear anything above around 20 kHz, give or take. This article gives a good summary of the issues. It also brings up a good point, that that sample rate has the potential to pick up harmonics and other high-frequency distortion caused by equipment and electronics, despite the fact that we can't hear it. Perhaps something like that is going on?

$\endgroup$
  • $\begingroup$ Thank you! I now have a more complete view of windows' effect on the signal and as you said, this completely explains the difference in the spectra with regards to the window type. That's now clear in my mind. $\endgroup$ – user13706 Jul 12 '15 at 13:19
  • $\begingroup$ Concerning the sample rate, I think I quite perfectly understand the matter. In fact, I got interested in DSP precisely to understand the discussion between pro and con high sample rates. But what seems clear to me now is not clear for everyone. The samples I used were given on a website to "listen to the blatant quality difference between samples of different sample rates" (with a complete disregard for the ear and the audio hardware bandwidth). So I'm trying to find ways to prove that if there is any difference, it should only be distortions due to aliasing. $\endgroup$ – user13706 Jul 12 '15 at 13:32
  • $\begingroup$ But looking at the 192kHz power density, I was wondering whether the sample was upsampled from 44.1kHz. And instead, I saw what you see today: higher frequencies are not cut. On the contrary, they are present and attenuated only at 5 orders of magnitude from DC. That's the range of attenuation you have BEFORE filtering, in the 44.1kHz sample. If there is no hardware filtering, such a sample would definitely alias and create distortion... $\endgroup$ – user13706 Jul 12 '15 at 13:33
  • $\begingroup$ Finally, do you have any additional comment concerning the "peak" at frequencies above 57kHz. That could very well be noise from the equipment or the electronics but since this is sold as "very high quality" audio, having this king of noise problem would completely defeat the purpose. I mean, even from the marketing technicaly-impaired point of view (which is "ohh! bigger numbers! therefore this is better and should be sold twice the price"), if the higher frequencies are filled with nothing but random noise, there is nothing left to discuss about, right? $\endgroup$ – user13706 Jul 12 '15 at 14:57
  • $\begingroup$ What do you mean by cut? Usually when you do upsampling or resampling that will involve spectral copies of the original signal. However, a filter is integrated in that reduces the level of those spectral copies. But I've seen, especially in noiseless or low noise signals, examples where the original signal is present, along with obvious copies of the original that are just reduced by 50 or 60 dB. This doesn't appear to exactly be the case here, but what I'm saying is that 50-60 dB below the peak IS usually considered filtered and "cut," or removed. $\endgroup$ – Eric Carlsen Jul 13 '15 at 0:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy