# Upgrade Priorities



## Rohann (Mar 10, 2017)

Hi folks,

Currently running a 4790k with Win8.1, 250GB SS EVO SSD, 16GB RAM, 2x 2TB 7200RPM drives.

I know it's not kosher but throwing my Hollywood Strings library onto my OS SSD makes a big difference with dropouts in somewhat larger (70 instruments-ish) mockups, albeit at high buffer settings. SCS is still on the HDD.

Running a project with SCS, Bohemian Violin and a few others seems to create some CPU spikes/audio artifacts and I can't seem to get my buffer settings reasonably low (i.e. stuck at 256-512 for 7 articulations of SCS loaded along with a few Violin instances), but I'm starting to wonder if it's my audio interface (Scarlett 18i8 1st-gen).

I'm looking for RAM on sale as Kontakt/SCS is a bit of a memory hog, but I'm also wondering what to upgrade next. Would an interface with better latency provide better performance? Or should I first be looking to another SSD/RAM?


----------



## charlieclouser (Mar 11, 2017)

I think you'll see the biggest increase in system performance from adding more RAM and moving all your sample libraries to SSD than you will from changing your audio interface. Once you start getting to the bleeding edge of high performance then perhaps swapping out the Focusrite to an RME interface, which are known for excellent low-latency performance and bulletproof drivers, will let you zero in on that last reduction in buffer size, but I think the first things to address are going to 32gb (or more) RAM and DEFINITELY getting all your sample libraries on Samsung 850 SSD drives.


----------



## GP_Hawk (Mar 11, 2017)

I agree, add more ram and definitely go ssd. Would you need 4TB? You would be looking at $2200 or more for the evo. And the 2TB is roughly $1400. Wonder if there is a realtime performance hit going with the 4TB although I doupt it or at least very un noticeable.


----------



## samphony (Mar 11, 2017)

Like everyone above mentioned it upgrade ram and move the heavy scripted libraries single or raid or m.2 ssds (pcie) makes a huge difference!


----------



## GP_Hawk (Mar 11, 2017)

I checked this writeup on the evo 4TB and it's looking good!
http://www.tomshardware.com/reviews/samsung-850-evo-4tb-ssd-review,4623-3.html

I might move up as more real estate is needed to the 4TB....


----------



## synthpunk (Mar 11, 2017)

You could save some dough going with four 1TB ssd drives. I have two of the below now and reportedly they are made by crucial.

https://www.smithbuy.com/micron-1tb-2-5-sata-solid-state-drive-mtfddak1t0mbf-1an1zabyy.html?utm_source=hs_email&utm_medium=email&utm_content=41860667&_hsenc=p2ANqtz-9MFWXLOESUTi6QNLA0qESQnoRnPPdBgxIqy-dc3DviVU78m-Pg0G308ia0kHhOZ38BVvsno2-7PbhC_Vo3aM-JevxntA&_hsmi=41860667


----------



## Ashermusic (Mar 11, 2017)

Totally with Charlie. Definitely RAM first, then SSDs, then audio interface with better driver and converters.


----------



## AllanH (Mar 11, 2017)

FWIW, I've had good experience with the MX class Crucial SSDs. I have two 1 TB drives, and they've been flawless so far.


----------



## NathanTiemeyer (Mar 11, 2017)

Once you upgrade everything to SSD it'll be a night and day difference. Like the others said you can't go wrong with upgrading RAM or to all SSDs.


----------



## N.Caffrey (Mar 11, 2017)

NathanTiemeyer said:


> Once you upgrade everything to SSD it'll be a night and day difference. Like the others said you can't go wrong with upgrading RAM or to all SSDs.


How are you connecting the SSD to the computer?


----------



## Rohann (Mar 11, 2017)

Thanks all.

Makes a lot of sense, however: with Bohemian Violin loaded onto my system SSD and only about 7 SCS instruments streaming off my 7200RPM SSD, my total RAM is only at about 7-8GB including the DAW, and I still get pops and clicks along with 100% CPU spikes at a buffer of 64 and even 128 sometimes even with the Bohemian violin (on SSD). Is this not a driver/interface issue? PC is optimized as per VI company recommendations, and I realize streaming isn't ideal from a 7200RPM but with the amount of SCS loaded into RAM I wouldn't think the disk would be too strained.

I do realize I need 32GB RAM quickly for bigger Kontakt projects, but the pops/clicks/dropouts are throwing me off. This even happens with a single instrument sometimes at a 32 buffer, hence my suspicion that it's the Scarlett that's the cause of this particular problem.

Any thoughts? Happy to be wrong here, but am suspicious, especially with reports of poor latency with 1st gen Scarlett units.

4TB of SSD is out of the question right now, but build with 500GB or 1TB to start would work. Haven't had issues with most of my instruments, the only one I actually noticed a difference with is HWS (kind of mandatory), other than load times.



N.Caffrey said:


> How are you connecting the SSD to the computer?


SATA-3 I think. Not the fastest, I know, but load times are nonexistent even with the long-powerful HWS patches.


----------



## Rohann (Mar 13, 2017)

*chirp chirp* Anyone?

Forgot to add, re: 4TB. The HDD's are multipurpose, one being a backup for redundancy and the other for audio, video, etc. projects, more than fast enough for those so far. 4TB of SSD would be _massive_ overkill at this point.

synthpunk: That's _really_ cheap for a 1TB SSD. How do you like them so far?


----------



## synthpunk (Mar 14, 2017)

They been perfect, and are apparently made by Crucial. I will be getting two more this year to fill My Blackmagic with four and relegating my old 250/500g drives for backups, audio, and media. They also go on sale occasionally for $199usd.



Rohann said:


> *chirp chirp*
> synthpunk: That's _really_ cheap for a 1TB SSD. How do you like them so far?


----------



## Rohann (Mar 19, 2017)

charlieclouser said:


> I think you'll see the biggest increase in system performance from adding more RAM and moving all your sample libraries to SSD than you will from changing your audio interface. Once you start getting to the bleeding edge of high performance then perhaps swapping out the Focusrite to an RME interface, which are known for excellent low-latency performance and bulletproof drivers, will let you zero in on that last reduction in buffer size, but I think the first things to address are going to 32gb (or more) RAM and DEFINITELY getting all your sample libraries on Samsung 850 SSD drives.


Charlie, I've really appreciated your insight (as well as others') in other threads, and specifically your willingness to explain things clearly. If you don't mind humouring me if you find the time:
I'm having trouble understanding the issues I'm facing. In the aforementioned project, 7-8 instances of SCS plus Bohemian Violin (a pretty significant VI in terms of RAM and CPU use, but still) produces occasional spikes and dropouts at a buffer of 64, 128 and even 256 on occasion, with 100% CPU spikes showing up in the CPU monitor when legato notes are triggered. RAM seems to be floating around 7GB for the entirety of Studio One's usage, and the Bohemian Violin is already on an SSD. I didn't even have this much trouble with dropouts with Hollywood Strings streaming from my HDD in a bigger project.
I understand PLAY's streaming from disk a little better, but I'm somewhat new to Kontakt. I've had others say this seems more like an interface issue, as my CPU is anything but slow and it's not really a big project. I'll defer to the expertise on this board, certainly, but I want to be sure I'm understanding what's happening clearly. Would you still say it's the lack of SSD that's the cause of this with SCS? The Bohemian Violin seems to suffer from dropouts at low buffer settings at times too, even with no other instruments loaded, despite being on an SSD.


----------



## kurtvanzo (Mar 19, 2017)

Rohann said:


> Charlie, I've really appreciated your insight (as well as others') in other threads, and specifically your willingness to explain things clearly. If you don't mind humouring me if you find the time:
> I'm having trouble understanding the issues I'm facing. In the aforementioned project, 7-8 instances of SCS plus Bohemian Violin (a pretty significant VI in terms of RAM and CPU use, but still) produces occasional spikes and dropouts at a buffer of 64, 128 and even 256 on occasion, with 100% CPU spikes showing up in the CPU monitor when legato notes are triggered. RAM seems to be floating around 7GB for the entirety of Studio One's usage, and the Bohemian Violin is already on an SSD. I didn't even have this much trouble with dropouts with Hollywood Strings streaming from my HDD in a bigger project.
> I understand PLAY's streaming from disk a little better, but I'm somewhat new to Kontakt. I've had others say this seems more like an interface issue, as my CPU is anything but slow and it's not really a big project. I'll defer to the expertise on this board, certainly, but I want to be sure I'm understanding what's happening clearly. Would you still say it's the lack of SSD that's the cause of this with SCS? The Bohemian Violin seems to suffer from dropouts at low buffer settings at times too, even with no other instruments loaded, despite being on an SSD.



I agree with what others say about Ram and SSD, but based on your CPU you may want to run Bohemian on the 48k/16 version while writing, then swap it out for the 96k/24 when mixing (with a higher buffer- like 512 or 1024). And if your playback during mix is having issues, lay BV to an audio track then mix- BV takes a bit of CPU, and depending on your machine it may clog up the works regardless of RAM and SSD storage.


----------



## passsacaglia (Mar 20, 2017)

Have been using that Smithbuy Micron SSD, worked perfeclty after the formatting to MacOSJournal etc. Speeds around 460MB/s and above, orico ssd enclosure with uasp support. Works perfectly  No issues or struggles after 2 months of daily use.


----------



## Musicam (Mar 20, 2017)

Ashermusic said:


> Totally with Charlie. Definitely RAM first, then SSDs, then audio interface with better driver and converters.



What kind of RAM do you say me?


----------



## Ashermusic (Mar 20, 2017)

Musicam said:


> What kind of RAM do you say me?



The fastest your computer will allow.


----------



## heisenberg (Mar 20, 2017)

Ashermusic said:


> The fastest your computer will allow.



Is latency more important that speed?


----------



## Ashermusic (Mar 20, 2017)

heisenberg said:


> Is latency more important that speed?




I have never heard of "RAM latency"

But the more RAM you have, the more ease your computer will deal with its load.


----------



## Rohann (Mar 20, 2017)

kurtvanzo said:


> I agree with what others say about Ram and SSD, but based on your CPU you may want to run Bohemian on the 48k/16 version while writing, then swap it out for the 96k/24 when mixing (with a higher buffer- like 512 or 1024). And if your playback during mix is having issues, lay BV to an audio track then mix- BV takes a bit of CPU, and depending on your machine it may clog up the works regardless of RAM and SSD storage.


Yeah it's a bit confusing, as I am running the 48k/16bit version (CPU is an i7-4790K @ 4.0GHZ). The reason the Focusrite interface is making me suspicious is because the latency numbers on it are quite poor, and I've heard a number of times that people can't get down to a buffer of 32 regardless of the project due to pops and clicks. Their drivers are nothing like RME's, apparently. I assume I'll need another SSD and more RAM down the road anyway so I'm keeping an eye out, but in the meantime I want to make sure my cash goes directly to current workflow issues, hence my concern. Sounds more like an SSD thing than a CPU/interface thing to you too? I can't see how it would be a RAM thing when the PC's total usage is only around 9GB (not a lot of headroom, I know, but specific to this issue).



heisenberg said:


> Is latency more important that speed?


In the realm of DDR3/DDR4 RAM, the amount you have significantly outweighs the speed. If higher speed is cheap, go for that, but real world differences are relatively moot when it comes to, say 1600 vs 1866, for instance. Just make sure your RAM is all the same and you'll avoid a headache; it'll only go as fast as your slowest RAM anyways.


----------



## storyteller (Mar 20, 2017)

Rohann said:


> Hi folks,
> 
> Currently running a 4790k with Win8.1, 250GB SS EVO SSD, 16GB RAM, 2x 2TB 7200RPM drives.
> 
> ...


I know a lot of people are mentioning the parts to upgrade, but I just wanted to suggest to keep in mind that the best CPU will not be able to handle a full orchestration without offloading processing power somewhere. For example, Kontakt can only voice about 1000-1400 voices on 8 threads on an i7 4GHz before it chokes. Play may be a little less than that. Overall, the bottleneck is going to be simultaneous audio streams. Some synths can consume massive CPU cycles per track as well. If you have complex routing inside your template (e.g. numerous sends, etc), then that is going to reduce the throughput as well. So, what you may be experiencing could be voice count issues - which means you will need to bounce/freeze each track after playing it. There are inevitably a lot of variables that affect the performance, but if you have SSDs, and a large enough amount of RAM for your purpose, the only thing remaining is CPU bottlenecking (likely from voice counts).


----------



## Rohann (Mar 20, 2017)

storyteller said:


> I know a lot of people are mentioning the parts to upgrade, but I just wanted to suggest to keep in mind that the best CPU will not be able to handle a full orchestration without offloading processing power somewhere. For example, Kontakt can only voice about 1000-1400 voices on 8 threads on an i7 4GHz before it chokes. Play may be a little less than that. Overall, the bottleneck is going to be simultaneous audio streams. Some synths can consume massive CPU cycles per track as well. If you have complex routing inside your template (e.g. numerous sends, etc), then that is going to reduce the throughput as well. So, what you may be experiencing could be voice count issues - which means you will need to bounce/freeze each track after playing it. There are inevitably a lot of variables that affect the performance, but if you have SSDs, and a large enough amount of RAM for your purpose, the only thing remaining is CPU bottlenecking (likely from voice counts).



Thanks for the explanation. Totally agree -- with my other project of 80 instances of PLAY including a number of HWS patches, I don't expect to be able to record at a buffer of 64 (hence slave PC's). But in a project of 8 instruments? I don't really understand how that could be overloading the CPU, especially when I've experimented with both different and the same instances of Kontakt.

That said, I did experiment using Bohemian Violin and a number of instances of HWS (on my OS SSD) and I didn't _really_ get issues at 64 samples. For some reason BV will cause pops when I hit start or stop with a 100% CPU spike, but not really while playing or recording. Seems likely to be the lack of SSD on SCS.

Where does external hardware factor in? Is it more with the specific latency of the unit (i.e. a Scarlett at 64samples getting a 10.32ms total latency, whereas an RME would get 6ms, for instance)?


----------



## brett (Mar 21, 2017)

Couple of random thoughts...

Are the SCS patches all legato?
Do you have tempo changes in your project?


----------



## galactic orange (Mar 21, 2017)

synthpunk said:


> You could save some dough going with four 1TB ssd drives. I have two of the below now and reportedly they are made by crucial.
> 
> https://www.smithbuy.com/micron-1tb-2-5-sata-solid-state-drive-mtfddak1t0mbf-1an1zabyy.html?utm_source=hs_email&utm_medium=email&utm_content=41860667&_hsenc=p2ANqtz-9MFWXLOESUTi6QNLA0qESQnoRnPPdBgxIqy-dc3DviVU78m-Pg0G308ia0kHhOZ38BVvsno2-7PbhC_Vo3aM-JevxntA&_hsmi=41860667


Apparently they've got a processor sale going on at the moment if anyone is interested.

https://www.smithbuy.com/processors.html


----------



## storyteller (Mar 21, 2017)

Rohann said:


> Thanks for the explanation. Totally agree -- with my other project of 80 instances of PLAY including a number of HWS patches, I don't expect to be able to record at a buffer of 64 (hence slave PC's). But in a project of 8 instruments? I don't really understand how that could be overloading the CPU, especially when I've experimented with both different and the same instances of Kontakt.
> 
> That said, I did experiment using Bohemian Violin and a number of instances of HWS (on my OS SSD) and I didn't _really_ get issues at 64 samples. For some reason BV will cause pops when I hit start or stop with a 100% CPU spike, but not really while playing or recording. Seems likely to be the lack of SSD on SCS.
> 
> Where does external hardware factor in? Is it more with the specific latency of the unit (i.e. a Scarlett at 64samples getting a 10.32ms total latency, whereas an RME would get 6ms, for instance)?


Latency should be the same (or very close) regardless of external unit. RME and Apogee drivers are great so they will handle loads better, but the buffer setting is simply math. A buffer setting should equal the same delay on any unit. Any difference in delays between units should be negligible if their developers programmed their drivers correctly. But the difference in latency is usually because of project based settings. For example, a 24/48k session at 256 buffer is going to have a different latency than a 24/96k at 256 buffer. Hope that helps some. 

EDIT: Also, the amount of upsampling/downsampling will effect the processor depending on each sample library's bitrate and your project setting.


----------



## Rohann (Mar 21, 2017)

galactic orange said:


> Apparently they've got a processor sale going on at the moment if anyone is interested.
> 
> https://www.smithbuy.com/processors.html


I wonder if a Microcenter Proxy would be a better deal. I got my 4790k for $279 and bundled with a mobo that was only $50 after discount. Decent prices on some of the more extreme CPU's though.



brett said:


> Couple of random thoughts...
> 
> Are the SCS patches all legato?
> Do you have tempo changes in your project?


1. No, only the cello performance legato patch.
2. No, quite basic, was more using it as a "mess around with SCS" project.



storyteller said:


> Latency should be the same (or very close) regardless of external unit. RME and Apogee drivers are great so they will handle loads better, but the buffer setting is simply math. A buffer setting should equal the same delay on any unit. Any difference in delays between units should be negligible if their developers programmed their drivers correctly. But the difference in latency is usually because of project based settings. For example, a 24/48k session at 256 buffer is going to have a different latency than a 24/96k at 256 buffer. Hope that helps some.
> 
> EDIT: Also, the amount of upsampling/downsampling will effect the processor depending on each sample library's bitrate and your project setting.


Curious, as the latency reports floating around on Gearslutz or the like show massive variability depending on the unit. Even Focusrite's site reports lower latency with their Scarlett 2nd generation series than their first. Not a massive difference, but close to 3-4ms at times, especially if the first gen is compared to RME or the like.

So is the benefit to an external unity more stability at lower buffer settings then? If all units have roughly the same latency then I'm confused as to why someone would bother with an RME unit over something cheaper.

Re: upsampling/downsampling. Is there any sort of "sweet spot" for this? Some quick research says the standard for film music is 48/24b, with video game and the like varying (CD audio obviously being 44.1/16). I usually record at 44.1/24bit, but maybe I should be at 48/24? Spitfire's sample libraries seem to be at 48 but older EastWest libraries are (I think) at 44.1.


----------



## storyteller (Mar 21, 2017)

Rohann said:


> Curious, as the latency reports floating around on Gearslutz or the like show massive variability depending on the unit. Even Focusrite's site reports lower latency with their Scarlett 2nd generation series than their first. Not a massive difference, but close to 3-4ms at times, especially if the first gen is compared to RME or the like.
> 
> So is the benefit to an external unity more stability at lower buffer settings then? If all units have roughly the same latency then I'm confused as to why someone would bother with an RME unit over something cheaper.
> 
> Re: upsampling/downsampling. Is there any sort of "sweet spot" for this? Some quick research says the standard for film music is 48/24b, with video game and the like varying (CD audio obviously being 44.1/16). I usually record at 44.1/24bit, but maybe I should be at 48/24? Spitfire's sample libraries seem to be at 48 but older EastWest libraries are (I think) at 44.1.



I think you'll probably have various users who will have opinions on it and feel confident their way is "the best," but there is a little wiggle-room to play with on what works best for you. If you are using any effects (such as reverb, comp, delay, etc), 24 bit will provide a higher resolution of detail than 16bit. Mathematically, it could be argued that the sine waves reconstructed from 16bit and 24bit files will be identical - and that is probably true. But the problem is the granularity the ear can hear and how your effects process that "dithered" audio. To me, there is an extremely big difference between 16bit and 24bit. I'd rather not work on a session at all if I have to work in 16bit to be honest. It bothers my ears that much (but I am probably in a small minority who pay that much critical attention to sound). To most, 16bit sounds fine. But if we are being very particular about having the most polished product you can produce, you will need to use 24bit to have your best shot at it sounding as fully polished as possible.

As for 44.1k, 48k or 96k, that's a little less important to me compared to bit-depth. However, 96k consumes more CPU. I work 100% of the time in 24/48k. If you walk into any Nashville studio (I am no longer in Nashville, I once was though), you will walk out with 24/48k session files regardless if you were recording a country singer or a full orchestra. Some artists, composers, and record companies will request 24/96k, but most assume 24/48k is the standard. Most sample library developers probably are capturing in 96k for two reasons. 1) For longevity in the event it is needed as technology and specs change (since the recording session is the highest cost of the project). 2) Depending on gear quality, it is easier to get a cleaner sound on cheaper gear with 96k A/D converters. Maybe that isn't a consideration, but if someone doesn't have great Apogee (or similar) A/D converters for 48k conversion, the divide in quality is greater at 48k than 96k....because Math.

FWIW, the silver/gold versions of sample libraries from EastWest tend to use 16bit to help define why it is worth it to spend more money on the 24bit Diamond version. Even if you take all of the extra mic positions away, the bit depth is justifiably worth the cost difference to my ears. But again, to most, 16bit does a solid job. We aren't talking about something so vastly different that great results can't be had. It is somewhat like a fine pair of handmade Italian leather shoes compared to nearly every other leather shoe available. The cost difference seems absurd. Most people won't notice - and it doesn't matter if they do because it is not about them. It is about you. And once you own and wear a pair, you realize why they were worth the money and you'd be hard pressed to have anything less in the future. Anyway, that's my $0.02 on it.

Per your driver question - yes, drivers can (and do) introduce latency beyond the buffer. But it is a little more complex. Here's a great article from PreSonus describing the latency issue induced by drivers. https://www.presonus.com/community/Learn/The-Truth-About-Digital-Audio-Latency


----------



## Rohann (Mar 21, 2017)

storyteller said:


> I think you'll probably have various users who will have opinions on it and feel confident their way is "the best," but there is a little wiggle-room to play with on what works best for you. If you are using any effects (such as reverb, comp, delay, etc), 24 bit will provide a higher resolution of detail than 16bit. Mathematically, it could be argued that the sine waves reconstructed from 16bit and 24bit files will be identical - and that is probably true. But the problem is the granularity the ear can hear and how your effects process that "dithered" audio. To me, there is an extremely big difference between 16bit and 24bit. I'd rather not work on a session at all if I have to work in 16bit to be honest. It bothers my ears that much (but I am probably in a small minority who pay that much critical attention to sound). To most, 16bit sounds fine. But if we are being very particular about having the most polished product you can produce, you will need to use 24bit to have your best shot at it sounding as fully polished as possible.
> 
> As for 44.1k, 48k or 96k, that's a little less important to me compared to bit-depth. However, 96k consumes more CPU. I work 100% of the time in 24/48k. If you walk into any Nashville studio (I am no longer in Nashville, I once was though), you will walk out with 24/48k session files regardless if you were recording a country singer or a full orchestra. Some artists, composers, and record companies will request 24/96k, but most assume 24/48k is the standard. Most sample library developers probably are capturing in 96k for two reasons. 1) For longevity in the event it is needed as technology and specs change (since the recording session is the highest cost of the project). 2) Depending on gear quality, it is easier to get a cleaner sound on cheaper gear with 96k A/D converters. Maybe that isn't a consideration, but if someone doesn't have great Apogee (or similar) A/D converters for 48k conversion, the divide in quality is greater at 48k than 96k....because Math.
> 
> ...


Thanks for the info! Much appreciated. Clears it up a bit and adds to what I already know.

Doing projects in 24 bit never seemed to change my resource usage that much so I stuck with it, but I notice a big difference with 96k and never bothered. I suppose my concern regarding 48k vs 44.1k comes down more to conversion:


> Maybe that isn't a consideration, but if someone doesn't have great Apogee (or similar) A/D converters for 48k conversion, the divide in quality is greater at 48k than 96k....because Math.


So do you mean with a cheap interface (i.e. converters), you'd be better off at 96k quality wise than 48 if it was recorded in 48? It seems like quite a few EW libraries were recorded in 44.1 and a good deal of Spitfire libraries in 48k. Would a project in 44.1k with instruments in 48k be a better idea than a 48k project and 44.1k instruments? Obviously the instruments aren't chosen by such criteria but wondering which direction results in more quality loss, and if it's noticeable at all.

Interesting what you say about 16 bit. I think I can hear a difference when the source material is mixed well enough (could be completely wrong), but CD's still sound quite good to me played through the right system.

Edit: SCS says "48k recorded at 96k". Does that mean they just downsampled after recording?


----------



## charlieclouser (Mar 22, 2017)

(Note: I am not an authority on these matters, and the stuff below is "to the best of my knowledge", and is how and why I decide on bit depth / sample rate, etc. In general, I don't care all that much - if it sounds okay, then I'm okay. But if anyone is more knowledgable and can correct me, have at it!)

I might not be totally surprised if the FocusRite interface / drivers are not as efficient on CPU as more slickly-designed interfaces / drivers from RME - but it's not likely to all of a sudden give you back half of your CPU. Some improvement? Sure. But I'd get RAM, SSD, and CPU all up to speed first. Plus, you said you're having trouble getting down to 32 sample buffer sizes? That's asking a lot from any rig that's hosting dozens / hundreds of Kontakt instances - with MOTU AVB series interfaces connected via Thunderbolt to a Mac Pro cylinder 12-core, I normally run at 256 or maybe 128 if I'm feeling lucky. If you want to be at 32 with a big template then you better get an RME interface and the most insane computer on earth.

Now..... using 48k samples in a 44k session, or the other way around, I think you will strain to ever hear a difference. Choose your session sample rate based on what you're delivering for - since 48k is the standard for use in film+tv production, use 48k if you're delivering to dub stages - and pay no mind to whether some of your sample libraries were at 44k.

I also think you'll likely see very little difference in CPU performance by using 16 bit versions of sample libraries - you may see a little less strain on your disc, but if you use SSDs then you should have no worries in that department. Since 16-bit is only 2/3 the data of 24-bit, you'd think you'd get a corresponding easing of disc and CPU stress by using the 16-bit versions of things like Sonokinetic libraries - but it seems that the disc/CPU performance meters in Logic don't show a corresponding reduction when I try using those lighter versions of the libraries. Maybe a *little bit *less disc usage, but it's not 2/3, and CPU stress seemed basically the same. Maybe because that data is only 16 bits deep at the moment it's pulled from disc - once it moves downstream inside Logic / Kontakt it's blown up to whatever the bit depth of the mix engine is? Who knows.... who cares. Very few libraries are provided in both 16 and 24 bit versions anyway, so it's not like you can make a habit of using lighter versions except in a very few cases (like Sonokinetic).

Now, of course you'll basically double your CPU load when working at 96k. However, sample libraries that are recorded at 48k and are used in a 96k session will not sound better - they will sound identical. Perhaps some eq or other effects plugins like reverb tails might sound a little better at 96k, even when being fed samples that are at 48k, but the difference is so small that I'd never use 96k for that reason alone. Maybe some trailer composers who want big reverb booms to decay to total silence, when there's not going to be any dialog or car crashes happening, can see some real reason to go to 96, but then will their trailer music be playing back at 96k in the theater?

The main reason I hear of folks using 96k is if they're recording some samples that they want to transpose downwards and retain more high frequency info - like recording croaking frogs and meowing cats to transpose them down and turn them into monster sounds or something. This is why some sound design guys up at Skywalker still love their old Synclavier systems with 100k sampling - but a buddy who's a dual-Synclav owner swears that the unique sound of downward-transposed hi-rate samples in the Synclav is because of its analog voice-mixing circuitry and the unique anti-aliasing filters on both the sampling inputs and audio outputs, which are all discrete analog designs and not implemented in software as they are in DAWs, Kontakt, EXS24, etc. Each individual sample voice and hard disc track goes through its own individual D>A, individual anti-aliasing output filters, and they are then mixed inside the unit in the *analog* domain. Like a summing mixer for each note of a chord on the sampler. Big difference. If you need that sound, get a Synclavier - they're surprisingly affordable these days, and can be totally reliable - but you'll need some dedicated 20-amp circuits if you don't want the streetlights in your whole neighborhood to go dim when you play a two-handed chord!

http://www.synclav.com

I have done some recordings at 96k, but it was for rock albums where we were tracking to tape first, then dumping to ProTools for editing, then dumping back to tape for mixing, and only because we didn't want to hear *any* effect that ProTools might have had on the recordings - and in those cases we had a finite number of tracks to deal with, and a big and powerful PThd system that could swallow 48 tracks of 96k and not explode - and it was always 48 tracks, never more, never less. That's a very different situation from using virtual instruments when you always want to add just one more (or 20 more). If I was recording the LSO at Air Lyndhurst and money was no object (or if I was Hans and was recording that big pipe organ for Interstellar or something) then maybe I'd flip the switch to 96k, but for in-the-box production with sample libraries it's 48k for me.

There's still the question of whether your setup can even capture and then reveal the additional high frequency information captured by sampling at 96k. I've recorded a bunch of samples of scraping bows on strings and stuff like that at 96k, hoping to transpose them down and hear nice high end detail, and.... nothing. The original 96k samples sounded identical to sample-rate-converted-to-48k versions when transposed down 1, 2, or 3 octaves. Playing in Kontakt, EXS24, or as non-warped audio in Ableton - all identical. Your mileage may vary, but I was disappointed to not hear a huge difference. With one or two of the samples I recorded, I "might" have heard "something", but it sure as hell wasn't like someone took a blanket off the speakers or whatever. This was most likely because my mics and preamps were designed for ordinary music use, and by design bandwidth-limited to 20kHz and thus weren't capturing much of anything above 20k or so - so recording at 96k was, for the most part, nothing but a waste of disc space. (yeah, yeah, upper harmonics, "air", blah blah blah... not talking about that!)

I do know that those sound designer guys who want to transpose down to get monster growls generally use a small subset of audio gear which is specifically designed for high-bandwidth signal capture - like Earthworks mics or the Sanken CO-100k, along with preamps like the Earthworks ZDT that can pass signal well beyond 20k. If I'm bored someday I may pick up a pair of the Sankens and a pair of ZDT pre amps, but.... for now, for us civilians, 48k it is.

http://www.sanken-mic.com/en/product/product.cfm/3.1000400

http://www.earthworksaudio.com/products/preamps/

In a similar vein, 32-bit-float storage is not going to "sound better" per se - it may be useful if you're dealing with mix stems and other recorded elements that, for some reason related to delivery standards, need to be at shockingly low levels - like far lower than any sensible person would normally use. Let's say you're printing stems for use in an Imax/Atmos delivery, and some of those stems contain nothing but 12 discrete tracks of crickets chirping at -82db. Then, maaaayyyyyybeeee it will make sense to use 32-bit float, since you don't have to worry about what level those stems are being bounced at. But for general purpose music use, straight 24-bit is fine. The range of human hearing from the tiniest little noise you could possibly detect up to the threshold of actual pain, is around 120db - and 24-bit linear audio encoding can accurately represent a dynamic range of around 146 db. (Yes, I know we're talking apples and oranges / DBv vs. DBspl, but work with me here!) 32-bit audio represents a dynamic range of around 194db - so in practice you could have a signal at 70db below full-scale in 32-bit and still have a very accurate representation. (I know I'm simplifying, generalizing, and glossing over important distinctions, but, again... work with me here!) Unless you already *know* you need 32-bit float, and already know *why*, you can probably skip it. There's basically no such thing as a 32-bit A>D converter (yeah, okay, I know some research-oriented lab equipment can go beyond 24 bit, but I'm talking pro audio gear here...), so capturing a signal at 24 bits and storing it at 32-bit-float is pretty much wasting space - *unless*, as I described above, you're inside the box, and in a hi-bit-depth (64-bit) mix engine (like ProTools or Logic v10.3.1) and are *bouncing* elements at very low levels, then in that case 32-bit-float can preserve detail when levels *need* to be low. Like, you've recorded those crickets at a decent level in 24 bits, and are then bringing the fader waaaaay down so it "sounds" at the right level in your stems with your calibrated monitor system - then, sure, go ahead and bounce to 32-bit-float.

In general, with respect to bit depth, just do like we've been doing forever - record at a decent level in 24 bits and away you go. However, using 16-bit as your recording depth *can* be a little less safe than 24-bit - if you accidentally record a couple of dozen db below full scale, you'll run the risk of capturing signals at unacceptably low resolution, winding up with a 12-bit guitar track or whatever... so stick to 24 bit from end to end and you'll be fine, even if your recordings only peak at -18 or so.

On the feature films or network tv series that I get hired for, I've *never* seen the dub stage working at anything other than 48k / 24 bit. *Ever*.


----------



## brett (Mar 22, 2017)

Great post Charlie


----------



## storyteller (Mar 22, 2017)

Rohann said:


> Thanks for the info! Much appreciated. Clears it up a bit and adds to what I already know.
> 
> Doing projects in 24 bit never seemed to change my resource usage that much so I stuck with it, but I notice a big difference with 96k and never bothered. I suppose my concern regarding 48k vs 44.1k comes down more to conversion:
> 
> So do you mean with a cheap interface (i.e. converters), you'd be better off at 96k quality wise than 48 if it was recorded in 48? It seems like quite a few EW libraries were recorded in 44.1 and a good deal of Spitfire libraries in 48k. Would a project in 44.1k with instruments in 48k be a better idea than a 48k project and 44.1k instruments? Obviously the instruments aren't chosen by such criteria but wondering which direction results in more quality loss, and if it's noticeable at all.



Charlie covered it extremely well. My reference to quality on cheaper gear at 96k vs 48k with respect to A/D conversion was referencing the actual recording process where an analog signal is converted to 1's and 0's. But like Charlie said, you'll have a tougher time trying to tell the difference between 44.1k and 48k, though 48k will be "smoother" than 44.1k at 24bit. That's the best way to describe it. Mathematically 48 is a multiple of 24 which the ear can perceive as a smoother recreation of analog sound. Then you also have factors like you D/A conversion and then speaker quality, etc. You won't go wrong with a 24-bit 48k session, though.



Rohann said:


> T
> Interesting what you say about 16 bit. I think I can hear a difference when the source material is mixed well enough (could be completely wrong), but CD's still sound quite good to me played through the right system.



When trying to hear the difference between 16bit/24bit think of it as listening for depth/thickness/a z-axis for sound. 16bit will generally sound thinner or less full than a 24bit recording. You''ll need good gear to hear the difference. But the reason all of this becomes inevitably important is that if you are recording and mixing in 16bit, you will be missing nuances that will cause your session to translate differently among different speakers/converters/etc. Top engineers mix with all of the variables revealed to their ears so the mix can translate expectedly across systems. Once it is correct at this level, downsampling it to 16/44.1 for CDs and MP3s works out great because everything was mixed from the top of the pyramid down.



Rohann said:


> Edit: SCS says "48k recorded at 96k". Does that mean they just downsampled after recording?



Yep! You are correct. After recording they just downsampled it to 48k.


----------



## charlieclouser (Mar 22, 2017)

A little while ago I bought a sample library of "trailer doom hits" that was delivered as 96k files. At first I thought I'd be transposing them down and hearing amazing high frequency stuff in a way that I wouldn't if the files were 48k. So I loaded them into Kontakt / EXS and dropped the pitch by 2 octaves - nothing. So I did some precise A-B testing between the original 96k files and the 48k versions I created by sample-rate-converting them using iZotope.

There was *absolutely* no difference in sound, even when pitched down 1,2, or 3 or more octaves. Bummer.

So then I did some more sample-rate-converting tests on these samples using every crappy piece of software that could do the job - an old version of BarbaBatch, Sample Manager, Logic, AudioFinder, etc. Same result. In a straight 2:1 sample rate conversion it seemed that even the worst sample rate conversion routine does the same job as the fancy stuff - which isn't surprising at all; that's what I would have assumed. Maybe when you're doing less linear conversions, like going from 96 to 44, or 48 to 44, *then* the various competing algorithms might exhibit audible differences? But for a straight shot from 96 down to 48 they all sounded the same to me.

This led me to believe that the samples in that library were *not* created with truly high-bandwidth audio gear, rather they originated at some point as 48k files and then the sound designers stacked, pitched, and edited a bunch of samples and ran them through a bunch of plugins and bounced from there. Just because they did their work in a 96k session did not magically add more information. They probably built these sounds by just stacking samples from Damage and other libraries anyway! I often hear "epic movie" libraries that quite obviously are re-using very recognizable samples from other libraries like Heavyocity etc. I don't know how they get away with it!

I probably should get a pair of those Sanken 100kHz mics or at least the Earthworks QTC-50's before I record my next bowed-metal sampling adventure.... hmmm. That's a sound source that could really benefit from accurately capturing ultrasonic information and then revealing it when transposing the samples downward.

I agree that 16 vs 24 bit is a more important thing to watch out for - but I made dozens of albums on the original 16-bit ProTools systems, sometimes with the original Apogee converters, sometimes with Digidesign 424 interfaces (!), and back then we *knew* that we needed to record hot. Not pinning, but definitely up there within a few db of full scale, otherwise we'd wind up with recordings that were effectively 9 bits or whatever. So when 24-bit converters first came out (yes, I'm old!) it's not like I all of a sudden thought I could relax and not watch my levels - I still record *hot* at all times. Once that 24-bit file is inside the 64-bit mix engine, *then* we can bring that fader way down and we're not losing anything important in terms of bit depth. Okay, sure - printing a 24-bit mix that has a bunch of hot 24-bit signals that have been attenuated in the mix by dozens of db *will* result in those files having, effectively, a lowered bit depth in the context of that final mix, but now we're talking musical context, masking effects of other, louder signals, etc. So I don't worry about that - but I still print *hot* all the time. I never bought into the recent logic where people say your recordings should never peak above 18db below full scale - that's just silly to me. Get up there, at least get in the yellow, man! My logic is a carry-over from the days when 16 was all the bits you got, and just because 24 bits gives us the luxury of maybe not watching our levels quite so carefully, I still hit it hard. Heck, on the first tv series I ever worked on back in the eighties we were printing mixes to a VCR hooked up to a Sony PCM-F1 encoder, which basically turned a video deck into a 14-bit DAT machine - and it sounded pretty good back then. This was, of course, before the DAT machine was even invented. 

God dang it... I'm old.


----------



## Rohann (Mar 22, 2017)

Charlie and storyteller: I sincerely thank you for the explanations, I've learned a tremendous amount here!

Charlie: Thanks for sharing your personal experience and wisdom. 24 bit makes plenty of sense and there's been no hit to my system. 96k, on the other hand...the CPU hit is substantial, and your explanation clears that out of the way as a consideration.
Getting down the 32 samples is difficult even with a relatively small (i.e. 10 instruments) project, but messing around now and reading the info here I'm convinced it's an SSD thing. Again, I can run 10 instances of HWS plus a few other CPU-hungry instruments with little CPU hit, but SCS likes to give my CPU grief (not on an SSD). The need for a better interface makes more sense now for recording purposes, but less so for VI usage. Not sure why I got a recommendation on Gearslutz for a new interface over the rest (figured I'd post here for second opinions, also to avoid spending $1000 where I can instead spend $500 on an SSD and 16GB RAM).
I sincerely thank you again for your thorough and clear explanation, I'll be reading over this a few times to absorb everything. I appreciate the practical example re: recording samples too, that's excellent info. I'll certainly be doing a "bow everything metal" recording at some point and this is useful info.



storyteller said:


> Charlie covered it extremely well. My reference to quality on cheaper gear at 96k vs 48k with respect to A/D conversion was referencing the actual recording process where an analog signal is converted to 1's and 0's. But like Charlie said, you'll have a tougher time trying to tell the difference between 44.1k and 48k, though 48k will be "smoother" than 44.1k at 24bit. That's the best way to describe it. Mathematically 48 is a multiple of 24 which the ear can perceive as a smoother recreation of analog sound. Then you also have factors like you D/A conversion and then speaker quality, etc. You won't go wrong with a 24-bit 48k session, though.


Thanks for this! Glad to hear that. Conforming to the standard of the film/TV industry makes sense to begin with, far more so with the technical explanations in this thread.



> When trying to hear the difference between 16bit/24bit think of it as listening for depth/thickness/a z-axis for sound. 16bit will generally sound thinner or less full than a 24bit recording. You''ll need good gear to hear the difference. But the reason all of this becomes inevitably important is that if you are recording and mixing in 16bit, you will be missing nuances that will cause your session to translate differently among different speakers/converters/etc. Top engineers mix with all of the variables revealed to their ears so the mix can translate expectedly across systems. Once it is correct at this level, downsampling it to 16/44.1 for CDs and MP3s works out great because everything was mixed from the top of the pyramid down.


Thanks for the info, and great point. Really seems to be no downside to mixing and writing in 24 bit.


----------



## charlieclouser (Mar 22, 2017)

After poking around a little bit, it seems that some modern digital projection systems in use in theaters *can* play back either 48k or 96k files at 24 bits. Whether or not the film studios actually distribute at the higher sample rate is another matter - a decision that might be made on a per-project basis?

Interstellar? Sure, 96k it is. Mike And Dave Need Wedding Dates? mmmmm.... we'll mix and ship that one at 48k. 

Maybe not every single neighborhood theater can suck back the 96k files without choking? Maybe only the latest systems can deal? Any projectionists in the house can give us a definitive answer?

Anyway, for broadcast tv, cable, netflix, dvd, etc. it seems that everyone's still at 48k. I just checked with the dub stage (Deluxe in Toronto) and we'll be mixing SAW VIII at 48k end-to-end.

But the use of higher sampling rates when recording audio that might be transposed downwards for sound design purposes is definitely a real thing. I've heard some things played back from the Synclav that definitely tickled my ears. My buddy's rig came with a stack of hard drives that were still full of everything from Skywalker sound effects to Michael Jackson album backing vocal stacks, etc. - and the Skywalker folder was pretty amazing. Not that we could or would ever use these samples - they were things like nature fx, animal sounds, guns, space station doors, etc. - but the sonic quality was completely on another level, and it was easy to hear that transposing them down revealed audio that was not present in the samples we typically make on our RME/MOTU/Kontakt rigs.

So, yeah... the Sanken mic is $2,400 each. Ouch. I think (hope) my CraneSong Spider mic pre / mixer unit can pass high-bandwidth signal. It's capable of A>D at sampling rates up to 192k, so hopefully the analog side in front of the A>D is up to the task. I'd expect nothing less from CraneSong. 

When I get into my next round of bowed metal sampling (might be next week) I think I'll call around and see if I can rent a pair of the Sanken CO-100k mics. I'll report back with sound examples if I manage to get that together.


----------



## Rohann (Apr 19, 2017)

Update:

So, found an M.2 850 EVO 1TB open box here (Samsung warranty does transfer as per 2 different Samsung reps, so long as the drive isn't refurbished and is simply used or open-box) for cheaper than an MX300, so I went for it (I realize M.2 SATA isn't really any faster but it was $100 cheaper than a 2.5" EVO). Samples on the SSD now, and still getting CPU spikes with the Performance Legato (celli in this case) patch in SCS at 64 samples and only 9 SCS instances loaded (1 Bohemian Cello as well and 1 EW Play instance). I don't hear audio artifacts though. For the record, my interface's ASIO control panel lists 64 samples as having 10.311ms total latency (5.156 in/out). Switching to 256 samples means spikes are only around 30%, but that still seems a bit ridiculous (27.378ms total latency).

Is there anything I should be adjusting here with the SSD (i.e. lower the buffer in Kontakt)? I'll play around a bit more and see if I actually hear anything, just a bit late now. Thought it would decrease the CPU hit more noticeably.


----------

