4 ms·
> It seems that float32 is basically just PCM float has higher accuracy around 1.0 than around 2*24. This makes it quite a bit different from PCM which is ful
by timewizard 1y ago
> It seems that float32 is basically just PCM
float has higher accuracy around 1.0 than around 2*24. This makes it quite a bit different from PCM which is fully linear. Which is probably why floating point PCM keeps it's samples primarily between -1.0 and +1.0.
> which was a lossy audio compression
It's not lossy. Your bit depth simply defines the noise floor which is the smallest difference in volume you can represent. This may result in loss of information but at even 16 bits only the most sensitive of ears could even pretend to notice.
> If you give all 31 bits to the exponent, then normalize it to +/-2^7, you get a continuous version of the same function.
You'll extend the range but loose all the precision. This is probably the opposite of what any IEE754 user actually wants.
- dist-epoch 1y ago> Which is probably why floating point PCM keeps it's samples primarily between -1.0 and +1.0. No, it's just it's more natural/intuitive to express algorithms in a normalized range if given the possibility. Same with floating point RGBA (like in GPUs)
- deckar01 1y agoHere is what a 31-bit exponent 0-bit mantissa encoding looks like compared to float32: https://gist.github.com/deckar01/3f93802329debe116b0c3570bed65de2?permalink_comment_id=5647878#gistcomment-5647878 https://gist.github.com/deckar01/3f93802329debe116b0c3570bed...
- timewizard 1y agoI don't have the time to fully analyze this but my concern would be here: exponent *= 2 ** (8 - E) In the E=8 case then this is just `* 1`. In the E=31 case this is now `* 2*-23`. Python is going to do all of this for you in the float64 domain. I think it's possible that you haven't graphed what you intended. You also don't have subnormals, infinities or propagating NaNs. You manage to only retain the signed 0. EDIT: And the midpoint of your system is 0.5. Which is a little uncomfortable.