Cooledit/Audition 32 bit not IEEE-754?

[scott wurcer]

I can't believe Google has no results on this. I made up a tiny waveform and hand entered some exact values then saved it as 32 bit (I tried all three variants offered) and none of them matched the standard when I scanned them with OD on a Unix box.

There is a small Java applet at Babbage.cs.qc that converts numbers back and forth and I confirmed that the Unix machine is generating IEEE-754 compliant numbers and Audition (PC) is not.

24 bit files made on the Unix box work fine when imported as Motorola packed bytes. The Unix machine is not Intel hardware but the simple byte ordering does not seem to be the problem.

BTW on a couple of forums people did mention garbage results sometimes with different "32" bit hardware and Audition.

 

[scott wurcer]

problem solved

The numbers are normalized to 2^23 and then there is the Motorola to Intel byte swapping. This option is NOT one of the import/export options on my version of Cooledit.

 

[phofman]

I have no experience with Audition, but the 32bit HW was certainly 32 bit integer, while you are talking about 32bit floating point.

 

[scott wurcer]

Floating point, the problem might be history eventually. Motorola and Intel processors had reverse order on the bytes of multi-byte variables. If you use Photoshop it offers the option on some formats. My version (all?) of Cooledit only offers the option on 24 bit files. No idea why.

 

[phofman]

If you mean big-endian vs. little-endian formats, e.g. sox can convert them for you. I would guess few GUI audio tools offer the big-endian option.

 

[phofman]

The http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness says the IEEE standard for floating point numbers does not define endianness. That information should be stored in wav header though (RIFF vs. RIFX), at least sox does so.

 

[scott wurcer]

Sox is a real Swiss Army knife. I have everything talking the same language now.