Replaygain at high sample rate, currently replaygain only works upto 48 khz Options

[Ernst]

Hi,

I noticed that replaygain (as applied by metaflac) only works on tracks with a sample rate upto 48 khz.
I'd like to apply it to all my audio files and I do now have some with 88.2, 96, or 192 khz sample rate.
Looking into the code I see the following:

CODE

FLAC__bool grabbag__replaygain_is_valid_sample_frequency(unsigned sample_frequency)
{
    static const unsigned valid_sample_rates[] = {
        8000,
        11025,
        12000,
        16000,
        22050,
        24000,
        32000,
        44100,
        48000
    };
    static const unsigned n_valid_sample_rates = sizeof(valid_sample_rates) / sizeof(valid_sample_rates[0]);

    unsigned i;

    for(i = 0; i < n_valid_sample_rates; i++)
        if(sample_frequency == valid_sample_rates[i])
            return true;
    return false;
}

In other words, a limit, but it looks as if I could just add other values. However, 96khz would go over the unsigned 16-bit integer limit, so changing to 32-bit integers might be necessary. Would this make anything run into trouble? I've yet to try, which I'll hopefully do later today.

Now the guesswork:
Have these rates been chosen as commonly used?
Is this check at all necessary? Isn't it enough for the sampling rate to be a positive integer?
Is this only in the flac implementation or is this part of the proposed replaygain specification?
Is the reason for the lack of higher sampling rates that at the time calculation for them would have been very slow (in this case it would be better to put up a warning instead)?
Is this because the replaygain reference values are based on psychoacoustics and those are lacking for frequencies we don't hear but which would be present in the higher sampling rate signals?

[romor]

Quote from David's link:

The extended gain analysis tables in Foobar2000 (and the derivatives that copied it) are wrong.

Here is how to show that it's wrong. Use <http://www.daniweb.com/software-development/python/code/263775> to create
a 1 kHz signal using a 48 kSamples/sec rate (48.wav) and and a 192
kSamples/sec rate (192.wav). I modified the script to generate 2s of
samples.

Because the underlying signal is the same (1kHz with a fixed amplitude) the perceived loudness should be identical,
independent of the sampling rate.

Is it?



I used that messy script, which shows itself on Google on multiple places, just to confirm that we are talking about same thing, but that's not the way to treat Python. Numpy exists for reason, even if someone's testing procedure is limited on only two audio files. It's just a shame to use bare Python for audio testing.

Assuming:

CODE

import numpy
from scipy.io import wavfile
from scipy.signal import chirp

Here are some oneliner functions to bake the data, just follow your imagination, it's fast and easy:

CODE

def np_tone(fs, freq=440, t=2): return np.array(16384*np.cos((2*np.pi*freq/fs)*np.arange(fs*t)), dtype=np.int16)

def np_rand(fs, t=2): return np.array(16384*np.random.random_sample(fs*t), dtype=np.int16)

def np_chirp(fs, t=2): return np.array(16384*chirp(np.linspace(0, t, fs*t), fs/2, .002, t), dtype=np.int16)

then create for example 1 kHz tone in stereo (double mono):

CODE

data = np_tone(44100, freq=1000)
wavfile.write('44100.wav', 44100, np.column_stack((data, data)))

BTW, RG for some reason does not work for 176400 both with wvgain, and with same table: http://goo.gl/JwxaT using other tool. Perhaps coefficients are bad for that rate.