Data returned by Audioread

I have a question regarding the audioread function in Matlab. Audioread('file.wav') will return a normalized data of -1 to 1 that represents the amplitude of the sound. My question is, Are sensors (ex. Mica2) when acquire a sound signal and after doing the AD sampling will give me the same samples data that i'll get using Audioread?

Answer 1

[Star Strider]

The audioread function will read a previously-recorded audio file, so it will not itself record data from a sensor. You first have to record the data from your sensor and then play it through audioread.

See the documentation for audiorecorder (link) if you want to record sound directly from a sensor that your operating system and MATLAB support.

[Afnan H.]

Thank you for your answer, i know that i doesn't record a signal, but i mean when i record a signal in sensor and i start process the signals in the sensor, are the samples of the signal are the same values that i'll get using the audio read?

[Star Strider]

As you mentioned, audioread normalises the output to a range of ±1. Unless you saved the original maximum amplitude information from your original signal, and multiply it by the audioread output, you will not be able to reproduce it as you recorded it.

If you want to save your original amplitude data, it is best to save them (as well as the time vector or sampling frequency) as a ‘.mat’ file. That way, you can retain all your data as you originally recorded them, and still play them through sound and related functions when you want to.

[Afnan H.]

Thank you very much, highly appreciate it .. but what if i used the 'native' option in the audio read, isn't that will give the original signal as it orginally recorded by the microphone?

[Star Strider]

The 'native' option returns the native format of the file. That could work. I never tested that option.

I would still save the data as a ‘.mat’ file (time and sound vectors) to be certain, as a backup option.

[Walter Roberson]

The 'native' option will give you the values saved in the file. Which is not necessarily the original signal as originally recorded by the microphone, as whatever process wrote the audiofile might have done range conversion.

If you look at the list of datatypes and ranges possible with the native option, https://www.mathworks.com/help/matlab/ref/audioread.html#output_argument_d0e9496 you will notice that the floating point formats only support -1 to +1, not general ranges of floating point numbers, so if the "original signal originally recorded by the microphone" was (for example) 2.173258 volts, then there is no way you could possibly get that out.

The documentation for the MTS300 / MTS310 sensing modules for MOTE2 is not easy to find, but you can find the user manual at http://courses.ece.ubc.ca/494/files/MTS-MDA_Series_Users_Manual_7430-0020-04_B.pdf. If you examine section 3.1 you will see that the specifications for the microphone and for ADC2 are not given.

So... the implication is that you are going to need to manually calibrate a few of each board revision you work with, by presenting known frequency and amplitudes at known distances and seeing what you get out. And if you do that, you might as well calibrate it through to +/- 1.

[Afnan H.]

Thank you very much for your valuable information, but i'm actually going to do a simulation for mica2 implemented in C, not a real experiment. So i was really confused in this part, because in matlab i was processing the audio signal (feature extraction, ..etc) using the sample values that i get from the audioread, so i wasn't sure about how it works in real sensors ( i mean the type of sample values that will be stored in the sensor flash memory after the A/D) in order to do the simulation correctly. Thank you again for your answer, highly appreciate it

[Walter Roberson]

In short: if the absolute measurement matters instead of the relative measurement, then you need to do calibration (or simulate calibration).

If the absolute measurement matters, then you would probably be trying to calculate something like Sound Pressure Level, which you would not be able to directly calculate even if you knew the exact voltage reading in double precision, because without calibration (or a good set of specifications) you would not know how the voltage changes with pressure.

You might be interested in the paper https://npl.stanford.edu/~paul/web/pubs/FarshchiEtAlTBME2006.pdf "A TinyOS-Enabled MICA2-Based Wireless Neural Interface"

[Jan]

@Star Strider: You wrote:

 As you mentioned, audioread normalises the output to a range of ±1

Does it? I've tried it with some files:

S = audioread(FileName);
max(abs(S(:))

and got values smaller than 1.0 . audioread does not normalize the signal.

[Afnan H.]

Thank you very much, highly appreciate all the explanations and the shared links.

[Walter Roberson]

audioread converts file integer data according to internal datatype such that the minimum of the datatype maps to -1 and the maximum maps to +1 (or a single step before +1)

[Jan]

@Walter: I see this in the documentation of audioread also:

 If you do not specify dataType, or dataType is 'double', then y
 is of type double, and matrix elements are normalized values
 between −1.0 and 1.0.

Now unzip the attached file to snap.wav and run (in R2016b):

S = audioread('snap.wav');
min(S, [], 1)
%       -0.37420654296875        -0.527923583984375
max(S, [], 1)
%       0.465606689453125         0.600860595703125

Does not look normalized. What am I missing?

 S = audioread('snap.wav', 'native')

replies an int16 matrix.

I find also in doc audioread:

 Note: Where y is single or double and the BitsPerSample is 32 or
 64, values in y might exceed −1.0 or +1.0.

This is not a normalization also.

[Walter Roberson]

The normalization is according to what the internal data type can hold, not according to the stored range of data.

[Jan]

@Walter: Thanks. Ah, I think I get is slowly: When the signal is stored as int16, the values -32768 and 32767 are scaled to [-1, +1 - e] (with a tiny e such that 0 is still 0 inspite of the tiny asymmetry). And if the maximum value is 17, the output of audioread will be 17/32768.

This means that audioread scales the range, but not the actual signal. Then "normalized values between −1.0 and 1.0" is misleading, at least for me. I ask TMW if they could improve the help text.