[LAU] SFZ vs. GIG

[Robin Gareus]

On 05/28/2012 12:55 AM, Nils wrote:
> On Mon, 28 May 2012 00:34:04 +0200
> Emanuel Rumpf <xbran at web.de> wrote:
> 
>> 2012/5/27 Victor A. Stoichita <vicsto at gmail.com>:
>>>
>>> I hesitate between GIG and SFZ format.
>>
>> Since linuxsampler (svn-version) supports SFZ, I recommend that format.
>> It is flexible, has useful options and can easily be modified.
>> Record the audio-files as flac (or wav), and convert them to oga (ogg
>> audio) for use with SFZ format.
>>
>> If you actually need a different format any time later, you can use
>> a (commercial) sample converter.
>>
>> IIRC, sfz is supported by some commercial samplers too.
>>
>> -- 
>> E.R.
> 
> All statements are good and correct except one.
> Don't use a lossy compression format for samples (Flac is fine). You need as much quality as you can in the sampled instrument business. Doing a good recording is hard enough, you don't want to destroy it with technical errors like compressing your samples. That is even one which could be easily avoided by not doing anything at all :)
> I don't even know why ogg is allowed for sfz, they should have known better.
> 
> 1) You'll get audible artifacts once you record, mix and especially recompress then for the final mix.
> 2) Why the desire to compress at all? Sound quality aside I can only think of the filesize and nobody has to care about filesizes anymore. All harddrives are big enough, you can wait a bit longer for your download and Linuxsampler streams from the disk, so it doesn't matter if the file is bigger or not for your RAM.
> 
> Nils

RAM is the crux. You want to keep all the samples in memory so that they
can play was soon as you press a key without waiting for data from the
disk. But you're absolutely right: Never use lossy formats for
instrument samples.

One use-case for oga (or other lossy formats) is to assign whole songs
per key. ie a rather simple way to trigger background music. In that
case one won't re-encode or re-master the output. Yet the sampler engine
would need to support decoding on the fly (keep the lossy format in mem)
otherwise supporting lossy formats makes indeed no sense.

2c,
robin