I think you understand the underlying tech, but the use of “decimation” is not appropriate in this context. The word decimation, in a DSP context, refers to a process that reduces the sampling rate–something that is not happening here.
Changing from a single bit to multi-bit format in this situation is a completely lossless process–in fact, there isn’t even information loss (even in a discrete mathematical sense) until you begin processing the multi-bit form. Which of course happens immediately following that step, since the whole point of this feature is to enable processing of the signal.
It’s unfortunate that some people are getting confused by the use of the word “Native”. We have heard this feedback before, but have not been able to come up with better terminology.
My perspective is–“Native” is a marketing term, not a technical term. It’s meant to communicate that some aspect of DSD handling was done in the best way possible, and to differentiate against products that are “not native” (whatever scary thing that must imply!).
Yes, it is used to describe device drivers that are able to receive DSD streams from applications without encapsulation. It’s also the name of a music store. In both cases, it is intended to communicate that DSD is being handled “right”.
We are using it in much the same way–pairing it with the word “processing” to communicate that the processing is being handled in the best and most DSD-literate manner possible.
Technically this is accurate, but…
There are four main points to get across here:
- This feature applies when playing DSD files
- It avoids a conversion to PCM, which could make things sound better.
- it consumes extra processing power when this is turned on
- We have done this thing in the best possible way.
If people get 3-4 of those points, the text has done its job.
The goal of this text is not to give insight into what is happening under the hood–there is not enough room here to do that topic justice, and most people do not care. This is a fine line to walk.
Being too specific or pedantic can sow seeds of doubt–like maybe there is a “more native” way we could have done it that doesn’t require the “sample rate” qualifier. This is not actually the case. To someone who doesn’t understand the nuts+bolts, trying to expose the underlying implementation details more clearly in such a brief piece of text is going to create more confusion than good.
Also–a small point–the text for the name of the setting should not wrap, since it has a wrapped “fine print” paragraph underneath it. Ideally, there should be some breathing space to allow for translations, too. So the replacement string can’t be much longer than the current one.
Happy to hear any other ideas…I’d rather not have any confusion over this, and the current text has caused at least a little bit of confusion–but this isn’t the first time we’ve tried to re-write this little bit of copy. It’s not an easy one.