KVR Audio

learjeff · Post by **learjeff** » Sun Mar 05, 2006 8:06 pm

Well, I think we're pretty much done with the 24 bit thing for now. Fankly, it might be better for us to start a new thread and post what we've learned (that would be my job) for anyone who's interested but not following this thread.

SampleSmith · Post by **SampleSmith** » Sun Mar 05, 2006 8:30 pm

Agreed. Let's see where it goes. Thanks Jeff & Leonard!
k

pljones · Post by **pljones** » Sun Mar 05, 2006 8:58 pm

I believe SFZ already supports the 24 bit soundfont standard, btw.

learjeff · Post by **learjeff** » Mon Mar 06, 2006 7:49 pm

Glad to hear it. (Though, I hate to call something a "standard" when it's not documented! :p )

Thanks to folks from Chicken Systems, which makes Chicken Translator, pointing out a typo in the chunk name in my post above. I called it 'sd24' but it's 'sm24'. I've edited my post accordingly.

SampleSmith · Post by **SampleSmith** » Mon Mar 06, 2006 8:13 pm

Jeff, what are you guys using to look at this stuff?
(I gotta start somwhere!)
k

learjeff · Post by **learjeff** » Mon Mar 06, 2006 8:52 pm

I used a python script I wrote to help assemble larger layered soundfonts. Here's how yours looks:

Code: Select all

[d] 0x00000000:  RIFF len: 0x000f06dc type: sfbk loc: 0x0000000c
[d] 0x0000000c:   LIST len: 0x000000ca type: INFO loc: 0x00000018
[d] 0x00000018:    ifil len: 0x00000004 loc: 0x00000020
[d] 0x00000024:    INAM len: 0x0000000a loc: 0x0000002c
[d] 0x00000036:    isng len: 0x00000006 loc: 0x0000003e
[d] 0x00000044:    IPRD len: 0x00000008 loc: 0x0000004c
[d] 0x00000054:    IENG len: 0x0000000e loc: 0x0000005c
[d] 0x0000006a:    ISFT len: 0x0000000e loc: 0x00000072
[d] 0x00000080:    ICRD len: 0x0000000e loc: 0x00000088
[d] 0x00000096:    ICMT len: 0x00000016 loc: 0x0000009e
[d] 0x000000b4:    ICOP len: 0x00000022 loc: 0x000000bc
[d] 0x000000de:   LIST len: 0x000f03a4 type: sdta loc: 0x000000ea
[d] 0x000000ea:    smpl len: 0x000a0260 loc: 0x000000f2
[d] 0x000a0352:    sm24 len: 0x00050130 loc: 0x000a035a
[d] 0x000f048a:   LIST len: 0x00000252 type: pdta loc: 0x000f0496
[d] 0x000f0496:    phdr len: 0x00000072 loc: 0x000f049e
[d] 0x000f0510:    pbag len: 0x0000000c loc: 0x000f0518
[d] 0x000f0524:    pmod len: 0x0000000a loc: 0x000f052c
[d] 0x000f0536:    pgen len: 0x00000014 loc: 0x000f053e
[d] 0x000f0552:    inst len: 0x00000042 loc: 0x000f055a
[d] 0x000f059c:    ibag len: 0x00000014 loc: 0x000f05a4
[d] 0x000f05b8:    imod len: 0x0000000a loc: 0x000f05c0
[d] 0x000f05ca:    igen len: 0x00000024 loc: 0x000f05d2
[d] 0x000f05f6:    shdr len: 0x000000e6 loc: 0x000f05fe
                Bank Name: User Bank
                Engine: X-Fi
                Product: SBAWE32
                Designer: Vienna Master
                Tools: SFEDT v1.36:
                Created: Mar 03, 2006
                Comment: Comments Not Present
                Copyright: Copyright Information Not Present
phdr-entry          : 
  presetName          : C3 Sine Bot 8-01
  preset              : 0x0001
  bank                : 0x0000
  presetBagNdx        : 0x0000
  library             : 0x00000000
  genre               : 0x00000000
  morphology          : 0x00000000
  pbag-entry          : 
    genNdx              : 0x0000
    modNdx              : 0x0000
    pgen-entry          : 
      genOper             : kRange
      genAmt              : 0x4848
    pgen-entry          : 
      genOper             : instrument
      genAmt              : 0x0000
      inst-entry          : 
        instName            : C3 Sine Bot 8-01
        instBagNdx          : 0x0000
        ibag-entry          : 
          instGenNdx          : 0x0000
          instModNdx          : 0x0000
          igen-entry          : 
            genOper             : overridingRootKey
            genAmt              : 0x0048
          igen-entry          : 
            genOper             : sampID
            genAmt              : 0x0000
            shdr-entry          : 
              sampleName          : C3 Sine Bot 8-01(L)
              start               : 0x00000000
              end                 : 0x0001402c
              startLoop           : 0x00000008
              endLoop             : 0x00014024
              sampleRate          : 0x0000bb80
              origPitch           : 0x3c
              pitchCorrctn        : 0
              sampleLink          : 0x0001
              sampleType          : leftSample

          imod-entry          : 
            modSrcOper          : 0x0000: linear   +NoController
            modDstOper          : startOffset
            modAmt              : 0x0000
            modAmtSrcOper       : 0x0000: linear   +NoController
            modTransOper        : 0x0008
        ibag-entry          : 
          instGenNdx          : 0x0002
          instModNdx          : 0x0000
          igen-entry          : 
            genOper             : overridingRootKey
            genAmt              : 0x0048
          igen-entry          : 
            genOper             : sampID
            genAmt              : 0x0001
            shdr-entry          : 
              sampleName          : C3 Sine Bot 8-01(R)
              start               : 0x0001404c
              end                 : 0x00028078
              startLoop           : 0x00014054
              endLoop             : 0x00028070
              sampleRate          : 0x0000bb80
              origPitch           : 0x3c
              pitchCorrctn        : 0
              sampleLink          : 0x0000
              sampleType          : rightSample

phdr-entry          : 
  presetName          : C3 Full Scale
  preset              : 0x0000
  bank                : 0x0000
  presetBagNdx        : 0x0001
  library             : 0x00000000
  genre               : 0x00000000
  morphology          : 0x00000000
  pbag-entry          : 
    genNdx              : 0x0002
    modNdx              : 0x0000
    pgen-entry          : 
      genOper             : kRange
      genAmt              : 0x3c3c
    pgen-entry          : 
      genOper             : instrument
      genAmt              : 0x0001
      inst-entry          : 
        instName            : C3 Full Scale
        instBagNdx          : 0x0002
        ibag-entry          : 
          instGenNdx          : 0x0004
          instModNdx          : 0x0000
          igen-entry          : 
            genOper             : overridingRootKey
            genAmt              : 0x003c
          igen-entry          : 
            genOper             : sampID
            genAmt              : 0x0002
            shdr-entry          : 
              sampleName          : C3 Full Scale(L)
              start               : 0x00028098
              end                 : 0x0003c0c4
              startLoop           : 0x000280a0
              endLoop             : 0x0003c0bc
              sampleRate          : 0x0000bb80
              origPitch           : 0x3c
              pitchCorrctn        : 0
              sampleLink          : 0x0003
              sampleType          : leftSample

        ibag-entry          : 
          instGenNdx          : 0x0006
          instModNdx          : 0x0000
          igen-entry          : 
            genOper             : overridingRootKey
            genAmt              : 0x003c
          igen-entry          : 
            genOper             : sampID
            genAmt              : 0x0003
            shdr-entry          : 
              sampleName          : C3 Full Scale(R)
              start               : 0x0003c0e4
              end                 : 0x00050110
              startLoop           : 0x0003c0ec
              endLoop             : 0x00050108
              sampleRate          : 0x0000bb80
              origPitch           : 0x3c
              pitchCorrctn        : 0
              sampleLink          : 0x0002
              sampleType          : rightSample

That's the output from running "jSf.py" on your soundfont. If you're interested you can find my tools at my site. I'm considering starting a bigger project to make it quite a bit easier -- that method still requires a lot of fussy work.

Cheers,
Jeff

marce · Post by **marce** » Mon Mar 06, 2006 10:45 pm

Always is interesting the rare way creative merchandize the soundfont support. So, is supposed the X-FI soundcards are a cheap 24bit hardware sampler. I wonder myself if they still the memory limit for wave block and for total soundfont playing. Anyone knows?

marce · Post by **marce** » Wed Mar 08, 2006 7:10 pm

Well, i have just loaded it in an old sblive card. No error messages, all ok, as a normal soundfont, guessing that the additional info is just ignored.

SampleSmith · Post by **SampleSmith** » Wed Mar 08, 2006 7:49 pm

Good to hear Marce. And Jeff, thanks for the readout -not that I can make a lot out of it

Sorry I didn't get back earlier. I've been struggling with something one of you guys probably knows about.

Back on page 1 of this thread 93143 refered to creating release samples by looping 64 samples, or so, and having the rest of that sample played at note off. I've been able to do that easily enough, but with an instrument that decays, like a guitar, you need to be able to tie the velocity of the release sample to the decayed volume of the note sample. I can't see a way to do this in SF2. I see that in sfzed you can use trigger=release (I think it was), but that ties the release sample velocity to the note on velocity of the previous note.

Am I going to have to move to Kontakt or Giga to acheive this? Here, I'm thinking that if I could apply a volume envelope to the release sample that is linked to the length of the preceding note (i.e. the note length, not the sample length), then I could get that release sample to play at something near to the correct volume.
It seems to me that if one uses a loop to acheive this delay of the release sample, it would be impossible to apply a sensible volume envelope, so a better method would be needed.

Any thoughts?

thanks,
Keith

learjeff · Post by **learjeff** » Thu Mar 09, 2006 12:37 am

That's a question for Rene. Right, the soundfont spec is silent on it. However, the sensible implication is that the release sample amplitude needs to match the current note amplitude to some extent. There may be a way to do it, but it's not standardized.

Guido and I had a nice discussion about this, and he nailed it for MrRay73's release sounds.

I believe it might be possible to do it in the soundfont world but I would not expect it to work consistently on all players. A sound designer could have multiple presets, though, to work best on selected players. And I wouldn't be surprised if the sfz folks have thought through this pretty carefully with some guidance on how to configure it.

Cheers
Jeff

93143 · Post by **93143** » Thu Mar 09, 2006 1:17 am

If you've got a silent loop going, you should be able to use an envelope on that, since technically it's just another note. You won't hear anything until note off, of course, but the envelope will still be running, and when the note ends the sample should start at the volume the envelope was at when the key was released, and follow the release stage from there.

Shouldn't it?

This would require you to approximate the decay of the note-on sample with the envelope on the release sample, of course...

Sascha Franck · Post by **Sascha Franck** » Thu Mar 09, 2006 2:09 am

FWIW, Jeff, I don't exactly "dislike" normalized samples, I just find them less comfortable to work with. Seems I can get better velocity scalings with a mixture of velocity mappings and velocity to volume modulations. But then, I usually don't sample natural instruments often, so my thoughts should defenitely not be any sort of reference.

Regarding soundfonts, I don't exactly like the format too much - basically because of the sample embedding. That's why I also don't like all the new sample library formats that we see these days, as they're all coming with large .dat files, "containers" and whatever - which you can't extract or convert anymore (at least not without a lot of hassle, sometimes even not so legal hassle). Of course, that's because those folks care about copy protection, so it's kinda understandable, but well... it gets in the way of tweakers.

Another thing I don't like about soundfonts is that, without a SB card, you can't edit them while playing. Ok, to my knowledge there's one exception: VSampler. Seems to be the only softsampler actually loading soundfonts as such (without all the conversion blurb) and saving them as well. Unfortunately I find the VSampler UI to be very unpleasant, and apparently a lot of folks think the same, otherwise it'd surely deserve to be *way* more popular, as it's one of the most complete softsamplers when it comes to specs/features (not to forget it's quite more affordable than the "big" ones).

However, the main reason soundfonts are allways looking a bit fishy to me isn't anything about quality - I actually do believe that 16bit is fine even for professional productions, of course assuming the samples are recorded nicely and also assuming the material isn't exactly asking for ultra-pristine quality. A concert grand would probably benefit quite a lot from being sampled in 24bits, the same might be true for about any classical instrument, but it surely doesn't matter as much on a lot of electric instruments.

I actually have a way more "practical" problem with soundfonts. As there's only a handful of commercial soundfonts (at least compared to other formats), as using an SB card is usually your best bet to easily create soundfonts, SF2 is something like the poor mans sampling format.
As a result of that, there's a plethora of free soundfonts. Of course, basically that's a great thing - I mean, who wouldn't like to get a truckload of sampled instruments for free?
Now, that's where the problems start.

- There's too much of them. Which one to use? In my "normal musicians" live (using hardware instruments and such stuff), I have like 3 guitars to chose from (ok, I have quite some more, but most of them just aren't used). When I look at the amount of, say, epiano soundfonts I've been downloading over the years, it seems I got like at least 200 epianos to chose from. Which leads to the next problem...

- There's a VERY high s/n ratio in terms of quality. I would say that there's less than 10% of the freely available soundfonts which actually are sounding ok in, say, an ambitioned hobbyists environment (10% probably being an allready overestimated guess). In addition: Many of them are buried in banks. So you gotta download the complete bank (ok, less of an issue in these days of fast connects being common) and browse through all the sounds in that bank to find out which ones are useful. Next step would be to extract them, because you really don't want the extra mess. And yes, there's a lot of mess to deal with...
When it comes to soundfont quality, I've found the most amazing things in the past (and yeah, I even checked quite a lot of them on an SB card, on which they should probably sound as intended). Such as completely "randomized" looppoints. Such as horrible out of tune soundfonts. Such as completely misplaced keymappings (so playing a C would lead to an A or whatever). In addition, the used source material was just unbelievably bad. No proper keymappings (I mean, you just can't build a proper 1 keyzone soundfont for an SB card = aliasing galore!), noisy as hell, whatever.
In short: To find those (probably less than) 10% of useable soundfonts, you have to wade through a pile of shit, and if it wasn't for places like KVR (where there's people who've allready done the sorting), I'd probably given up on soundfonts entirely.

- There's legal problems with some soundfonts. See, there's even some "free" (and nice) orchestral soundfonts around.
Now, does anybody REALLY think someone hired an orchestra, a studio, cabled up some proper mics, recorded everything properly, then trimmed and looped the samples meticulously, mapped them over keys and velocities... in their SB Live card?!? What drugs would I have to take to believe in such a thing to happen?
It's a very common thing to find in those free soundfonts: They're ripped from commercial libraries. For instance, I once found a soundfont which was a 100% rip from the Vitous Mini AKAI CD (which I bought ages ago).
Another thing one might find rather often are rips of hardware synths. In that case, it's not a legal problem at all in case the synths weren't sample based and in case the presets weren't ripped off. But some "JV-80_raw_patches.sf2" or so soundfont would be clearly breaking copyrights.
Ok, you could allways say "I only dowloaded it from xxlsoundfonts.com", but in case you allready converted them (to use them in any other sampler as the SB Live one, sfz or VSampler), there would be quite some "offensive" wavefiles on your harddisk.
Not that it's likely to happen that any soundfont user will ever be asked (due to soundfonts being the "hobbyist" format), but it's still just clear that there's some copyright infringement.

Oh well, sorry for all that long untechnical blurb.

Cheers,
Sascha

Vendaval · Post by **Vendaval** » Thu Mar 09, 2006 2:29 am

Hi!

... If you don't like free soundfonts, don't use them. It's simple.

Greetings

Sascha Franck · Post by **Sascha Franck** » Thu Mar 09, 2006 2:32 am

Vendaval wrote: ... If you don't like free soundfonts, don't use them. It's simple.

I *do* use quite some.
It's just, some of them aren't "free", they just appear to be.

learjeff · Post by **learjeff** » Thu Mar 09, 2006 6:50 pm

93143, the problem is that there are two things that govern the output level: the programmed volume envelope, which you mentioned, and the "natural" envelope of the sample being played. The second part is the harder one to account for.

Consider an unlooped soundfont. No volume envelope is used at all, because the sample decays naturally. When the key is released, what volume should the release sample play at?

That's the problem that needs to be solved (and may have been, but it's not addressed in the spec).

For looped soundfonts where the sample is very short, or where there's no decay, like a bowed instrument, there's no problem. But most release samples are for keyboard instruments like piano and Rhodes, where longer samples make a big difference in the quality.

Personally, while I think they're nice, I don't find them necessary or miss them in my own soundfont. I'm playing the music, not trying to exactly recreate every nuance of a particular instrument. Well, some nuances are more important than others.

Sasha, I agree. I'd really like to help to raise the S/N ratio. One thing that would be great is a GOOD site (like Hammersound used to be) where folks could rate soundfonts in categories. I raised the issue on this forum and the general response was to refer me to sites that are frankly quite terrible. Nobody seemed the least bit interested in a GOOD site for collecting soundfonts, and I was dumbstruck and disheartened.

One of these days I might try to interest AudioShots (or perhaps this site) into doing it, but I have too many irons in the fire as it is.

Something you may not know; our discussion about normalizing did get me to do some thinking and it helped in addition to some other ideas, and I'm still considering writing a program to help record and assemble large soundfonts. One of the key ideas is to RECORD all samples un-normalized (unlike I did for jRhodes3, where I adjusted the gain for each velocity layer), abandon the "layer" idea completely, and instead allow the sound designer to record and collate a large number of samples and have the program (with guidance) automatically map them. Only after samples are collected and mapped would they be (optionally) normalized and de-noised and other things. This way, the normalization could be done in a way that it would not alter the keyboard response (i.e., if we add to the sample volume, we subtract exactly that amount from its gain level).

Ah well, ideas abount but life is short!

Cheers
Jeff

What I don't know about soundfonts