Fixed audioread bug for large sample numbers

[fascimare]

Audioread was misreading numbers in scientific notation as decimal numbers. Since it requires integers, this would case it to crash. I fixed it by converting the numbers to int and back again to double.

[marie-r]

Dear @fascimare (not sure who this is),

While I am sure this works, scientific notation is not the cause of your problem. Numbers in Matlab are all stored as double precision floating point. Scientific notation is a way of converting them into something that we can interpret. Without seeing what happened, I cannot be sure, but I suspect that either your start or stop was not a whole number. I suspect that line 100 might have been the problem:

rStart = ((rawByteLoc(idx)-rawByteLoc(1))/2) + 1;

if there were an odd number of bytes which should not be the case for 16 bit data. However, if you have 24 bit data, then this might be the case. If you are interested in having this work with 16, 24, or 32 bit data, you should probably be dividing by the sample size. If it is 16 bit data, I am a bit befuddled as to why you would have a number that is not whole.

All my best - Marie

[kfrasier]

@fascimare any thoughts on what should be done here, re:Marie's comment?

[fascimare]

@kfrasier @marie-r I have looked at the issue when you suggested that fix Marie, and it was 16-bit data. The only way I could get it to work was to do this work-around, but I will give it another go. Stay tuned.

Best,
Annebelle