IPB

Welcome Guest ( Log In | Register )

Replaygain at high sample rate, currently replaygain only works upto 48 khz
Ernst
post Oct 5 2010, 14:22
Post #1





Group: Members
Posts: 3
Joined: 5-October 10
Member No.: 84356



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?
Go to the top of the page
+Quote Post
 
Start new topic
Replies
DVDdoug
post Oct 5 2010, 19:09
Post #2





Group: Members
Posts: 2440
Joined: 24-August 07
From: Silicon Valley
Member No.: 46454



I'll make a couple of guesses & assumptions... biggrin.gif I can't think of any reason why the code couldn't be revised to work with higher sample rates.

QUOTE
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.
I don't know what you're getting at here... There's no relationship between the bit-depth and the sample rate. I haven't studied the code, but most DSP software converts the raw audio data to 32-bit floating point and then converts back at the end.

QUOTE
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?
I assume the psychoacoustic model will treat anything supersonic as inaudible. And, the loudness-curve filters have to be adjusted for the sample rate in any case... since digital filters are simply working on a sequence of numbers, in order for the filter to work properly it has to "know" the sample rate.
Go to the top of the page
+Quote Post
Ernst
post Oct 6 2010, 05:23
Post #3





Group: Members
Posts: 3
Joined: 5-October 10
Member No.: 84356



QUOTE (DVDdoug @ Oct 5 2010, 20:09) *
I'll make a couple of guesses & assumptions... biggrin.gif I can't think of any reason why the code couldn't be revised to work with higher sample rates.

QUOTE
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.
I don't know what you're getting at here... There's no relationship between the bit-depth and the sample rate. I haven't studied the code, but most DSP software converts the raw audio data to 32-bit floating point and then converts back at the end.

In some compilers int still means 16-bit. So the number 96000 could not be represented.

QUOTE (lvqcl @ Oct 5 2010, 20:19) *
QUOTE (tuffy @ Oct 5 2010, 22:01) *
I think what's missing is a set of equal loudness filter coefficients for higher sampling rates. If someone could crank out a set of them, it shouldn't be hard to add.


wvgain accepts input samplerates up to 192000. From wvgain.c:

CODE
// These are the filters used to calculate perceived loudness. The table data was copied
// from the Foobar2000 source code.



Maybe I'll copy from there to metaflac to see what works.

QUOTE (Yirkha @ Oct 5 2010, 22:48) *
Some filter coefficients in ReplayGain need to be changed for different sample rates. The original implementations supported only the rates listed above, but this has been subsequently amended later in some programs. For example, Menno kindly provided additional values for fb2k's RG scanner in 2003, I don't know about the other implementations. Further, this topic might be interesting as it deals with a similar question.

Nice links.

Of course I did not yet get around to trying something, probably soon.
Go to the top of the page
+Quote Post
saratoga
post Oct 6 2010, 19:01
Post #4





Group: Members
Posts: 4715
Joined: 2-September 02
Member No.: 3264



QUOTE (Ernst @ Oct 6 2010, 00:23) *
QUOTE (DVDdoug @ Oct 5 2010, 20:09) *
I'll make a couple of guesses & assumptions... biggrin.gif I can't think of any reason why the code couldn't be revised to work with higher sample rates.

QUOTE
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.
I don't know what you're getting at here... There's no relationship between the bit-depth and the sample rate. I haven't studied the code, but most DSP software converts the raw audio data to 32-bit floating point and then converts back at the end.

In some compilers int still means 16-bit. So the number 96000 could not be represented.


In c int size is generally thought of as CPU dependent, rather then compiler dependent. So on a 16 bit machine (e.g. a 286) int might be 16 bit. However, most likely metaflac would not compile on such a device without being ported to a 16 bit architecture. Its rare for ordinary programs to function on machines with int < 32 bits.
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th April 2014 - 11:26