Answers.Body: <p>You can also use <code>load.wave</code> from the audio package or <code>loadsound</code> from phonTools. They are not wrappers of <code>tuneR::readWave</code>. That said, <code>readWave</code> is the only function that allows you to read specific segments of the sound files (arguments <code>from</code> and <code>to</code>) which is very convenient.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-27T13:57:30.727Z
Answers.LastActivityDate: 2022-07-27T13:57:30.727Z
Answers.UserDisplayName: Marcelo Araya-Salas
Answers.Body: <p>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:</p>
  <p>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).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-26T15:37:28.410Z
Answers.LastActivityDate: 2023-09-26T15:37:28.410Z
Answers.UserDisplayName: Danielle Fradet
Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-27T13:11:23.940Z
Answers.LastActivityDate: 2022-07-27T13:11:23.940Z
Answers.UserDisplayName: Carly Batist
Answers.Body: <p>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 &gt; internal HDD &gt; external drive &gt; network attached drive &gt; cloud). Put your data nearest to your compute that is justified by your workflow for best performance.</p>
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-27T18:05:53.940Z
Answers.LastActivityDate: 2022-07-27T18:05:53.940Z
Answers.UserDisplayName: Dan Woodrich
Body: <p><code>tuneR</code>'s <code>readWave</code> 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 <code>Wave</code>?</p>
  <p>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.</p>
  <hr />
  <p><strong>Edit</strong></p>
  <p>To take the suggestions provided by @MarceloArayaSalas; with an example recording <code>tuneR::readWave</code> returns values ranging from -2682 to  +2117, while <code>audio::load.wave</code> 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 <code>phonTools::load sound</code>, so can't include a test yet.</p>
  <p>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:</p>
  <pre><code>microbenchmark(load.wave(&quot;/Users/tom/Desktop/Example.wav&quot;),
                 readWave(&quot;/Users/tom/Desktop/Example.wav&quot;))
  
  Unit: milliseconds
                                          expr       min        lq      mean    median        uq      max neval cld
   load.wave(&quot;/Users/tom/Desktop/Example.wav&quot;)  1.718556  1.920809  3.031906  1.994384  2.118019 16.81316   100  a 
    readWave(&quot;/Users/tom/Desktop/Example.wav&quot;) 42.863327 44.798137 46.309252 45.704504 46.310176 63.70035   100   b
  </code></pre>
  <p><a href="https://i.sstatic.net/AvWII.png" rel="noreferrer"><img src="https://i.sstatic.net/AvWII.png" alt="enter image description here" /></a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-27T10:36:55.033Z
Comments.Text: Is there a reason you're searching for alternatives?
Comments.UserDisplayName: Dan Stowell
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-27T14:23:37.473Z
Comments.Text: @DanStowell - details added.
Comments.UserDisplayName: EcologyTom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-10-19T14:01:24.277Z
Comments.Text: 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?
Comments.UserDisplayName: etgriffiths
Tags: <r><wav>
Title: Alternative to tuneR::readWave function in R?
ThreadText: # Alternative to tuneR::readWave function in R?
  
  (Asked by: username_0 on 2022-07-27)
  
  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
  
  **Tags:** r, wav
  
  > **Comments:**
  > **username_1**: Is there a reason you're searching for alternatives?  
  > **username_0**: @DanStowell - details added.  
  > **username_2**: 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?  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_3 on 2022-07-27. Score: 7
  
  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.
  
  
  ---
  
  ### Answer by username_4 on 2023-09-26. Score: 3
  
  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 @username_2:
  
  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).
  
  
  ---
  
  ### Answer by username_5 on 2022-07-27. Score: 2
  
  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.
  
  
  ---
  
  ### Answer by username_6 on 2022-07-27. Score: 1
  
  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.
  
  
  ---
  
  