<p>The following code will remove the first 5 seconds (you can change it for the duration of your calibration tone) of all the .wav files in your working directory:</p>
<pre><code>library(seewave)
library(tuneR)

setwd(&quot;&quot;) # Set your working directory to the folder containig the .WAV files you want to cut.

folder &lt;- dir(pattern=&quot;.wav&quot;) # This will make a list with the names of the .wav files.
length(folder) # Check the number of files in your folder

secs_to_remove &lt;- 5 # Define the number of seconds to remove from the beginning of your .wavs

# Run the .wav cutting loop.
for(i in 1:length(folder))
{
  waveFile &lt;- readWave(folder[i])
  waveName &lt;- substring(folder[i], 1, (nchar(folder[i])-4))
  waveLength &lt;- round(length(waveFile@left) / waveFile@samp.rate, 2)
  cutWave  &lt;- cutw(waveFile, from = secs_to_remove, to = waveLength, output = &quot;Wave&quot;)
  writeWave(cutWave, filename = paste(waveName, &quot;_cut.wav&quot;, sep = &quot;&quot;))
}
</code></pre>
<p>The cut wave files will be saved in your working directory (the same folder where the original audio files were) and will have &quot;_cut.wav&quot; written at the end.</p>
<p>Hope this helps!</p>

CC BY-SA 4.0
2022-11-14T13:53:07.893Z
Thank you very much for you answer and the code sample. I accepted another answer as it was suggesting a solution directly within the software hence saving some disk space, but if could I would accepted both :) I am sure that code will be useful at some stage and to others too! Many thanks !
Morgane
CC BY-SA 4.0
2022-11-10T22:43:03.200Z
2022-11-10T22:43:03.200Z
Matías Muñoz
<p>The question on efficiency depends on the mode of operation.</p>
<p>If you never care about the calibration tone and have a lot of disk space available, you can simply cut the first couple of seconds.</p>
<p>As the calibration tone was inserted for a reason, I would never remove it from the analysis. It becomes only a system-relevant signal, in addition to the bioacoustic signals you are interested in.</p>
<p>If there is a calibration tone, cutting it a-priori indicates that you ignore its reason, which could trigger the suspicion that your data are not calibrated, while it would need calibration.</p>
<p>From a signal processing standpoint of view, reading in a couple of seconds more data does not matter. Starting processing not with the first sample but after a time offset, should also be no issue and I would be surprised if PAMGuard does not offer that possibility.</p>

CC BY-SA 4.0
2022-11-11T11:02:19.720Z
These are very valid points. I fully agree calibration tones are very useful :) I suppose I was worried that in a soundscape analysis for instance, if they recurrently occur at high amplitude in the files, it would influence the final outcome when measuring energy across frequency bands. But maybe I can find a way to make the most of their purpose (ensure calibrated measurements) while still being able to look at some soundscape metrics... I will have a deeper look into it... Thank you for your reply, these are points I should definitely take into consideration !
Morgane
CC BY-SA 4.0
2022-11-11T11:12:54.067Z
I will also look at the time offset option at the processing stage in PAMGuard, as this would save some disk space compared to cutting files. Thanks !
Morgane
CC BY-SA 4.0
2022-11-11T06:10:13.987Z
2022-11-11T06:10:13.987Z
WMXZ
<p>@WMXZ alluded to this in their answer, PAMGuard has a &quot;Skip initial&quot; setting within the &quot;Sound Acquisition&quot; model, I believe it was put in specifically to deal with these calibration tones. Circled in red in the image below.</p>
<p><a href="https://i.sstatic.net/j1UZs.png" rel="noreferrer"><img src="https://i.sstatic.net/j1UZs.png" alt="1" /></a></p>

CC BY-SA 4.0
2022-11-14T13:49:10.687Z
Thank you very much ! I will mark this answer as the accepted one since it provides a straightforward and space saving solution. The others are still very valuable too :)
Morgane
CC BY-SA 4.0
2022-11-11T21:35:41.437Z
2022-11-11T21:35:41.437Z
Taiki Sakai
<p>I am processing a large amount of SoundTrap data in PAMGuard. In some cases, the calibration tones were enabled during data collection, meaning they appear at the beginning of each sound file, and will probably become a problem when extracting detections and soundscape metrics.</p>
<p>I am looking for the best way (if it exists!) to automatically ignore them - either at the processing stage, or later on.</p>
<p>Would it be worth cropping all the files before processing (e.g., removing the first seconds), using some R code similar to the ones suggested <a href="https://bioacoustics.stackexchange.com/questions/235/what-is-an-easy-way-to-split-wav-files-using-r-or-matlab">in this post</a>? or would it be more efficient to manipulate the Pamguard database post processing somehow?</p>
<p>Does anyone have experience with this kind of batch-editing?</p>

CC BY-SA 4.0
2022-11-10T17:14:45.347Z
I assume you don't know a priori which files contain the calibration tones 'cause otherwise you could very well crop the beginning of those files only. If you know exactly what the calibration tones are and what their duration is you could possibly create a simple "matching filter" (a very simple implementation could be done with cross-correlation) to do some detection of those tones at the beginning of each file. If they are detected, then you crop them, otherwise you skip the cropping process.
ZaellixA
CC BY-SA 4.0
2022-11-10T17:24:25.247Z
I can easily know actually! Calibration tones are automatically emitted at the beginning of each recording session, if the option is enabled. So, for any given deployment, I can check the first file, and either all of them or none of them will have the calibration tones, depending on the unit settings. I understand cropping the .wav files would be the way to go for you then? Thanks !!!! :)
Morgane
CC BY-SA 4.0
2022-11-11T11:50:49.160Z
Unfortunately I am not familiar with Bioacoustics and cannot say what exactly the implications would be if you would allow for the calibration tones to be present. On the other hand, if you know of the calibration signal (tones I assume), you could very well perform some cross-correlation to find the exact location (in time) the calibration tones are present and perform a simple subtraction of the calibration tones from the recorded signals. I assume that the recorded calibration tones will have the transfer function of the recording setup applied to them so the subtraction will most (cont.)
ZaellixA
CC BY-SA 4.0
2022-11-11T11:52:57.460Z
(cont.ed) probably not be perfect but I believe (assuming good alignment has been done) that you'll manage to remove a significant portion of the calibration tones. Of course an alternative to get rid of them completely would be to crop the sound files as you and others have already mentioned. Unfortunately I don't know R and I can't help you there but I see that you already have some code that I assume works.
ZaellixA
CC BY-SA 4.0
2022-11-14T13:51:21.593Z
Thank you very much for your comments! Someone suggested a way to directly ignore the first x seconds directly when processing into the software, so I upvoted their answer, but your suggestions were very useful, and can surely apply to other situations! Thank you very much :)
Morgane
<pamguard><soundtrap><r><wav><processing>
How to automatically ignore sections of sound files - crop wav files before processing or manipulate database after?
# How to automatically ignore sections of sound files - crop wav files before processing or manipulate database after?

(Asked by: username_0 on 2022-11-10)

I am processing a large amount of SoundTrap data in PAMGuard. In some cases, the calibration tones were enabled during data collection, meaning they appear at the beginning of each sound file, and will probably become a problem when extracting detections and soundscape metrics.

I am looking for the best way (if it exists!) to automatically ignore them - either at the processing stage, or later on.

Would it be worth cropping all the files before processing (e.g., removing the first seconds), using some R code similar to the ones suggested [in this post](https://bioacoustics.stackexchange.com/questions/235/what-is-an-easy-way-to-split-wav-files-using-r-or-matlab)? or would it be more efficient to manipulate the Pamguard database post processing somehow?

Does anyone have experience with this kind of batch-editing?

**Tags:** pamguard, soundtrap, r, wav, processing

> **Comments:**
> **username_1**: I assume you don't know a priori which files contain the calibration tones 'cause otherwise you could very well crop the beginning of those files only. If you know exactly what the calibration tones are and what their duration is you could possibly create a simple "matching filter" (a very simple implementation could be done with cross-correlation) to do some detection of those tones at the beginning of each file. If they are detected, then you crop them, otherwise you skip the cropping process.  
> **username_0**: I can easily know actually! Calibration tones are automatically emitted at the beginning of each recording session, if the option is enabled. So, for any given deployment, I can check the first file, and either all of them or none of them will have the calibration tones, depending on the unit settings. I understand cropping the .wav files would be the way to go for you then? Thanks !!!! :)  
> **username_1**: Unfortunately I am not familiar with Bioacoustics and cannot say what exactly the implications would be if you would allow for the calibration tones to be present. On the other hand, if you know of the calibration signal (tones I assume), you could very well perform some cross-correlation to find the exact location (in time) the calibration tones are present and perform a simple subtraction of the calibration tones from the recorded signals. I assume that the recorded calibration tones will have the transfer function of the recording setup applied to them so the subtraction will most (cont.)  
> **username_1**: (cont.ed) probably not be perfect but I believe (assuming good alignment has been done) that you'll manage to remove a significant portion of the calibration tones. Of course an alternative to get rid of them completely would be to crop the sound files as you and others have already mentioned. Unfortunately I don't know R and I can't help you there but I see that you already have some code that I assume works.  
> **username_0**: Thank you very much for your comments! Someone suggested a way to directly ignore the first x seconds directly when processing into the software, so I upvoted their answer, but your suggestions were very useful, and can surely apply to other situations! Thank you very much :)  

---

## 3 answers

### Answer by username_4 on 2022-11-11. Score: 5 | Accepted answer

@username_3 alluded to this in their answer, PAMGuard has a "Skip initial" setting within the "Sound Acquisition" model, I believe it was put in specifically to deal with these calibration tones. Circled in red in the image below.

[![1](https://i.sstatic.net/j1UZs.png)](https://i.sstatic.net/j1UZs.png)

> **Comments:**
> **username_0**: Thank you very much ! I will mark this answer as the accepted one since it provides a straightforward and space saving solution. The others are still very valuable too :)  

---

### Answer by username_2 on 2022-11-10. Score: 5

The following code will remove the first 5 seconds (you can change it for the duration of your calibration tone) of all the .wav files in your working directory:

```
library(seewave)
library(tuneR)

setwd("") # Set your working directory to the folder containig the .WAV files you want to cut.

folder <- dir(pattern=".wav") # This will make a list with the names of the .wav files.
length(folder) # Check the number of files in your folder

secs_to_remove <- 5 # Define the number of seconds to remove from the beginning of your .wavs

# Run the .wav cutting loop.
for(i in 1:length(folder))
{
  waveFile <- readWave(folder[i])
  waveName <- substring(folder[i], 1, (nchar(folder[i])-4))
  waveLength <- round(length(waveFile@left) / waveFile@samp.rate, 2)
  cutWave  <- cutw(waveFile, from = secs_to_remove, to = waveLength, output = "Wave")
  writeWave(cutWave, filename = paste(waveName, "_cut.wav", sep = ""))
}

```

The cut wave files will be saved in your working directory (the same folder where the original audio files were) and will have "\_cut.wav" written at the end.

Hope this helps!

> **Comments:**
> **username_0**: Thank you very much for you answer and the code sample. I accepted another answer as it was suggesting a solution directly within the software hence saving some disk space, but if could I would accepted both :) I am sure that code will be useful at some stage and to others too! Many thanks !  

---

### Answer by username_3 on 2022-11-11. Score: 2

The question on efficiency depends on the mode of operation.

If you never care about the calibration tone and have a lot of disk space available, you can simply cut the first couple of seconds.

As the calibration tone was inserted for a reason, I would never remove it from the analysis. It becomes only a system-relevant signal, in addition to the bioacoustic signals you are interested in.

If there is a calibration tone, cutting it a-priori indicates that you ignore its reason, which could trigger the suspicion that your data are not calibrated, while it would need calibration.

From a signal processing standpoint of view, reading in a couple of seconds more data does not matter. Starting processing not with the first sample but after a time offset, should also be no issue and I would be surprised if PAMGuard does not offer that possibility.

> **Comments:**
> **username_0**: These are very valid points. I fully agree calibration tones are very useful :) I suppose I was worried that in a soundscape analysis for instance, if they recurrently occur at high amplitude in the files, it would influence the final outcome when measuring energy across frequency bands. But maybe I can find a way to make the most of their purpose (ensure calibrated measurements) while still being able to look at some soundscape metrics... I will have a deeper look into it... Thank you for your reply, these are points I should definitely take into consideration !  
> **username_0**: I will also look at the time offset option at the processing stage in PAMGuard, as this would save some disk space compared to cutting files. Thanks !  

---

