The mystery of the a52dec decoded samples

I’ve been working a lot on the audio conversion code for xine-lib, with results that are always more satisfying, although Amarok fails to build on this new version, audio playback improved a lot, and with the code being all self-contained, the option of replacing the functions with more optimised code, using MMX, SSE, AltiVec or whatever other SIMD extension is more feasible.

Unfortunately I’ve hit one issue: beside A52 and DTS having a channel order different than most of other formats, I have an issue with the type of the decoded samples. There’s a function called float_to_int() that I supposed truncated the floating-point values to get 16-bit signed integer samples (that were the only format supported by xine before), but the floats themselves don’t play at all, while floating-point data plays fine for most other formats. I had to look up a lot of documentation to find for sure that floating-point samples, like I supposed before, varies in the interval [–1.0,1.0], so I was doing it alright up to now.

Now, if someone has any idea on what the following code does, I’d be glad to know it. The blah() function (with the same name) is present in xine, MPlayer, FFmpeg, and renamed in Ogle and other software too.

#include 
#include 

static inline int16_t blah (int32_t i) {
  if (i > 0x43c07fff)
    return 32767;
  else if (i < 0x43bf8000)
    return -32768;
  else
    return i - 0x43c00000;
}

int main() {
  uint8_t val_1[4] = { 0xFF, 0xFF, 0xBF, 0x43 };

  return printf("%fn%dn", *(float*)(&val_1), blah(*(int32_t*)(&val_1)));
}

The output (on Little-Endian, as val_1 is the byte representation of a float number in Little-Endian) is: 383.999969 and –1; it makes no sense to me, but maybe someone else has a clue..

And for who’s wondering, the byte-value I chosen there is one of the samples decoded by a52dec, so it’s a proper value I’m trying to understand; and for who’s wondering, the proper correspondence for –1 (int16) in float32 format is (approximated) –3.0517e-05.

Edit: thanks Nathan Smith who made me see the spelling error in the title (I still confuse the two).