librosa.feature.rms inconsistency - y vs S

Description

When calling librosa.feature.rms, the result using a wave y and the result using the spectrogram S are different.
This is because the algorithm is not correctly implemented to satisfy the Parseval’s equation.

Specifically, the direct current bin S[0] (and only if n_fft is odd, the sr/2 bin S[-1]) has twice as much influence as the other bins.

Steps/Code to Reproduce

import numpy as np
import librosa

# set paramters
np.random.seed(0)
frame_length = 2048
hop_length = 512
center = True

# make a wave and its spectrogram
y = np.random.rand(3000)  # wave, DC component is about 0.5 because the range of np.random.rand is [0, 1)
S = librosa.magphase(librosa.stft(y,  # spectrogram
        n_fft=frame_length,
        hop_length=hop_length,
        window=np.ones,
        center=center))[0]

# calculate RMS
rms1 = librosa.feature.rms(y=y, frame_length=frame_length, hop_length=hop_length, center=center)
rms2 = librosa.feature.rms(S=S, frame_length=frame_length, hop_length=hop_length, center=center)
print(rms1)
print(rms2)
print(np.allclose(rms1, rms2))

Expected Results

rms1 and rms2 are almost the same.

Actual Results

[[0.57401353 0.58105711 0.58252662 0.58571533 0.58668334 0.58252178]]
[[0.75760764 0.76713306 0.76892614 0.7742523  0.77579546 0.77086043]]
False

Versions

Darwin-18.7.0-x86_64-i386-64bit Python 3.7.3 (default, May 28 2019, 02:11:32) [Clang 10.0.1 (clang-1001.0.46.3)] NumPy 1.17.4 SciPy 1.3.3 librosa 0.7.1

[lostanlen]

@bmcfee one explanation could be the DC component in np.rand, which is nonnegative

[onkyo14taro]

There are two causes for calculation errors in the previous implementation (correct vs. previous):

1. Constant for averaging
   • if frame_length is even, 1/(2M)^2 vs. 1/(4M(M+1))
   • if frame_length is odd, 1/(2M+1)^2 vs. 1/(4M(M+1))
2. The bias of specific terms
   • if frame_length is even, none vs. |S[0]|^2 + |S[M]|^2
   • if frame_length is odd, none vs. |S[0]|^2

The larger frame_length (i.e., n_fft) is, the smaller the influence of these error factors is. However, if the value of frame_length is small or the DC component (i.e., |S[0]|^2) is relatively large, the calculation error cannot be ignored.

I guess that the reason why the previous implementation passed the previous test is as follows.

• frame_length was large enough to ignore the calculation error.
• The previous test code only has been using live recorded audio. When recording sound, it is thought that the influence of the DC component is reduced due to the performance of the microphone and the effect of the high-pass filter. By nature, the DC component of the audio waveform is small. However, when a wave with a large DC component is used, the previous code produces a large calculation error.