Currently, the read::Description provides:
Some other useful information might include:
- Whether the channels are interleaved or not. If we end up providing unique methods on the
Reader for producing InterleavedSamples and NonInterleavedSamples, this could be a useful indicator for determining the more efficient option?
- Whether the sample is formatted as integer or floating point data.
- The bit depth per sample. Users who care highly about performance could match on this alongside the sample format to request the most efficient target
Sample type when calling Reader::samples.