audioread() returns wrong data for integer range

In the following code, audioread() returns wrong data but wavread() returns correct data from a wav file if the range parameters [start, finish] are int32 type. If the range parameters are type double, both audioread() and wavread() return correct data.

Is this expected behavior or a bug or my misunderstanding?

%audioread() reads from start=1 for range that is integer;  wavread() correctly returns data starting at 'start'
start = int32(42016);
finish = int32(44440);
%start = 42016;
%finish = 44440;
wavpath = '.\test.wav';
clear arResult Fsar wrResult  Fswr;
[arResult, Fsar] = audioread(wavpath, [start, finish ], 'native');
[wrResult, Fswr] = wavread(wavpath, [start, finish ], 'native');

[John Wygonski]

Update: To make matters more confusing, when I run the code segment above withing my larger Matlab script, I get this error message from audioread():

Error using audioread (line 127) Expected input number 2, range, to be integer-valued.

This is what prompted me in the first place to convert range as double type to int32.

[N/A]

I just ran into the exact same issue. Running version R2013a on Mac. Did you manage to resolve the issue? (other than just substituting wavread as a workaround).

I've used audioread quite a lot before without running into this issue, so I'm assuming its a bug which requires pretty specific circumstances.

[David Heise]

I am getting the same error with audioread() that John Wygonski reports above: "Expected input number 2, range, to be integer-valued". I am getting the error when the elements of the "samples" vector passed to audioread() get large, specifically when MATLAB would report those values in scientific notation. For instance, if I allow display the values of my samples vector in a loop, I get output such as the following:

...
samples =
       531841      536801
samples =
       572801      577761
samples =
     24088961    24094241
samples =
    1.0e+07 *
     3.3396    3.3405
Error using audioread>readaudio (line 228)
Expected input number 2, rand, to be integer-valued.
...

(works until the last iteration)

I have not yet confirmed whether or not audioread is reading the desired segments from the file (which, I believe, was John's original question). I *have* confirmed that the file has around 536 million samples...

Since I am running 2020b, I cannot use wavread() as a workaround. I would try using wavread() with 2015b, but my code is using newer functions of the Audio Toolbox. I'd rather not fiddle with two different versions.

My workaround for now will be to load the entire audio file and use only the segment I need, but in any case the bug John reported (and others echoed) appears to persist.

[For the record, I am running 2020b Update 3 on MacOS Big Sur.]

[Walter Roberson]

i did some digging into the code, but unfortunately going further would require testing with a large .wav and I do not happen to have one large enough sitting around.

[David Heise]

In implementing my "workaround", I noticed a similar error (at the change to scientific notation) when using the calculated sample numbers as indices to access a portion of the entire signal. I was eventually able to get around that issue by explicitly converting the calculated indices to an int (I used uint64) and then *back to a double* since some of the Audio Toolbox functions - in this case, pitch() - expect doubles as input parameters.

It is odd to me that the Audio Toolbox functions - or, for that matter, audioread() - would expect doubles as the type to specify what must be an integer index, but maybe it's done that way since most of the time we rely on the default data type...

In any case, a bit later I'll see if a similar strategy can be used to avoid the aforementioned error with audioread(), and I'll post a code example for the benefit of others running into this particular issue.

Answer 1

[Antara Ganesh Kolar]

Hey, Did you resolve this error? Even I am getting the same error. I am using R2016a on Windows.