SFZ drum samples loudness levels?

[D2sX9ek8w3]

Hi,
In 2007, I made a set of samples of my acoustic drum kit and assembled an SFZ kit that I used with Cakewalk's Session Drummer vST.
It was a basic exercise, but I used 20 to 30 samples per group. In this instance, the dB levels of my samples were scaled to relate to the ranges of velocity each sample was assigned to.

I thought it sounded pretty good, and more importantly, it sounded like my drum kit.

Anyways, now it's 2025, and I would like to make an SFZ kit for use with Plogue's Sforzando.

I have been looking at different sample sets to learn how others do things.

It seems many kits use the amp_velcurve_N opcode with samples that have been normalized to some extent.

I am writing here to ask for insights and suggestions regarding choosing between assembling collections of drum samples where the quiet hits are stored at low levels and loud hits are stored at high levels, or normalizing the hits and using the amp_velcurve_N opcode to output appropriate levels.

It seems to me that one benefit of normalizing would be when previewing individual samples. However, it looks like increasing the amplitude of the digital file just for preview convenience also brings up the noise floor, but I guess you turn it all back down in the playback engine. Another option would be to record the quieter hits louder, either with preamp gain or mic placement, one would bring up the acoustic and analog noise floor, and the other would change the character of the mic response.

Those are some of the ideas I am considering and getting confused about.

Can you please offer some insights, opinions, facts, etc.?

Thank you.

[PTV]

If you have many velocity layers you can try to use a low amp_veltrack, but not too low if you don't want to have "steps" between one velocity layer to another. Experience and find what's the optimal value.

[D2sX9ek8w3]

Hi, it seems like amp_veltrack is an alternative to amp_velcurve_N.

I am asking about the bigger picture:

Normalize the stored samples and code the volume/velocity response.

or

Store the samples with natural scaling and playback without any volume/velocity compensation.

I am starting to realize that natural scaling will work best with lots of samples, such as the 30 I used in the example cited in the OP. In contrast, the opcode scaling would be very useful if you only had fewer samples to stretch across the entire volume range.

Code: Select all

// Acoustic Snare: 

<group> key=38 loop_mode=one_shot

//30 levels

<region> lovel=000 hivel=007 sample=Snare\Snare_01.wav
<region> lovel=008 hivel=011 sample=Snare\Snare_02.wav
<region> lovel=012 hivel=015 sample=Snare\Snare_03.wav
<region> lovel=016 hivel=019 sample=Snare\Snare_04.wav
<region> lovel=020 hivel=023 sample=Snare\Snare_05.wav
<region> lovel=024 hivel=027 sample=Snare\Snare_06.wav
<region> lovel=028 hivel=031 sample=Snare\Snare_07.wav
<region> lovel=032 hivel=035 sample=Snare\Snare_08.wav
<region> lovel=036 hivel=039 sample=Snare\Snare_09.wav
<region> lovel=040 hivel=043 sample=Snare\Snare_10.wav
<region> lovel=044 hivel=047 sample=Snare\Snare_11.wav
<region> lovel=048 hivel=051 sample=Snare\Snare_12.wav
<region> lovel=052 hivel=055 sample=Snare\Snare_13.wav
<region> lovel=056 hivel=059 sample=Snare\Snare_14.wav
<region> lovel=060 hivel=063 sample=Snare\Snare_15.wav
<region> lovel=064 hivel=067 sample=Snare\Snare_16.wav
<region> lovel=068 hivel=071 sample=Snare\Snare_17.wav
<region> lovel=072 hivel=075 sample=Snare\Snare_18.wav
<region> lovel=076 hivel=079 sample=Snare\Snare_19.wav
<region> lovel=080 hivel=083 sample=Snare\Snare_21.wav
<region> lovel=084 hivel=087 sample=Snare\Snare_22.wav
<region> lovel=088 hivel=091 sample=Snare\Snare_23.wav
<region> lovel=092 hivel=095 sample=Snare\Snare_24.wav
<region> lovel=096 hivel=099 sample=Snare\Snare_25.wav
<region> lovel=100 hivel=103 sample=Snare\Snare_26.wav
<region> lovel=104 hivel=107 sample=Snare\Snare_27.wav
<region> lovel=108 hivel=111 sample=Snare\Snare_28.wav
<region> lovel=112 hivel=115 sample=Snare\Snare_29.wav
<region> lovel=116 hivel=127 sample=Snare\Snare_30.wav

Code: Select all

// Acoustic Snare: 

<group> key=36 loop_mode=one_shot

//4 levels

<region>          hivel=031 amp_velcurve_31=1 sample=Snare_01.wav
<region>lovel=032 hivel=063 amp_velcurve_63=1 sample=Snare_02.wav
<region>lovel=064 hivel=095 amp_velcurve_95=1 sample=Snare_03.wav
<region>lovel=096 hivel=127                   sample=Snare_04.wav

[pljones]

I wrote myself a script: https://github.com/pljones/ns_kit7-sfz2 ... elocity.sh
There's some other wonders in the same repo, like https://github.com/pljones/ns_kit7-sfz2 ... _ranges.sh
Eventually, the low level mapping looks like this (for some snare drum - there's a <group> header with the key=... opcode):

Code: Select all

<region> lovel=1 hivel=1 amp_velcurve_1=1 amp_veltrack=1.000 seq_position=1 seq_length=1 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_001.wav
<region> lovel=2 hivel=4 amp_velcurve_4=1 amp_veltrack=0.971 seq_position=1 seq_length=2 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_002.wav
<region> lovel=2 hivel=4 amp_velcurve_4=1 amp_veltrack=0.988 seq_position=2 seq_length=2 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_003.wav
...
<region> lovel=118 hivel=122 amp_velcurve_122=1 amp_veltrack=0.962 seq_position=1 seq_length=5 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_031.wav
<region> lovel=118 hivel=122 amp_velcurve_122=1 amp_veltrack=1.000 seq_position=2 seq_length=5 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_037.wav
<region> lovel=118 hivel=122 amp_velcurve_122=1 amp_veltrack=0.995 seq_position=3 seq_length=5 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_030.wav
<region> lovel=118 hivel=122 amp_velcurve_122=1 amp_veltrack=0.995 seq_position=4 seq_length=5 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_033.wav
<region> lovel=118 hivel=122 amp_velcurve_122=1 amp_veltrack=0.995 seq_position=5 seq_length=5 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_032.wav
<region> lovel=123 hivel=123 amp_velcurve_123=1 amp_veltrack=0.995 seq_position=1 seq_length=1 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_034.wav
<region> lovel=124 hivel=125 amp_velcurve_125=1 amp_veltrack=0.985 seq_position=1 seq_length=1 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_035.wav
<region> lovel=126 hivel=127 amp_velcurve_127=1 amp_veltrack=0.979 seq_position=1 seq_length=1 sample=../samples/snares/sn14rock/stx/snare_on/ord/sn14wrock_stxr_ord_036.wav

Basically what you're proposing is the same - just I tweak it using amp_veltrack so the top of the next layer down meets the bottom of the next layer up... hopefully...

[enroe]

...
It seems to me that one benefit of normalizing would be when previewing individual samples. However, it looks like increasing the amplitude of the digital file just for preview convenience also brings up the noise floor, but I guess you turn it all back down in the playback engine. Another option would be to record the quieter hits louder, either with preamp gain or mic placement, one would bring up the acoustic and analog noise floor, and the other would change the character of the mic response.

Those are some of the ideas I am considering and getting confused about.

Can you please offer some insights, opinions, facts, etc.?

Thank you.

In general, I think it's a good idea to normalize all samples.
This way, you have a consistent, good wav base as a
sample base.

But that also means that you have to pack the volume
dynamics into the SFZ definition of a multisample. And the
SFZ format offers many possibilities for this. I'll briefly list
them here:

1. You can classify the low-velo samples into your own
"regions" or even "groups". Then you can write

volume=x --- where x = Volume in dB

and with it you can set the volume directly.

2. You can write

amp_random=2

So here you can even add a touch of randomness to the
volume. This makes the multisample more lively, but also
more uneven.

3. You can directly control the dynamics with

amp_veltrack=0 ... 100

4. You can adjust the dynamic curve with

amp_velcurve_1 = 0
amp_velcurve_64 = 0.7
amp_velcurve_127 = 1

and accurately "draw" the velocity curve yourself.

5. You can also explicitly set the volume in the song using
any controller:

gain_ccN

e.g. gain_cc11=12

Here, MIDI controller No. 11 has a range of 12 dB.

So there are many ways to determine the dynamics down to the
last detail and thus create a drum set that is very sophisticated
and has all the dynamics.

[DSmolken]

Hi, it seems like amp_veltrack is an alternative to amp_velcurve_N.

I am asking about the bigger picture:

Normalize the stored samples and code the volume/velocity response.

or

Store the samples with natural scaling and playback without any volume/velocity compensation.

I am starting to realize that natural scaling will work best with lots of samples, such as the 30 I used in the example cited in the OP. In contrast, the opcode scaling would be very useful if you only had fewer samples to stretch across the entire volume range.

Code: Select all

// Acoustic Snare: 

<group> key=38 loop_mode=one_shot

//30 levels

<region> lovel=000 hivel=007 sample=Snare\Snare_01.wav
<region> lovel=008 hivel=011 sample=Snare\Snare_02.wav
<region> lovel=012 hivel=015 sample=Snare\Snare_03.wav
<region> lovel=016 hivel=019 sample=Snare\Snare_04.wav
<region> lovel=020 hivel=023 sample=Snare\Snare_05.wav
<region> lovel=024 hivel=027 sample=Snare\Snare_06.wav
<region> lovel=028 hivel=031 sample=Snare\Snare_07.wav
<region> lovel=032 hivel=035 sample=Snare\Snare_08.wav
<region> lovel=036 hivel=039 sample=Snare\Snare_09.wav
<region> lovel=040 hivel=043 sample=Snare\Snare_10.wav
<region> lovel=044 hivel=047 sample=Snare\Snare_11.wav
<region> lovel=048 hivel=051 sample=Snare\Snare_12.wav
<region> lovel=052 hivel=055 sample=Snare\Snare_13.wav
<region> lovel=056 hivel=059 sample=Snare\Snare_14.wav
<region> lovel=060 hivel=063 sample=Snare\Snare_15.wav
<region> lovel=064 hivel=067 sample=Snare\Snare_16.wav
<region> lovel=068 hivel=071 sample=Snare\Snare_17.wav
<region> lovel=072 hivel=075 sample=Snare\Snare_18.wav
<region> lovel=076 hivel=079 sample=Snare\Snare_19.wav
<region> lovel=080 hivel=083 sample=Snare\Snare_21.wav
<region> lovel=084 hivel=087 sample=Snare\Snare_22.wav
<region> lovel=088 hivel=091 sample=Snare\Snare_23.wav
<region> lovel=092 hivel=095 sample=Snare\Snare_24.wav
<region> lovel=096 hivel=099 sample=Snare\Snare_25.wav
<region> lovel=100 hivel=103 sample=Snare\Snare_26.wav
<region> lovel=104 hivel=107 sample=Snare\Snare_27.wav
<region> lovel=108 hivel=111 sample=Snare\Snare_28.wav
<region> lovel=112 hivel=115 sample=Snare\Snare_29.wav
<region> lovel=116 hivel=127 sample=Snare\Snare_30.wav

Code: Select all

// Acoustic Snare: 

<group> key=36 loop_mode=one_shot

//4 levels

<region>          hivel=031 amp_velcurve_31=1 sample=Snare_01.wav
<region>lovel=032 hivel=063 amp_velcurve_63=1 sample=Snare_02.wav
<region>lovel=064 hivel=095 amp_velcurve_95=1 sample=Snare_03.wav
<region>lovel=096 hivel=127                   sample=Snare_04.wav

Yup, this is exactly how I do it.

I never normalize drum samples, and leave amp_veltrack at the default of 100. However, when you set lovel/hivel for a velocity layer with that, for example lovel=30 hivel=35, then a velocity 35 sample will not play at its real volume, but it will be scaled down by the velocity tracking. lovel=30 hivel=35 amp_velcurve_35=1 gets around this.

With that many velocity layers, of course, the difference between amp_veltrack=100 and amp_veltrack=0 isn't big anyway, except for the lowest few layers. But I leave it at 100 mostly for things that end up with fewer layers, like cymbals (which take forever to record) or more niche (perhaps even Nietzsche) techniques.