emit unscaled floating-point-encoded signals instead of re-encoding when input encodings are mismatched

[jrevels]

realized while writing #34 (comment)

Let's say OndaEDF extracts a group of channels to convert into a single Onda.Samples. If all channels have the same LPCM encoding, OndaEDF will just use that, concatenate the channels into a matrix, and boom, done. If the channels have different LPCM encodings, however, OndaEDF will try to select the "best" target encoding and re-encode all of the channels. This re-encoding process involves dithering, which is kind of computationally expensive (requires RNG) and very slightly raises the signal's noise floor (only by the minimal step size of the encoding resolution - well worth it to avoid the quantization distortion that could occur otherwise).

OndaEDF does this because when OndaEDF was originally written, Onda didn't have floating-point encodings, so OndaEDF HAD to select some integer encoding. These days, though, Onda supports floating-point encodings.

Thus, I think we should just remove the whole "encoding selection" machinery entirely if the channels don't all have the same LPCM encoding. Instead, we should just emit an unscaled floating-point encoding (e.g. sample_resolution_in_unit=1.0, sample_offset=0.0, sample_type=Float32). That way no dithering is required and we can delete a bunch of code

[kleinschmidt]

One potential issue with this is that for signals with a big DC offset or signals with wacky scales (e.g., EEG recorded in mV), you could lose precision using floating point if you have a lot of values that are not near zero (although it's possible my intuitions about this are off, I'll have to think about it a bit more). And I'm not sure whether you can detect whether you're in the danger zone just from looking at the headers.

[jrevels]

i'd imagine for most EDFs the DC offset will be low enough and/or the actual sensor precision will be low enough that floating point precision wouldn't come into play

could be wrong though