<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Hi Kevin and Bob,</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Robert from Fraunhofer was
just complaining because Ian claimed that the clipping was "baked
in" to the encoder. Which is untrue to the best of my knowledge.
The encoder/decoder are in a closed floating point relationship
and so if you intercept the decode in the floating point domain,
attenuate it and dither it to 24 bits and then send it on to the
DAC or file or whatever, there will be no clipping. </p></div></div></blockquote><br class=""></div><div>I got a reply from my Spotify contact. Please treat this as confidential information!</div><div><br class=""></div><div><div class="">"I've also found out the float/int situation, and unfortunately it was as I feared, we're using int:s throughout the pipeline. The decoder(s) is/are float, but we clamp them to int right after the decode step. This is also, for sure, on our roadmap to change, but no promises on timeline there either, I'm afraid."</div></div><br class=""><div class="">So at the moment there’s not much they can do. But at least they are aware of the problem and the opportunities now.</div><div class=""><br class=""></div><div class="">All the best,</div><div class="">Eelco</div><div class=""><br class=""></div></body></html>