bitflipper


Something I'd not given any thought to before: SRC for sample libraries. Obviously, SONAR needs to convert a 44.1 sample library to 48 if your project's at 48. Not a big deal. But what if you're not rendering/importing audio, just playing back MIDI-driven samples? Would that not require constant and continuous SRC every time you hit the spacebar? 

Just do the SRC at the plug's output.

Not really any different than a plug that oversamples for processing purposes.

Just curious, if I am at 48K and I pull in some 44.1K samples for a track does the sound card just fill in the extra bits with 0s?

 
You're confusing sample rate with bit depth.  Bit depth is the 16bit / 24bit setting, and yes, if you up 16bit data to 24bit, the least significant bits are simply tacked on as 0's.

Sample rate conversion is basically mathematically guessing where the signal lies at the time of the output sample based on the 2 closest input samples.  They've gotten really good at that math these days.  The best plan used to be to simply use the sample rate of your target medium, 44.1k for audio CD and 48k for video / DVD.

I once read a funny analogy to this

Sample rate is how fast the tape speed is.  
Bit depth is how wide the tape is. 

wogg
Sample rate conversion is basically mathematically guessing where the signal lies at the time of the output sample based on the 2 closest input samples. 

It is NOT guessing and it is NOT based on only the 2 closest input samples. That's how people often assume it works, but it's doesn't work that way.
The value of a new sample between two existing samples is calculated and the calculation is based on a series of samples. The accuracy of the result is largely a factor of how much processing power you want to throw at it, but with the power available with modern CPU's there's really no reason for SRC's to cause problems. 

Its my understanding that you can't change the sample rate of a project that already contains audio. Am I wrong?

drewfx1

bitflipper


Something I'd not given any thought to before: SRC for sample libraries. Obviously, SONAR needs to convert a 44.1 sample library to 48 if your project's at 48. Not a big deal. But what if you're not rendering/importing audio, just playing back MIDI-driven samples? Would that not require constant and continuous SRC every time you hit the spacebar? 

Just do the SRC at the plug's output.

Not really any different than a plug that oversamples for processing purposes.

Exactly my point. Oversampling within plugins increases CPU usage, which is why most users only turn it on for rendering. An underpowered machine like mine might not manage 40 or 50 oversampled plugins. 


If I was using 48KHz as my project samplerate, every Kontakt/SampleTank/Omnisphere/Alchemy sample would require real-time SRC every time I played back the project, with no option to avoid it other than rendering the tracks. 


That got me wondering if sample-based projects might be significantly more CPU-efficient if the project SR was the same as the sample libraries.

bitflipper

drewfx1

bitflipper


Something I'd not given any thought to before: SRC for sample libraries. Obviously, SONAR needs to convert a 44.1 sample library to 48 if your project's at 48. Not a big deal. But what if you're not rendering/importing audio, just playing back MIDI-driven samples? Would that not require constant and continuous SRC every time you hit the spacebar? 

Just do the SRC at the plug's output.

Not really any different than a plug that oversamples for processing purposes.

Exactly my point. Oversampling within plugins increases CPU usage, which is why most users only turn it on for rendering. An underpowered machine like mine might not manage 40 or 50 oversampled plugins. 

Remember that the oversampled plugins are also doing all of their work at the higher sample rate, which is the major factor in increasing the CPU usage.

The SRC part isn't much more than a (hopefully) very good quality LPF, CPU wise.

@bitflipper: You raise an interesting question. I scratched my head a couple of times, then remembered that samplers rely on SRC (sort of - read on) as a fundamental operation of their playback engines. It's what allows them to play (for example) a D note based on a sample recording of a C note. The "SRC" is used to play back the recorded sample at a time rate different from the recorded rate (thus shifting the pitch) while preserving the rate at which the samples come out. It's all accomplished with the same type of interpolation process as used on SRC. There, you are playing back a sample at a different sample rate than recorded, while preserving the pitch in the output.  In the case of the sampler, changing the sample rate on the output side should simply amount to changing a scale factor in the interpolator. Any increase in computation should then be just the overhead that you get from processing the added samples at the higher rate, which you would get everywhere else in the DAW anyway.
 
@drew: I concur - though it would be closer in comparison to a good linear-phase lowpass

Good one, losguy. I get it now...SRC isn't a particularly CPU-intensive operation. The reason oversampled plugs gobble CPU cycles is because they're doing calculations on more data, not because of the oversampling itself. SRC overhead while playing back samples at a different project rate is therefore negligible.

My head hurts now!