16 to 32 bit floating point conversions

[james0tucson]

And I assume you mean by proportional scale that we want the int range -32768..32767 to map to -1.0..1.0 in floats? What OTHER way would anyone EVER want to do this? How can you do this without a multiply somewhere?

OK, well, firt I thought the question was about converting half-precision 16-bit floats to single precision IEEE-754 floats, and I assumed that you'd want "3.14" in half-precision to equal "3.14" when you converted it.

Now I've got to think about this again. You don't want to just convert between different float precisions, you want to map to a propotional scale. Nevertheless with only five bits of exponent, I still imagine there is a better way to do the mapping in the domain of the 5 bit exponent to the 8 bit.

[BarendB]

I still imagine there is a better way to do the mapping in the domain of the 5 bit exponent to the 8 bit.

I just beat you to it Not by mapping the exponent though, simply using a constant exponent, and keeping the values between 1.0 and 2.0

[aciddose]

you guys (BarendB, stefancrs, dblue, AdmiralQuality) are confusing 16b integer with 16b float.

sqook; i can not find any documentation that says aiff stores samples in a float format with less than 32 bits. the 24 and 16 bit formats seem to be linear integer.

[BarendB]

you guys (BarendB, stefancrs, dblue, AdmiralQuality) are confusing 16b integer with 16b float.

Not really..

[aciddose]

i have trouble believing anyone attemping to write aiff loading code doesnt know how to convert an integer to a float on x86..

maybe if you've never programmed for x86 or any other cpu with ieee float support and dont know the conversion functions are required by the specification....

[BarendB]

Doh, I didn't even notice that james was talking about 16b floats until now Time to get some sleep...

[AdmiralQuality]

you guys (BarendB, stefancrs, dblue, AdmiralQuality) are confusing 16b integer with 16b float.

sqook; i can not find any documentation that says aiff stores samples in a float format with less than 32 bits. the 24 and 16 bit formats seem to be linear integer.

I KNOW, that's what I'm saying.

[stefancrs]

d'oh!

[sqook]

sqook; i can not find any documentation that says aiff stores samples in a float format with less than 32 bits. the 24 and 16 bit formats seem to be linear integer.

http://www.borg.com/~jglatt/tech/aiff.htm

From this page:

Because most CPU's read and write operations deal with 8-bit bytes, it was decided that a sample point should be rounded up to a size which is a multiple of 8 when stored in an AIFF. This makes the AIFF easier to read into memory. If your ADC produces a sample point from 1 to 8 bits wide, a sample point should be stored in an AIFF as an 8-bit byte (ie, signed char). If your ADC produces a sample point from 9 to 16 bits wide, a sample point should be stored in an AIFF as a 16-bit word (ie, signed short). If your ADC produces a sample point from 17 to 24 bits wide, a sample point should be stored in an AIFF as three bytes. If your ADC produces a sample point from 25 to 32 bits wide, a sample point should be stored in an AIFF as a 32-bit doubleword (ie, signed long). Etc.

The AIFF standard lets you specify a sample bit size in the COMM chunk. It can be up to 32 bits, but you can find 16 and 24 bit sample sizes as well.

[arakula]

Somehow, the ability to store floating-point samples in an AIFF file eludes me when I read through Jeff's page... it only refers to signed integer samples of various sizes...

[aciddose]

sqook; the 8/16/24 bit sizes are always integer. 32/64 bit sizes are float. it isnt possible to store 32/64 bit integer as far as i can see. it seems the format is the same as riff wave in terms of how sample data is stored.

[james0tucson]

sqook; the 8/16/24 bit sizes are always integer. 32/64 bit sizes are float. it isnt possible to store 32/64 bit integer as far as i can see. it seems the format is the same as riff wave in terms of how sample data is stored.

So the original question about converting half-word floats to single precision was based on wrong assumptions. Going from 2's complement to float is pretty easy.

[BarendB]

Well, the original question was:

how exactly do I go about reading the raw 16-bit values from disk and converting them internally to 32 bit floats?

so I don't think the original question was about 16bit floats at all..

[james0tucson]

Well, the original question was:

how exactly do I go about reading the raw 16-bit values from disk and converting them internally to 32 bit floats?

so I don't think the original question was about 16bit floats at all..

You are absolutely right, and I am very stupid and need to learn to read.

I really like the way you did the scaling in logic without a divide. Is it actually faster than a good hardware divide by a constant? (Just wondering).

[aciddose]

it is better to use a divide or multiply than a bitshift in most cases on modern cpus, and always in c/c++ langauge. the divide or multiply will get optimized to the best form by the compiler, while if you use a bitshift it will not.

in any case, a bitshift will take the same number of cycles as a divide or multiply.. either as a single opcode or in a lea, they all take one cycle. the use of bitshifts in place of multiplies/divides is an artifact of older architectures and is really no longer nessicary in almost all cases.

many multiples/divides will get optimized selectively to both bitshifts and leas on the x86 because sometimes it is more advantageous to use one than the other.