Re: [Linuxsampler-devel] stereo samples format in DLS2/GIG ?

[Josh G. <jg...@us...>]

On Mon, 2003-09-15 at 05:57, be...@ga... wrote:
> Hi, I was just wondering if Christian, Josh or others
> could enlighten me how stereo stamples are stored in DLS2 / GIG files.
> 
> Are they stored as a single interleaved stereo sample or 
> as two separate mono samples where the first is mapped to the
> left output channel while the second to the right channel ?
> Treating stereo samples as two mono samples has the 
> advantage that you can set different loop points, modulation etc stuff.
> 

I'm going to answer for DLS2 since I'm not real sure what GigaSampler
files allow.

Either way is possible actually. A sample can be stored as stereo
interleaved or as individual synchronized mono samples (or even multiple
synchronized surround sound samples). I think the first sample in an
instrument determines the tuning and loop stuff though. So the samples
have to be synchronized.

> Regarding the sample sizes: I've seen only GIG files with 16bit
> samples in in them so far. Is 24bit possible ? If yes, how
> are they stored ? 24-bit packed ? (which means 3 32 bit words
> store 4 24 bit samples).

The DLS2 specification defines that only 8 bit or 16 bit data should be
found in the sample pool. The format is very flexible though, since it
is essentially just embedded wave files. So in theory if one were to use
conditional chunks (a feature in DLS2 files) you could create a new
24bit DLSID signature (globally unique ID) and then use that in your
program without breaking things too badly. This actually might not even
be necessary though. If one were to just write 24 bit wave samples, I'm
sure loading programs would detect this and balk at it, it just wouldn't
be within the DLS2 specs (not breaking the file format though).

> In order to read these 24bit samples from disk efficiently (in large 
> chunks) probably we would need a temporary buffer because 
> the streaming ringbuffers (which in case of 16bit samples are arrays
> of 16bit quantities (=short datatype)), cannot easily cope
> with 3-bytes long (24bit) quantities.
> Ok they can (the ringbuffer.h template class can handle any kind
> of datatype so just define sample_24bit_t as char[3].
> But I guess in order to not incur into CPU read/write penalties
> because usually the x86 needs 32bit-aligned read/writes to be able
> to work with the maximum efficientcy,
> we whould just fit the 24bit samples into 32bit words.
> 

Well I guess as long as you are out of DLS2 specs you could probably
store any format that wave files support. Looks like 32 bit integer, 32
bit float and 64 bit float are all formats you can store in a wave file.
These wouldn't suffer from the alignment issues, but would cause the
file to be larger of course (hmm, now that I think about it, RIFF files
are only 2 byte aligned, I wonder if there is a way to pad 2 bytes when
writing 4 byte samples, if someone was to say mmap the whole mess). It
seems DLS2/GigaSampler files are probably limited to 4Gigs, since thats
the limit of RIFF files.

> Or am I wrong about the read/write alignement issues ?
> 
> thoughts ?
> 
> Benno
> 

I really like the DLS2 specification when it comes to the file format.
It seems to be very flexible and is fairly extend-able (through the use
of conditional chunks and the like). Unfortunately there is a lot of
stuff that seems to be somewhat undefined in the area of modulator
connection blocks and additional audio data formats. As there really
aren't a lot of DLS2 files out on the net, its hard to get an idea of
whats okay and whats not okay. It would be nice to take advantage of >
16 bit width audio, its just deciding how this should be done, and
checking if maybe there is already a program out there that has done it
so we could keep compatibility with other implementations.
Its kind of funny too, since DLS2 is being implemented in rather
interesting stuff (MPEG4 and MS Media player and Quicktime have soft
synth support for playing back MIDI files with DLS2 instruments), but I
cannot find one DLS2 file on the net! Time for an open source editor :)
Cheers.
	Josh Green