Audioread function and 32bit audio

The help information for audioread ( https://uk.mathworks.com/help/matlab/ref/audioread.html ) says that 32 bit audio is read from a .WAV file into a range of -1:+1 (if it's read as a 'native' datatype), at single precision.

My question:

• Is the full-scale of IEEE single precision data being 'scaled' internally to a range of -1:+1 in some way, or is the fuction reading in all the raw IEEE single precision numbers and somehow 'zooming in' as default to show only -1:+1, since that's the range within which we would expect audio to have been scaled (however it was generated or measured)? This latter option would presumably mean that Matlab could read in samples that are greater than -1:+1, and store them without scaling, if that's what was in the WAV file.

Answer 1

[Walter Roberson]

If you encounter a .wav file with 32 bit single precision data, and the data is outside of the range -1:+1 then the data is out-of-specification, an invalid .wav file .

If the .wav uses a codec (not just uncompressed data) then the codec will have assumed that the data is in the correct range, and should be unable to decompress out of the range (except perhaps due to round-off error.)

I'm not saying such files will never happen... but they "shouldn't".

[Mike]

Hi Walter,

Thank you very much for replying to my question - it's much appreciated.

I've done a little more digging, and I think I've partially answered my question... either that, or dug myself into a deeper hold of misunderstanding! First, though, a brief comment on the specification issue for .WAV files in general. My understanding is that, underneath the hood, 16 bit .WAV files encode samples as 16 bit signed integers, in the range -32768 ≤ y ≤ +32767. Clearly these raw numbers are out of the range of +/- 1, but in a standard import to Matlab (i.e. not using 'native' flag) they are converted to double precision, and normalised to range of +/-1. I understand from the ,WAV spec that 24 bit .WAV files record 'raw' sample values in an analogous way, though of course the raw number range differs (Matlab seems to only read in 24 bit files as floating point).

In any case, I have just done a mini-test with an audio recorder, a Zoom F3. This new recorder only writes to 32 bit float .WAV files, and has no manually adjustable input gain at all. Driving an attached sensor (in this case, a piezoelectric 'contact mic') very hard, the device does eventually 'clip', since there is still an analog gain stage with a fixed headroom (even if the user can't control it). The recorded .WAV files, read into Matlab, include a large number of samples of value >1. The max raw amplitude for this mini test is about 18, whether read into Matlab using the 'native' flag or not. Double checking the file in an audio editor (Adobe Audition) confirms this.

Hence, I think, if I haven't misunderstood something thus far, that the 32 bit .WAV spec does indeed record raw numbers, under the hood, that conform to the standard IEEE spec. And hence these might exceed +/-1, in principle. I suppose on my particular Zoom F3 device there must be some analog reference level that determines the arbitrary digital sample value of "1", whatever it is. Perhaps for ADC type purposes this is set somewhere close to where the clipping level might sit for 24 bit audio sampling, with the analog gain set to a minimum (but this is purely speculation). In other words, to a level where it would be very unlikely for a typical input signal to 'clip' the notional analog gain stage, and hence exceed a digital value of +/-1.

[Walter Roberson]

The file format described at https://www.sounddevices.com/32-bit-float-files-explained/ is the IEEE 754 single precision floating point representation.

[Mike]

Thank you again, Walter - that's a really helpful link. As you say, it seems like standard 32 bit .WAV files use the established IEEE standard, and hence the numerical values that can be stored occupy the full ~1500dB range above/below 0. In all practical cases, certainly involving signal sampling, I suppose we'll only be using a tiny fraction of that possible range (i.e. the region around +/-1, give or take).