Extended 80-bit hex floating point (IEEE?) conversion

stephen barncard stephenREVOLUTION2 at barncard.com
Sun Feb 6 14:28:51 EST 2011


Thanks very much for your input, Alex and Jim. This stuff goes into my
scrapbook.
The designers of the AIFF format wanted to make sure no sample rate value
could left out for a thousand years!

Quite frankly, as I've found, there's only a handful of sample rates that
are in general use, however expressed, and the 80 bit value can be selected
from a lookup table and grokked from files created in other applications. As
I am discovering, there isn't much to control in an audioclip object.

I am still delving into the mysteries of exporting sound out of a Livecode
stack by script. I am now sure it can be done. Long ago I exported an audio
file this way from rev, imported through the raw feature of  Amadeus Pro,
and that fixed the headers and made it playable.

There appears to be only a couple of bit depths allowed in stacks: 16 or 8
bit.  I think everything is converted to a creator-less 16 bit 44.1 binary
stream with about 30 bytes of header inside of the stack. The data
interleaving in Livecode export, WAV and AIF files appear identical, after
the headers are stripped. Perhaps all audio in Livecode is stereo, and both
channels are used anyway for mono. I will have to investigate.
I am just about to experiment with stripping the Livecode header and tacking
on the audio data to a WAV or AIF header.

I have found out that exporting the audioclip in this way will also include
any custom property data attached to the clip, so it may be undesirable to
do that - otherwise the data would appear in the audio (probably inaudible
though).  This could be a way to tag and copyright the audio stream.

I will report on what I find.

sqb

On 5 February 2011 18:07, Alex Tweedly <alex at tweedly.net> wrote:

> You could easily clean this code up.
> You could easily make it much shorter and/or faster
>
> I just ignored corner cases, error checking, and other cases that probably
> don't matter to you.
> I just ignored negative numbers !!!
>
> and with all those caveats, try this in your msg box
>
>  put "400EAC44000000000000" into hexstring
>>
>> repeat with i = 1 to 20
>>  if char i of hexstring is not a number then
>>     put 10 + chartonum(char i of hexstring) - chartonum("A") into t
>>     -- put char i of hexstring && t & CR after msg
>>    put t into v[i]
>>  else
>>   put char i of hexstring into v[i]
>> end if
>> end repeat
>>
>>
>> put 0 into t
>> repeat with i=1 to 4
>>  put t*16 + v[i] into t
>>  -- put i && v[i] && t & CR after msg
>> end repeat
>> put t into texp
>>
>> put 0 into t
>> repeat with i = 5 to 12
>>  put t*16 + v[i] into t
>> end repeat
>> put t into mantissa
>>
>> put texp && mantissa && mantissa & CR after msg
>> put texp - 16383 into texp
>> put mantissa * 2^(texp-31) after msg
>>
>
> Oh, by the way, I also ignored the lower half of the mantissa - i.e. extra
> precision.
> That probably doesn't matter for the kind of numbers you'll see for sample
> rates, etc.
>
> -- Alex.
>
>
> On 05/02/2011 03:01, stephen barncard wrote:
>
>> Still messing with exporting sounds out of Livecode. Working with AIF
>> files for now.
>>
>> I can't yet find where Livecode stores the metadata like length,
>> sample rate and bit depth for imported sound files.
>>
>> In the meantime, I can grab these values from the incoming aif files
>> and store them in custom properties ins the soundclip object.
>>
>> The aiff sample rate is defined in 10 hex bytes of Extended 80-bit
>> floating point, like so: (big endian)
>>
>> 44100  =
>>
>> 40 0E AC 44 00 00 00 00 00 00<
>> http://www.onicos.com/staff/iz/formats/ieee.c>
>>
>> 48000   =
>>
>> 40 0E BB 80 00 00 00 00 00 00<
>> http://www.onicos.com/staff/iz/formats/ieee.c>
>>
>>
>> 96000   =
>>
>> 40 0F BB 80 00 00 00 00 00 00
>>  <http://www.onicos.com/staff/iz/formats/ieee.c>
>>
>>
>> Extended 80-bit floating-point format
>> <http://www.onicos.com/staff/iz/formats/ieee.c>
>>
>>
>>
>> I could use some help here.. I want to detect other sample rates. The ones
>> above were determined by examining them in sound files with known rates.
>>
>> How would I convert these 80 bit hex floating point numbers to the values
>> shown and back again?. Baseconvert doesn't work with this many hex
>> characters. (linked is some C source...)
>> surely this can be done in Livecode...
>>
>> thanks in advance...
>>
>>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  <http://www.google.com/profiles/sbarncar>



More information about the Use-livecode mailing list