An efficient sample recording workflow?

Link to good samples/soundfonts at http://wiki.linuxaudio.org/wiki/free_audio_data

Moderators: MattKingUSA, khz

Post Reply
starfry
Established Member
Posts: 26
Joined: Wed Dec 09, 2020 9:19 am
Has thanked: 5 times

An efficient sample recording workflow?

Post by starfry »

I have a spare-time project to sample an old analogue keyboard. I'll probably use this an an exercise to learn how to code SFZ but the format choice isn't really relevant to this question which is about collecting actual samples. I'll likely start with SF2 and then make SFZ afterwards.

This is just for the experience of doing it, learning something and a little nostalgia - I'd like to sample my own keyboard that I've had since new over 40 years ago rather than search the internet.

The keyboard is very basic - it has 14 presets each with two variations and no velocity so 42 in all. The range is 4 octaves - 49 keys C to C. I think the nature of the instrument should simplify the sampling task because the variations / nuances are quite limited.

As a trial, I used Audacity and Polyphone to make a SF2 of one preset that has decay (that it loosely describes as "piano"). While not being great, it does work fine. I only sampled four F notes, being the centres of the keyboard's 4 octaves. You can hear the difference as you, say, move from B to C it's clear they come from different samples.

I made one recording in Audacity containing the four notes with gaps between, recorded via a Line-In (no mic) and manually divided it into the notes using Audacity before saving each cut as a WAV. I then used Polyphone to make a SF2 from those four WAVs.

So I plan to sample all 49 notes separately. I'm going to start with the same "piano" preset that has decay. Once I get that down, I'll try the continuous "organ" type tokens that'll require loops.

I also recorded "silence" so I could try removing low-level noise from the samples but I haven't tried to do that yet. Whether I should try cleaning the power supply to the keyboard, I don't know.

I'm looking for suggestions to make the sampling process as efficient as possible. A single recording containing the 49 notes seems to me to be the quickest way but the manually intensive edit phase is slow (although no slower than cutting the good part out of separate recordings). Is there a tool that can automate this or is it really a manual job? Is Audacity the right tool or is something else more appropriate?

There's lots of info on this great forum about making sf2/sfz from samples already taken but very little on the practical aspects of sampling itself. This thread was most relevant but I didn't want to necro-bump an old thread.
tavasti
Established Member
Posts: 2057
Joined: Tue Feb 16, 2016 6:56 am
Location: Kangasala, Finland
Has thanked: 373 times
Been thanked: 209 times
Contact:

Re: An efficient sample recording workflow?

Post by tavasti »

Linux veteran & Novice musician

Latest track: https://www.youtube.com/watch?v=ycVrgGtrBmM

User avatar
d.healey
Established Member
Posts: 611
Joined: Fri Sep 22, 2017 8:33 pm
Has thanked: 278 times
Been thanked: 101 times

Re: An efficient sample recording workflow?

Post by d.healey »

starfry wrote: Thu Mar 17, 2022 10:41 am I have a spare-time project to sample an old analogue keyboard.
I'm guessing not, but does it have MIDI in?
David Healey
YouTube - Free HISE scripting and sample library dev tutorials
Libre Wave - Freedom respecting instruments and effects.
starfry
Established Member
Posts: 26
Joined: Wed Dec 09, 2020 9:19 am
Has thanked: 5 times

Re: An efficient sample recording workflow?

Post by starfry »

d.healey wrote: Thu Mar 17, 2022 1:17 pm
I'm guessing not, but does it have MIDI in?
No nothing like that, completely analog. I looked into something called autosampler but that won't help me here because it sends midi to play the notes it records.
User avatar
magicalex
Established Member
Posts: 193
Joined: Sun Jan 24, 2016 6:34 pm
Has thanked: 130 times
Been thanked: 7 times
Contact:

Re: An efficient sample recording workflow?

Post by magicalex »

You can use the command line tool sox to split a file by silence. There's a tutorial here http://madskjeldgaard.dk/posts/sox-tuto ... y-silence/
User avatar
d.healey
Established Member
Posts: 611
Joined: Fri Sep 22, 2017 8:33 pm
Has thanked: 278 times
Been thanked: 101 times

Re: An efficient sample recording workflow?

Post by d.healey »

In that case recording manually is your only choice. Audacity is fine for this, so is Ardour. If it was me I'd use an external recorder like a Tascam dr-40 or one of the Zoom recorders.

For editing I use Ardour. Ardour and Reaper are the only tools I've found suitable for editing large batches (1000s) of samples efficiently. For a smaller sample set SoX, Audacity, or DGEdit might be suitable.

I made a video about my editing process:

https://youtu.be/iuUgnBQLJE4
David Healey
YouTube - Free HISE scripting and sample library dev tutorials
Libre Wave - Freedom respecting instruments and effects.
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 358 times

Re: An efficient sample recording workflow?

Post by j_e_f_f_g »

Here's some advice about recording. I'm going to be talking about some technical issues, but I'm deliberately going to phrase it in a way that should make sense to a layman (ie, non-technical musician). One aspect of my job it to translate technobabble into regular english. Think of me as a translator between a software engineer and the head of marketing. If there's some part of my advice you don't understand, let me know and I'll rephrase it in a different way. Sometimes, your first swing yields a foul ball. But the second can be a home run.

Here we go:

If you're recording a line level signal such as a keyboard's (analog) audio out jack or a mixer output, set your audio interface to line input (instead of microphone input). This will bypass your audio interface's mic preamp, which isn't needed for line level signals. (Line level signals are much louder than mic signals. The former don't need a large "volume boost" from your interface, and that will do nothing except add extra noise -- ie, hiss -- to the line signal). If your audio interface's main input jacks don't have a toggle switch for line versus mic level, then see if there are some line level jacks somewhere else on the interface).

Always record the hottest signal you can without clipping. If you're recording a quiet hit on a snare drum, for example, then turn up the input (record) volume on your interface so the wavefrom that is recorded is as loud as your heaviest snare hits. When you later make the final set of samples (perhaps as an SFZ instrument), you can adjust the "soft" hits volume back down, and it will help minimize the amount of background hiss (noise) on those soft notes. (The soft notes are where you can most often notice the noise on poorly recorded waveforms).

During your session where you're recording your softest waves, take a moment to record about 5 seconds of silence. Leave your keyboard (or mic, or whatever it is you're recording) plugged into the input while recording the silence. What you're really recording is any background noise (hums, hisses, crackles, etc) that are always happening while recording. Save this 5 second silence wave to your hard drive, and don't lose it. You can later use this silence wave file with "noise removing" software to get rid of even more potential noise in your "soft" waves. DO NOT normalize this wave.

Normalize your newly recorded waveform right after you record it. Normalize means to adjust the volume louder until the top and bottom peaks of the wave (when you're looking at it displayed on your computer screen) stretch all the way from the very top of your screen to the very bottom. In other words, get the wave as loud as it can be without clipping. You do this once only -- right before you save your wave to your hard drive for the very first time. Nearly all wave editors will have a menu command labeled "Normalize" which will do this automatically for you.

Set your daw to record in 24-bit resolution. (Usually this is rounded up to 32-bit resolution). Do not record 16-bit. You need the extra resolution so that you can best capture the dynamic range. 24-bit makes it easier to capture the loudest parts without clipping, and the softest parts without being buried in background "hiss".

Whereas you always record in 24-bit, after you've done the normalize, you can then save the file as a 16-bit wave. 16-bit is plenty of dynamic range when you're saving a waveform that has been normalized. This is optional. You can save in 24-bit wave files if you desire. But you won't hear any difference between fully normalized 16-bit and 24-bit waves. And 16-bit waves are much smaller when saved. Do not waste space saving 32-bit or floating point waves. That's unneeded overkill.

So too, record at 44.1KHz or 48KHz sample rate. Use 48KHz only for instruments with a lot of very high frequency content such as cymbals, snare drum, hihat, piccolo, certain percussion. Most instruments have very little content at ranges approaching 22KHz. For example, it's a complete waste of time recording a vocalist at 48Khz because you likely won't be able to hear anything from a vocalist's sound above 15khz. 88KHz and 96KHz are overkill for music use. I know the industry has brain-washed folks into thinking otherwise. But go get your hearing checked, and there's a good chance your ears aren't good enough to even hear up to 22Khz (the effective audible range of 44.1KHz sample rate). And 192Khz is ridiculous. That's pure marketing BS. The only people who need that are folks who record whale songs.

Whatever resolution, and sample rate you choose, make sure you have a 5 second "silence file" using the same.

There's a lot more to know about making your own sample sets, especially in regards to looping. But I'll save that for another time. I should do a video on looping. I'll show my technique for creating a crossfade loop that is seamless, even on difficult, single-pitch waveforms, usimg only manual editing (no crossfade algorithms applied). With this technique, you can create loops you can't even detect, like I did on just about all the samples in No Budget Orchestra and No Budget Band sound sets. But I first need to get done a whole bunch of things on a huge To Do list. So, I should have that video around 2050.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

User avatar
d.healey
Established Member
Posts: 611
Joined: Fri Sep 22, 2017 8:33 pm
Has thanked: 278 times
Been thanked: 101 times

Re: An efficient sample recording workflow?

Post by d.healey »

A few comments in addition to @j_e_f_f_g's excellent advice. A lot of what I'm going to say here won't apply to your particular instrument.
Normalize your newly recorded waveform right after you record it.
I would say this depends somewhat on your recording strategy and the instrument you're recording. I usually record an instrument in passes. For example I'll record every note from low to high at pianissimo, then I'll do the same at mezzo forte, and then again at fortissimo.

Sometimes this will be one continuous wav file, other times it will be three separate files, but either way there is usually a change in loudness between the start of the wav and the end of the wav. If I were to normalize the file at this point it would bring all the volumes up evenly but this isn't necessarily what you want when constructing a sample library.

If I'm building a woodwind library then I'll be using dynamic crossfades between layers to control the dynamic level. This is independent of volume. I will also probably be including some legato transitions. For these things to work smoothly it's important that the volume levels of each note are roughly the same. To achieve this I normalize each sample individually on export, so even the softest samples will be at the same volume as the loudest samples.

I also don't normalize to 0dB, I usually use -3dB, this gives me some room if I need to boost the volume of some of the samples to match other samples once I'm in the sampler. This can occur because usually the attack of a sample is the loudest part, but on some samples it isn't, so even if you normalize two samples to the same level they don't always have the same perceived volume and need to be further adjusted. Sometimes adding effects can also boost the volume so I like having the extra range available.

Once I have the crossfades and legato working smoothly I can re-add the volume curve to match the real instrument. This is done with another continuous controller modulating the gain. If it's a plucked or percussion instrument then I'll use velocity for these things rather than continuous controllers.
And 192Khz is ridiculous.
I always record at 24/48. This is good for almost anything and gives you room to play with effects that might require more range. Also switching to different settings for different recordings get tedious, I'm a set it once kind of guy. I also generally export my final samples at the same settings. I used to export at 16bit but harddrive space is cheap and 24bit can be useful if you are planning to add effects or for instruments with long tails that fade to silence, like harps and certain percussion.

There is one occasion I can think of where 192Khz is very useful. That is if you are doing some extreme pitch stretching. Stretching a sample is basically speeding it up or slowing it down and recording at a higher rate will give better quality results if you're doing something like a 2 octave or more stretch.
David Healey
YouTube - Free HISE scripting and sample library dev tutorials
Libre Wave - Freedom respecting instruments and effects.
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 358 times

Re: An efficient sample recording workflow?

Post by j_e_f_f_g »

I don't normalize to 0dB, I usually use -3dB
That's fine. You're using enough of the 16-bit dynamic range to mask the noise floor.

Crap. Let me translate that technobabble.

When you normalize to 0dB, that makes the waveform as loud as it can possibly go without clipping. The very highest point in the displayed wave will reach the top of your screen, and stop there. The very lowest point will reach the bottom of your screen. (Or at least one of those points will.) When you normalize to -3dB, it's almost, but not quite, as loud as the maximum. You'll see that either the highest point, or the lowest point, or both, don't quite reach the edges of your screen. But the waveform will be loud enough that any background hiss in it will effectively be "drown out" by the musical content, even if your wave has a fadeout to silence.

Ok?
even if you normalize two samples to the same level they don't always have the same perceived volume and need to be further adjusted.
Right. I didn't want to overwhelm folks with too many minor details. So I left out the following part:

After I normalize my wave, before I save it to the hard drive for the very first time, I listen to it in comparison to all the other waves I've recorded/normalized to that point. I load them all up in my wave editor, and listen to each one compared to the others. I'm looking for 2 things. First, is there a very noticeable change in the timbre? Is the new wave a lot brighter, or vice versa? Does it have some "ringing" or other "coloring" of the sound which the other waves don't have. If so, it's gonna sound "out of place" when I go to make the final set. Secondly, is the "perceived volume" noticeably different.

For volume irregularities, usually I'll go through the wave using Waveosaur's volume contouring tool to manually adjust any part of the wave where the volume "sounds a bit off". For timbre, I may try filtering (eq) if it just needs minor tweaking.

I do this kind of "timbre/volume" correction during the recording process, because sometimes it's easier to correct a problem just by recording another take. (Especially when it's the tone, not volume, which is off.) On the other hand, if you don't do this correction during your recording session, and later on you just can't process a wave to acceptably blend in with the others, it's a PITA to replace it.

So by the time I'm ready to save for the first time, a wave has already gotten at least an acceptable level/tone, and therefore I likely don't need to do much of that adjustment during the later editing.

And while I'm adding some more details, I do want to talk about the recording process. Do not do it all in one session. Sure, record all the waves in the first session. But leave everything setup overnight so the next morning you can get up and listen to those waves with a "fresh ear". You may find that something you thought sounded good the day before, now sounds horrible to you. (This is due to something called "brain masking", but I'm not gonna get into that here). You'll want to be able to record a second take of anything that sounds "off". If you're sampling some other person, ask if he'll be willing to do a second short session if needed. Explain that the second one will be short and easier because you're correcting only the bad parts.
I record at 24/48.
That's a good recommendation.
switching to different settings for different recordings get tedious
That's a recipe for disaster. I concur 100% with keeping the same format of all waves recorded for a particular sample set.
192Khz is very useful for extreme pitch stretching.
Absolutely true.

But I don't like to stretch a pitch more than plus or minus 4 semitones. Beyond that I can really start to notice the change in tonality, and I find it off-putting.

My advice reflects the perspective of someone who doesn't care for significant pitch stretching.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

starfry
Established Member
Posts: 26
Joined: Wed Dec 09, 2020 9:19 am
Has thanked: 5 times

Re: An efficient sample recording workflow?

Post by starfry »

I've been absorbing all the information posted here, thank you.

I've made a couple of sample sets using sox - I recorded all 49 notes of the keyboard into one file using Audaity and then used sox to break the samples out into separate files:

Code: Select all

sox piano.wav piano.wav silence 1 0.1 1% 1 0.5 1% fade 0.01 : newfile : restart
I found that the cut at the start comes after the end of the percieved silence which is after the first detected non-silence. So a little of the waveform is lost and this resulted in a pop in the audio. So I added a fade to smooth that out which works ok for a first attempt. I could not find a way to tell sox to include some samples before the detected cut point. Not sure if that's possible?

I've also installed ocenaudio and will take a look at that, not sure how to use it to split samples though (but I only installed it this morning!). I'm going to try a continuous tone next which will require looping. Not sure how to approach that yet.

Having been messing around for a while, I find myself with more questions. I initially sampled using my laptop which is actually a combined headset mic port rather than a proper line-in. I found the initial attempt less than satisfying so I remade samples using my desktop which has a proper line-in. I am wondering whether it would be worth using a plug-in interface like I think someone mentioned, although I wouldn't want to spend out large amounts so not sure what's possible or worthwhile. The line-in on my desktop is ok, probably good enough given the source. I have a PCI m-audio 2496 card I could de-mothball if that would be better.

I'm also curious how Audacity works re sample rates. I've sampled at 44.1K and 48K. I've saved to WAV at 16 and 24 bit. From what I've read in the other posts 44.1K should be enough and I can drop to 16K once I've finished alteriung the samples. I haven't normalised yet - not sure whether I should - the original tones decrease in amplitude as they increase in pitch - not sure whether to leave as-is or normalise them?

I'm also unclear how Audacity works - does it sample at a higher rate than what you state, only down-sampling when you export? I don't understand why the "project" file would otherwise be so much bigger than the exported wav. If it's sampled internally higher that would explain how it can resample from 44K to 48K. I thought that I'd need to re-record if changing the sampling rate but it seems not. Am I missing something?

Next I tried grouping two sample sets to be selectable using Midi program but I found that sfizz (as used by Carla) only recently added support for hiprog/loprog so I'll need to upgrade my machine before I can test that again. Right now it's playing samples from both groups at the same time. I used Polyphone to make a sf2 from the sfz and that worked fine in Carla (with a couple of tweaks to the presets).

I've kept my sfz simple - it only has group and region tags - 2 groups with 49 regions in each. One group has loprog and hiprog set to 0, in the other it's set to 1.

I've also tried Konfyt which I like, but I have problems where it won't play my files reliably (it does play other sfz however). Either I'm missing something from my sfz or perhaps my upgrade may help fix things.
starfry
Established Member
Posts: 26
Joined: Wed Dec 09, 2020 9:19 am
Has thanked: 5 times

Re: An efficient sample recording workflow?

Post by starfry »

I thought I'd post another update.

So I worked out how to do loops using Ocenaudio. It's a great program, shame there appears to be no documentaiton. But I got there :D

Still using sox to break recording into individual samples and then the painstaking job of setting loop points in Ocenaudio. I don't know if there is a way to automate that - it's quite fiddly and will be time-consuming to do it over all samples. I've only done one loop sample as a test and have tried it in a sfz (I didn't specify loop points, instead relying on the markers in the file).

Mixed results there... the player in my Carla doesn't recognise the loop points. But I also tried with the sfizz plugin which worked fine.I tried with Konfyt also but that emits a click like it isn't using the right sample endpoints. I do need to do some upgrade work so maybe now is the time and may solve these issues.

I also got to thinking that it would be good to know the sampling limitations of the hardware - the applications allow selecting rates higher than the hardware supports and still work without informing. I used "arecord" with a high sample rate so it would error and show me its accepted max. I wonder how people identify the hardware limitations they're working with.
User avatar
d.healey
Established Member
Posts: 611
Joined: Fri Sep 22, 2017 8:33 pm
Has thanked: 278 times
Been thanked: 101 times

Re: An efficient sample recording workflow?

Post by d.healey »

starfry wrote: Fri Mar 25, 2022 7:46 pm Still using sox to break recording into individual samples and then the painstaking job of setting loop points in Ocenaudio. I don't know if there is a way to automate that - it's quite fiddly and will be time-consuming to do it over all samples.
LoopAuditioneer

https://youtu.be/90SmO_dMIJs
David Healey
YouTube - Free HISE scripting and sample library dev tutorials
Libre Wave - Freedom respecting instruments and effects.
User avatar
Loki Harfagr
Established Member
Posts: 268
Joined: Thu Aug 02, 2018 1:28 pm
Has thanked: 151 times
Been thanked: 53 times

Re: An efficient sample recording workflow?

Post by Loki Harfagr »

As for SoX, you might have to search for more preciselisy adapted settings for the cut, just as an example (which settings I've actually used in the very ancient past on a quite similar aim):

Code: Select all

sox piano.wav piano.wav silence 1 0.25t 0.065% 1 0.25t 0.065% : newfile : restart
The minimal settings will certainly depend on how deep the noise floor is in the recording so you'll have some quick & dirty dichotomic tries at first ;)
Note that I didn't use fade which you may or not have to use and I used the same settings for fore and aft but since it's for piano sounds you may use more permissive values for the tails.
Post Reply