11
$\begingroup$

tuneR's readWave function is good and works pretty quickly for loading audio recordings into R. But I was wondering if there are any alternative functions for loading .wav files? And if so, are details and raw values the same in the resulting object? Do they also create an object of class Wave?

I'm interested because (a) finding potential speed improvements in my workflow (although I realise this may well depend more on computer power), and (b) I recently became aware that different software might represent recording values differently. This would make transferring calculation methods among platforms quite difficult, and hinder comparison of analyses conducted using different tools.


Edit

To take the suggestions provided by @MarceloArayaSalas; with an example recording tuneR::readWave returns values ranging from -2682 to +2117, while audio::load.wave returns -0.08185064 to +0.06460571. The values have virtually the same distribution, so can be made nearly identical by scaling. I'm having issues with phonTools::load sound, so can't include a test yet.

On the speed issue, load.wave seems to be a lot faster, so could be useful if you don't need the functionality of only loading sections of the file. With a 60-second recording:

microbenchmark(load.wave("/Users/tom/Desktop/Example.wav"),
               readWave("/Users/tom/Desktop/Example.wav"))

Unit: milliseconds
                                        expr       min        lq      mean    median        uq      max neval cld
 load.wave("/Users/tom/Desktop/Example.wav")  1.718556  1.920809  3.031906  1.994384  2.118019 16.81316   100  a 
  readWave("/Users/tom/Desktop/Example.wav") 42.863327 44.798137 46.309252 45.704504 46.310176 63.70035   100   b

enter image description here

$\endgroup$
3
  • $\begingroup$ Is there a reason you're searching for alternatives? $\endgroup$
    – Dan Stowell
    Jul 27, 2022 at 10:36
  • $\begingroup$ @DanStowell - details added. $\endgroup$
    – EcologyTom
    Jul 27, 2022 at 14:23
  • 2
    $\begingroup$ Does anyone know why this difference exists? In Matlab, if you use the audioread() function, you get the same output as audio::load.wave. Why is tuneR::readWave so different? $\endgroup$ Oct 19, 2022 at 14:01

4 Answers 4

7
$\begingroup$

You can also use load.wave from the audio package or loadsound from phonTools. They are not wrappers of tuneR::readWave. That said, readWave is the only function that allows you to read specific segments of the sound files (arguments from and to) which is very convenient.

$\endgroup$
3
$\begingroup$

To add onto the edited question involving the difference in values returned by tuneR::readWave and audio::load.wave and to address the comment made by @etgriffiths:

If you read in a 16-bit linear PCM .wav file using readWave, each sample (from sampling rate) is stored as a signed integer with a value between -2^15 and 2^15-1 (i.e. -32,768 and 32,768). In load.wave and also in MATLAB’s audioread() function (assuming you don’t use the ’native’ modifier), the function will read the file and covert the raw sample values to be a double floating point value between -1 and 1. So to get the values to be comparable from readWave to audio::load.wave or MATLAB's audioread(), just divide the values read into R from readWave by 32768 (or the appropriate number for your bit rate).

$\endgroup$
2
$\begingroup$

Not that I know of, as other bioacoustic packages with their own read functions (i.e., seewave, warbleR, etc.) just use a wrapper to tuneR's readWav function.

$\endgroup$
1
$\begingroup$

To address your comment concerning whether it's worth it to optimize for read speed: read and write speed (to learn more, read about I/O optimization) is usually not a good area optimization to speed up code. A lot of times it is simply limited by processes on your operating system, but far more relevant is the attachment of your compute to your data (internal SSD > internal HDD > external drive > network attached drive > cloud). Put your data nearest to your compute that is justified by your workflow for best performance.

Putting a call to readWave in parallel (for instance, using the doParallel R package) is another way to get the read speed somewhere close to the OS I/O limitation. But it is usually not a big enough speedup to justify the extra work.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.