If you are a composer or producer that uses a computer in their productions, odds are you have at least a sample library or two. From soaring orchestral strings, to exotic world instruments, pianos, drums or guitars, sample libraries cover a stunning range of instrumentation across many genres of music. Today I am going to give you a brief overview of how commercial sample libraries are made.
The first place we always start is with the concept. Before we record a note, book the studio or call a musician we have to get a concrete idea of what is we are going to make? What are the libraries unique features? As developers we ask why we are making the library and what unfulfilled needs it is going to fulfill. During this phase we figure out things like what instruments are we going to record, and which playing techniques and try to get an overall idea of how we want the user to interact with the library. We also try to get a basic idea of how we want the user to interact with the library though we won’t necessarily have designed the UI at this point.
Once we have decided on the basic parameters of the library we need to do a bit more pre production before having getting musicians in the studio. Pre-production tasks include things like refining the list of playing techniques and deciding on the number of notes, round robin and dynamic layers to get an approximate estimate of how much recording time (and money) will be needed. A crucial step in this process is factoring in the human element; error and fatigue. Years ago on one of my first projects I naively failed to account for brass players needing to recover and ended up having to do twice as many sessions of half the length I originally planned once I realized that well, brass players don’t have unlimited lung capacity. This then goes into a spreadsheet that helps us calculate with a bit more precision how long the session will take. During the recording sessions and in post I often use additional spreadsheets to keep track of progress of various tasks.
Now we’ve gotten to the fun bit. The actual recording session (or more likely sessions). If you are wondering how long it takes to record a library, there is no hard and fast answer. To give you some guidelines, I have recorded some smaller libraries in a single 3 or 4 hour session, others have taken several days or weeks or even a month.
One thing a lot of people find surprising is that many sampling sessions feature the use of printed scores. While it is perfectly possible to conduct many sampling sessions without scores, having scores helps keep things organized and improves communication and consistency. During the session the producer(s) job is to keep things moving along and listen critically to ensure that the performances are up to spec and congruent with the vision of the project. In addition to listening to the actual musical performances from the instrumentalist, the producer also has to be ever mindful of intermittent noises like breaths, chairs, wild bows, etc. While many of these things can be removed or at least subdued in post, we try to minimize them during the session to lessen our burden down the line.
Before we can chop our files into thousands of individual samples we have to do just a wee bit of clean up. This is more or less a two part-process; first we “de-noise” our audio by removing any mic and electrical noises from all of our files. Once we have our noise profiles for a file it can take several minutes to process an individual audio file depending on the length and bitrate. For some context a session can have anywhere from 16 – 24 mics even if these will later be mixed down to fewer stereo stems and each file can take 3 minutes or more to process. That is per mic, per session by the way. So if we recorded a single session with 16 mics, that could be 48 minutes of processing for denoise. If it were 5 days of sessions (not uncommon) we would then be looking at 240 minutes (4 hours) of processing time. Pretty intense!
The second part of clean-up is to remove all of the breaths, chair noises, extraneous bows, etc that are the result of working with humans. This is a completely manual process and can often be the most time consuming and labor intensive aspect of library production. Depending on the number of repairs needed (and number of mics) it can be a days or weeks long process.
Now that the audio is all nice and squeaky clean, audio is phase aligned and stems are created before being chopped into thousands of individual samples. My tool of choice these days for chopping samples is Reaper, due to its impressive, flexible and easy to use file naming and export features but this can be done in just about any DAW. Audio is then exported and given hyper-specific names to make integration into the sampler easier.
With the samples sliced and diced to perfection the next task at hand is to create the actual virtual instruments. Samples are loaded into and mapped into the sampler of choice, for most commercial libraries this will be Kontakt. Though there are many other formats including, Halion UVI Falcon, Engine, EXS24 and HISE.
Simply loading the samples into the sampler does not an instrument make, while the results might be playable there is a lot of tweaking that happens under the hood to get the instrument to its final state. Possible tweaks at this phase include things like adjusting sample start times, envelopes and modulators, looping, sample volume, tuning, release triggers, etc.
With all the samples cleaned, repaired, mixed, chopped, tuned and mapped into the sampler of choice scripts are added to bring additional functionality to the library. There are myriad ways scripts can improve the functionality of the library. On the most basic level scripts help developers integrate the GUI to make the library more fun and easy to use for the user. GUI design is usually done by a specialized GUI artist though some developers do this internally.
Scripting is not necessarily the last phase of sample development; scripting can be done almost completely before any samples are recorded though there is usually at least some tweaking that is necessary once all the samples are mapped to refine the library before it becomes a final product. Depending on the complexity of the library a script can be composed of up to 80,000 lines of code representing dozens of hours worth of work.
I hope you have had fun learning about the process of creating commercial sample libraries. Even if you don’t end up creating your own commercial libraries hopefully you have gained some appreciation for all the hard work and thought and inspiration that has gone into the creation of your favorite sample library.
About The Author
Olajide Paris is an American composer, producer, multi instrumentalist, sample library developer, and entrepreneur based in the Republic of Georgia since 2012. He has created music for over 100 films, games and corporate projects including orchestration work for the 2016 Capcom XBOX release, Dead Rising 4. As an engineer he has worked with such talents as Jessica Simpson, Christina Aguilera, Jewel, Ellis Hall and Kamasi Washington.
He is founder of The Remote Orchestra, which enabled him to work on trailer music albums for Brand X and Roba Music, and led him to found another company, Private Labs Audio, Georgia’s first sample library company. He has also recorded and produced world class sound libraries for 8DIO, Audio Imperia, and Impact Soundworks and now creates libraries exclusively for his own brand Audio Wonder and manages Silk Factory Studio.