Like a few other folks in this forum recently, I've been spending time getting away from music and sound design, and studying audio programming(DSP eventually). However, in looking at samplerates and samples, I've been tooling with numbers and my attention has been brought to the fact that certain ideas are not expressable in integer sums at given bitrates. Example: If I record a loop of music that is going at a perfect(lets assume its mathematically perfect, for the sake of this illustration) 160 BPM, in two formats, 44.1 kHz and 48 kHz, we can make the following calculations: in the 48 kHz file, 1 minute of audio takes (48k * 60 = 2.88M samples), which gives each beat (1/160 min) a value of (2.88M / 160) = 18,000 samples. Wonderful. However, in the 44.1 kHz file, 1 minute of audio takes (44.1k * 60 = 2.646M samples), giving each beat (1/160 min) a value of (2.646M / 160) 16537.5 samples. Now, I admit Im just a beginner ATM in audio programming, but theres no such thing as half a sample, right? So, to my tired eyes, holding all other things perfect, its not actually possible to capture a perfect 160 beats in one "real life" minute in a 44.1 kHz file. While there will be 160 percieved perfect beatlengths in the file, each beat will have to take up either 16537 or 16538 samples , and the time it will take in playback will either accumulate to just slightly over or under one minute(59.998 sec or 60.002 sec by my numbers). Over minutes or hours, you could see a serious slippage away from what was supposed to be a perfect 160 BPM piece of music. Am I putting too much value in the discrete samplerates used in audio? Does this all just come out in the wash of interpolation and such? Am I just conjuring up number voodoo or is this a real issue in audio recording? I get the feeling Ive missed an idea somewhere and Im making up problems.

First, I'm not an audio programmer, so take everything I say with a grain of salt.

It looks like your sample scenario is a non-issue. Although one beat may be represented as 16537 or 16538 samples, 160 beats will still be represented by precisely 2.646 M samples. Consider that there are an even number of beats, so for each beat represented by 16537 samples, another beat will be represented by 16538.

I'm not sure there are any realistic examples where this problem would appear at a sample rate of 44.1 or higher. You can encode any BPM to precisely one minute. You'd have to shorten or lengethen beats by a little bit, but you can always end up with a precise minute, and no one could ever hear the difference. At lower sample rates, it could certainly be an issue, though, so if you're looking to compress data as much as possible and need perfect synching with no audible breaks, you could get issues.

I think that studying this would fall under the general area of float representations. I've studied that a bit for its use in audio work, but never quite enough :).

Quote: Original post by krikkit
While there will be 160 percieved perfect beatlengths in the file, each beat will have to take up either 16537 or 16538 samples , and the time it will take in playback will either accumulate to just slightly over or under one minute(59.998 sec or 60.002 sec by my numbers). Over minutes or hours, you could see a serious slippage away from what was supposed to be a perfect 160 BPM piece of music.

No... the samples are merely that, 'samples'. It doesn't mean your timing will be out, just that to represent a given timespan at a given rate will require a fraction of a sample, and that samples don't always fall precisely on arbitrary timing boundaries such as minutes. Nor do you allocate a specific and fixed number of samples per beat. Why would you?

It's just like representing 1/3 of a dollar requires a fraction of a cent - it doesn't mean that 1/3 of $1000 turns out to be $300 or anything. You don't multiply up the errors.

Okay, seems reasonable that I'm abstracting way too far.

Would you say that, in a situation where you are trying to move from real-world ideas to expressing it in terms of discrete values (like samples in a samplerate) that it's "okay" to deal with fractions, then?

In other words, lets say you're given a .wav file of a music loop, and then tasked with determining the BPM of it, based on regions of time (time t represents x beats, or delta-t represents one "beat"), then in accordance with my scenario above, if I tried to represent each beats by an integer amount of samples, I could be incorrectly representing the reality of the sounds, and introducing my own errors by rounding/truncating to integer sample lengths, right? And therefore I should allow room in my intermediate math for floats and fractions?

I'm working on something similar to this idea, and I can prove that my ideas work on paper, but when I codify it to samples in a file I keep introducing wild error. This might be my problem then?

Quote: Original post by krikkit
Okay, seems reasonable that I'm abstracting way too far.

Would you say that, in a situation where you are trying to move from real-world ideas to expressing it in terms of discrete values (like samples in a samplerate) that it's "okay" to deal with fractions, then?

Samples in a sample rate will almost always be a discrete integer value. If you meant samples in a measure|beat|arbitrary-time-span, then yes.

Quote: In other words, lets say you're given a .wav file of a music loop, and then tasked with determining the BPM of it, based on regions of time (time t represents x beats, or delta-t represents one "beat"), then in accordance with my scenario above, if I tried to represent each beats by an integer amount of samples, I could be incorrectly representing the reality of the sounds, and introducing my own errors by rounding/truncating to integer sample lengths, right?

I think you're making this sound more complex than it actually is. Samples are just measurements taken at equally spaced intervals. There is absolutely no guarantee that they will be taken at points that divide equally into whatever tempo you're playing at. Therefore measuring time in integer samples is like measuring distance in integer yards - you're gonna lose some inches when measuring most distances, because yards aren't precise enough to fit every distance exactly.

Simple mathematical thought experiment: imagine a tempo of 44101 beats per second (yes, per second). Now imagine your sampling rate is 44100 samples per second. Each beat there lasts slightly less than a sample, so there is absolutely no way whatsoever than you can represent a beat with an integer number of samples. 1 sample per beat is too many, 0 samples per beat is too few. Any situation where the beats per second is not a factor of the samples per second is going to leave you with a remainder in the division, meaning an integer loses information.

Yeah, thats pretty clear now. I had a hole in my head that said "Since you can only measure the file in samples, therefore the time within the file must be expressibly in integer samples as well."

Thanks for the input.