TransPCM—use Float16/24 to reduce bit-depth, also promotes compression, 2012-05-29: beta v0.1.1 / formerly HalfPrecision / ref.: IEEE 754-2008 Options

[Nick.C]

When I first became aware of the Float16 type I found it interesting in terms of maybe having potential as a possible lossy storage type.

Attached is a processed version of the sample in this thread which has been decoded back to PCM. The processing is as follows (at this stage as there is no player that I am aware of):
Input file Sample [PCM] > FLOAT16 > [PCM] > Output File.

The conversion from integer to Float16 reduces the number of significant bits of the 24-bit sample to (a maximum of) 11. There is therefore an amount of added noise due to truncation. The added noise has been noise shaped using SG's adaptive noise shaping method as used in lossyWAV.

Original Sample

Lossy Float16 Processed Sample [edit] removed due to TransPCM executable / foobar2000 Float16 playback availability, 29th May 2012. [/edit]

If the 24-bit coded sample is encoded with FLAC (wFormatTag left as 0x0001 as FLAC does not handle Floating Point samples and wBitsPerSample is left as 24) there is a saving of in excess of 20% in filesize.

I don't see any practical advantage using this storage type for native 16-bit PCM.

This post has been edited by Nick.C: May 29 2012, 21:36

[Nick.C]

.... a surprise, yes, however as the standard has not become widespread in terms of implementation then I think that Float16 being different is understandable / acceptable in the same way that 8-bit integer is unsigned with a 128 offset compare to 16/24/32 bit signed integers with no offset.

[edit] In terms of headroom, due to the added noise associated mantissa bit reduction, I would expect Float16 to be a final format rather than an interim step for further processing. Use of the full range available in Float16 was a very conscious decision to maximise range (min sample value to max sample value). Also, there is nothing stopping someone reducing the scale of the audio prior to converting to Float16. [/edit]

In my testing, Float16 in a 24-bit sample container compressed better than the same number of 24-bit integer samples upon which the Float16 samples were based. Unfortunately, now that HalfPrecision stores the FMT.wFormatTag properly (0x0003 for Float), FLAC will not compress Float16 output.

HalfPrecision beta 0.1.0b attached. [edit3] superseded, 29th May 2012 [/edit]

• Correction files implemented;
• CRC32 and CRC16 calculated and stored for audio data to allow checking of successful recombination;
• Code speedups.

[edit2] experimental Adaptive Noise Shaping coefficients snuck through.... beta 0.1.0b replaced. [/edit2]



This post has been edited by Nick.C: May 29 2012, 21:37

[Gumboot]

Well, by "huge surprise" I mean "destroy your speakers", and by "any software" I mean that I have to contact my previous employer and have them check to see if I committed that code before one of these files gets into a mobile phone and is played at high volume through a set of earbuds.

In terms of headroom, due to the added noise associated mantissa bit reduction, I would expect Float16 to be a final format rather than an interim step for further processing.

This raises the question of why you need so much low-level resolution, then.

[Nick.C]

It would surprise me if, when using any type of float where the expected range is ±1.0 but the available range is massive (i.e. 10^38 or 10^308), no checks were made by the decoding software on the inbound data to ensure that these limits were adhered to.

As this potential audio type is in its infancy, common practice is not yet defined (although it could be *assumed* that the treatment would be the same as for Float32).

Why maximise resolution? Simply, because it's there to be used. Why limit the type to a range of ±1.0 to 5.96E-08 (i.e. 2^24:1) instead of using ±65504 to 5.96E-08 (i.e. almost 2^40:1)? One of the complaints commonly made against 16-bit integer is lack of resolution compared to relatively commonly available 24-bit integer. The adoption of ±65504 takes the range of the Float16 type beyond that of 32-bit integer.

[Gumboot]

Well it's not really in its infancy. I included 16 bit float (part of the logical extrapolation on power-of-two bit depths) in a file format proposal in 2005, and a couple of years ago the same thing came about as an inevitable consequence of passing the bit depth (whatever it maybe) to a floating-point conversion routine which supported 16-bit as well as 32 and 64 bit precision.

What checks do you propose to perform, and what is the proper action to take on different results?


I don't mean for anything to be changed on my account, anyway. I've already asked for my old code to be reviewed and deleted as appropriate.

This post has been edited by Gumboot: Dec 23 2011, 22:31