(04-22-2018, 02:45 AM)peastman Wrote: [ -> ]I'll make those changes and send a new pull request to the sfz branch. What values would you like me to use for attack and release? These are just default values. Ultimately you'll want to customize them for each instrument, but right now I'm just trying to auto-generate files, and I don't know of any automated way to pick appropriate values for different instruments.
The main purpose of the volume correction is to make all the samples for each note consistent. Otherwise the volume jumps when it goes between layers and the round robins sound different from each other. I also do a little bit of normalization to smooth out differences between adjacent notes, but that's just a local correction. It doesn't change the balance between high and low registers. Unfortunately, the largest allowed value for "volume" is 6 dB, and some of the samples are already hitting that limit. If you want the recorder to be louder, I think you need to actually amplify the samples. Some of them are super quiet.
Quote: - Piano is 1 octave too high (note that most instruments are C3=60=middle C, only a few, if any, are C4=60)
Is there any way I can tell which convention is being used for each instrument? I could try to figure it out by analyzing the sound, but that won't be completely reliable. The routine for calculating frequency sometimes picks up on a prominent harmonic rather than the fundamental.
I might try crossfading if I'm feeling really ambitious! But I suspect that without phase locking, that's not going to work too well.
The 6 dB max is incorrect information, at least for ARIA-based systems. I've nearly blown out my speakers with a simple typo before (e.g. 120 dB instead of 12 dB!). I don't know what the actual max is, but it's waaay more than 6 dB. You can hear this in the SFZ's I made for VSCO 2 CE- they will go well above and beyond +6 dB.
Ideally, everything should be normalized. However, this has two major issues-
1. Any relationships in volume intended between instruments are lost, such as an oboe being recorded more quietly than a trombone.
2. Any super-quiet sounds get boosted, along with the noise floor, meaning people are more likely to experience issues when those sounds (e.g. a quiet rim click or col legno versus a snare drum hit or a bartok pizz, respectively) are played. This means at the end of the day, the creator of the sfz's should manually tweak a "general offset" for the sample set as a whole, without having to manually tweak EVERY sample. A simple additive variable in the code as I suggested would allow this, although manual tweaking is inevitable for at least some of the samples in mixed articulation patches (e.g. a drum kit patch).
Distinguishing between conventions is really easiest done by ear. Locate a C3/C4 sample and compare it to a known middle C (best is a known-good piano). You can also use a range chart (I keep a 'spectrotone chart', not for the actual spectro/tone part, but just because it has general ranges of all orchestral instruments written in MIDI key numbers with a nice piano keyboard annotated with key numbers, notation, pitches, and frequencies). It's something that can take time to really develop a good ear for with some instruments- I once mapped a timpani up a fifth from what it really was by accident!
You should assume that 90+% of the sample set (especially the "easy"/"well-annotated" stuff) is C3=60. It's what Kontakt and most other samplers uses. On the other hand, there are a few older things I cut myself that I did under C4=60 (which is technically the "more correct" one, but has a smaller following in the world of digital audio). These tend to be older samples, and for the most part, you won't even see those.
May I suggest the group defaults as the following for pianos-
Code:
ampeg_attack=0.004
ampeg_release=0.3
(for the 'sus'/'normal' group, put 'trigger=attack', for the 'rel', put 'trigger=release')
For sustaining instruments-
Code:
ampeg_attack=0.5
ameg_vel2attack=-0.495
ampeg_release=0.3
The ampeg_attack and ampeg_vel2attack will work together to create a soft fade at the start of the sample at low velocities, which diminishes as the attack is greater. You can tweak these values by decreasing ampeg_attack and ampeg_vel2attack together. The difference between the two is how much of an attack is left at velocity 127 (in this case 0.005, or 5 ms, which is just enough to clean up any unwanted clicks, although it could be even shorter).
If there are sus and rel, set them up like above. This can probably be automated if you can build instruments from within multiple folders ('default_path=' inside of <control> is your friend, especially since you can put multiple <control> headers in an instrument).
You can couple the ampeg_attack with a lowpass filter with a similar envelope if you want to go overboard, but this will at least get the job started and make controlling brass and strings much more lively and dynamic seeming.
Try this with the filter. To be honest, not sure where to put it or if it even works... should be sfz 1.0 compliant-
Code:
fil_type=lpf_1p //a gentle lowpass
cutoff=22100
fil_keytrack=15 //slight keytracking to stop high notes from being too dull at inception
fileg_depth=6000 //not sure about this one, cryptic, may not even be needed or may break everything!
fileg_start=19 //percentage of cutoff - edit this!
fileg_attack=0.5
fileg_vel2attack=-0.495
On the other hand, it might be handy to have the script instead (or additionally) set up a filter whenever it notices there is only one velocity, to enhance the effect of the lower velocities-
Code:
fil_type=lpf_1p //gentle lowpass
cutoff=6000
fil_keytrack=15
fil_veltrack=2250 //again not sure about this setting, but that might just work
fil_random=100 //a little 'jitter' to help :)
You could alternately have it hooked up to CC1 for sustaining instruments for the modwheel lovers by swapping out 'fil_veltrack' for 'cutoff_cc1'.
Crossfading a piano is much more forgiving, as each note consists of multiple strings which phase together in their own way. Most of the pianos in VCSL are fairly precisely cut, so there should be less phasing than typical, but I can't promise it would be 100% perfect. You can crossfade any section (2+ instruments) without needing to worry about phasing regardless, and many solo instruments will work *okay* (but not necessarily fantastic) without phaselocking.
The crossfading is rather straightforward; to be honest, I don't know why I haven't had it implemented in my automapper (probably a fear of messing it up).
For a two-layer instrument, all samples are mapped to the full velocity range (1-127, or 0-127).
Then, the upper layer receives 'xfin_lovel=1' and 'xfin_hivel=126', for example (although you could pick a higher/lower combo, such as 10 and 119, for example). The lower layer receives 'xfout_lovel=1' and 'xfout_hivel=126' (or again, the same combo as used before). The lovel and hivel should match between xfin and xfin out for best results, and can be anywhere on the keyboard, even 50 and 70, for a very brief crossfade in middle velocities (perhaps to soften the transition a little bit).
With three layers, the situation is very similar again, but the numbers are different, this time with the bottom velocity mapped 1-64, the middle 1-127, and the top 65-127. The bottom xfout_lovel might be 10 and hivel 59, the middle gets both xfin and xfout, with xfin_lovel at 10, xfin_hivel at 59, then xfout_lovel=70, xfout_hivel=117. Finally, the top gets xfin_lovel=70 and xfin_hivel=117. These are just examples, and will leave a 10-velocity range for each of the samples to be "alone" in.
By default, SFZ spec indicates the curve of the crossfade is 'power' (as in 'equal power curve'), which is better for mixing non-phaselocked material. You can change this to 'gain' (as in 'equal gain curve'; better for phase-locked material) with 'xf_velcurve=gain'. You will probably want to leave it as-is though, but it's worth trying both options.