<blockquote>
<p><strong>Does Raven set the time of ALL files based on the timestamp of the first file? Or does it update with each subsequent file name?</strong></p>
</blockquote>
<p>According to the Raven Pro 1.5 documentation (which only includes new features in 1.5):</p>
<blockquote>
<p>If you open a sound file or sequence with the paging option, then Raven will display the date and time in the paging configuration panel at the top of the window, and you will be able to set not only the page start time as an offset from 0 (which is an existing feature of Raven), but you will also be able to set the page start time as an absolute date and time.</p>
</blockquote>
<p>I think the scenario of having a mismatch in sample-clocks and time clocks is actually a fairly common, but not often acknowledged scenario. My prior experience related to this comes from the other direction: my files tend to have extra samples (due to the sample rate being a tiny bit higher than expected).</p>
<p>I think your second screenshot answers the question. Raven provides several ways to navigate through multi-file datasets. These include clicking on the sliders within a page, buttons to advance pages and a drop-down with the names of files. If you've enabled the &quot;Use clock-time axis labels&quot; feature then Raven also provides some options to navigate by date and time.</p>
<p>When calculating dates and times, Raven appears to use the elapsed time since the start of the file. However, <strong>by default the Begin time (s) and End time (s) measures are just counting the number of digital samples in the &quot;Sound window&quot; divided by the nominal sample rate. Raven has it's own concept of &quot;Sound windows&quot; and this depends on which files are included in the sound.</strong></p>
<p>Raven's default accounting of samples and potential discrepancy with dates and times can create difficulties when trying to use third party software to locate portions of audio that correspond to Raven Selection Tables (e.g. loading a Selection in R or Matlab). However, Raven provides some additional columns that can be added to help line things up in an unambiguous way. In your second screenshot you've already added the &quot;Begin Date Time&quot; column. Additional columns that I suggest adding to resolve any ambiguities between samples, files, and clock date-times are:
Begin File,
End File,
Beg File Samp (samples),
End File Samp (samples),
File Offset (s)</p>
<p>In brief, these columns will include the first and last files for the <em>selection</em> (rather than the Sound Window), as well as the within-file sample numbers with 1 corresponding to the first sample of Begin file (rather than the first sample of the first file in the Sound Window).</p>
<p>It sounds confusing, and I'm not sure whether my response will actually clarify anything or just confuse things further. But hopefully by adding these extra columns you'll then have all the info you need to finish answering the question yourself?</p>

CC BY-SA 4.0
2024-03-13T15:24:04.910Z
Thanks this is really helpful for two reasons (1) just knowing I'm not the only one with time/sample mismatches to deal with :) and (2) it gives a viable reason for the inconsistent axes labels and measurements + a workable solution to deal with it if I'm taking the selections outside Raven. I think adding those measurement columns should be a default minimum set!
selene
CC BY-SA 4.0
2024-03-13T15:25:03.460Z
I bolded the bit about the sound window and samples because that really clarified it for me.
selene
CC BY-SA 4.0
2024-03-13T00:07:18.670Z
2024-03-13T15:25:47.263Z
2024-03-13T15:25:47.263Z
Brian Miller
<p>I have sound files from a recorder that writes very near continously, but with very tiny 0.0192 s gaps between every 1-minute file. A single 60-sec file with a sample rate of 180 kHz should be 10800000 samples but is actually only 10796544 samples. The time stamp of each file is <code>YYMMDD_HHMMSS.wav</code>. Because of this small gap, over time the seconds portion of the filename changes. So, I might have 10 files that end in <code>YYMMDD_HHMM37</code> and then 7 files that end in <code>36</code>, and so on. Occasionally, it will flip back and forth - so several files ending in <code>37</code>, one file ending in <code>36</code>, then another file ending in <code>37</code>, then a file ending in <code>38</code>.</p>
<p>This question is not about how or why that is...I can't answer that. It is what it is :)</p>
<p>My question is when viewing the data in Raven, I typically load a group of files and use the Paging option to be able to scan through the spectrograms. <strong>Does Raven set the time of ALL files based on the timestamp of the first file? Or does it update with each subsequent file name?</strong></p>
<p>I do not see the small gaps in the waveform or spectrogram if I zoom way way in at the delineation between two files. But I can't really tell from the time labels on the x axis and the datetimes in the measurements if they are resetting, or building off the previous file, or what. The axis label and measurements seem inconsistent but I think that just might be a rounding issue with the labels. Does anyone know how Raven handles a situation like this?</p>
<p>Here are a few example screenshots.</p>
<p>Zoomed out showing 6 files at once, with various time gaps in the naming. Each file should be 59.9808 sec long.</p>
<p><a href="https://i.sstatic.net/ue1tC.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ue1tC.png" alt="enter image description here" /></a></p>
<p>Zoomed in showing the transition between two files where there is a 2 sec jump between the two filename timestamps.</p>
<p><a href="https://i.sstatic.net/efioQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/efioQ.png" alt="enter image description here" /></a></p>
<p>Zoomed in showing the transition between two files where there is a (nearly) 1 second overlap between what should be the end of the first file and the start of the next file.</p>
<p><a href="https://i.sstatic.net/9VA4k.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/9VA4k.png" alt="enter image description here" /></a></p>

CC BY-SA 4.0
2024-03-06T19:58:31.890Z
Can you confirm that ALL files are short, or could it be that on average they correspond to the requested sampling rate.  This will happen when time is used to determine file close/open operations.
WMXZ
CC BY-SA 4.0
2024-03-07T01:09:57.040Z
Yes all the files are short, and all by the same number of samples.
selene
<raven><signal-processing><time-stamps>
How does Raven paging deal with imperfectly continuous data?
# How does Raven paging deal with imperfectly continuous data?

(Asked by: username_0 on 2024-03-06)

I have sound files from a recorder that writes very near continously, but with very tiny 0.0192 s gaps between every 1-minute file. A single 60-sec file with a sample rate of 180 kHz should be 10800000 samples but is actually only 10796544 samples. The time stamp of each file is `YYMMDD_HHMMSS.wav`. Because of this small gap, over time the seconds portion of the filename changes. So, I might have 10 files that end in `YYMMDD_HHMM37` and then 7 files that end in `36`, and so on. Occasionally, it will flip back and forth - so several files ending in `37`, one file ending in `36`, then another file ending in `37`, then a file ending in `38`.

This question is not about how or why that is...I can't answer that. It is what it is :)

My question is when viewing the data in Raven, I typically load a group of files and use the Paging option to be able to scan through the spectrograms. **Does Raven set the time of ALL files based on the timestamp of the first file? Or does it update with each subsequent file name?**

I do not see the small gaps in the waveform or spectrogram if I zoom way way in at the delineation between two files. But I can't really tell from the time labels on the x axis and the datetimes in the measurements if they are resetting, or building off the previous file, or what. The axis label and measurements seem inconsistent but I think that just might be a rounding issue with the labels. Does anyone know how Raven handles a situation like this?

Here are a few example screenshots.

Zoomed out showing 6 files at once, with various time gaps in the naming. Each file should be 59.9808 sec long.

[![enter image description here](https://i.sstatic.net/ue1tC.png)](https://i.sstatic.net/ue1tC.png)

Zoomed in showing the transition between two files where there is a 2 sec jump between the two filename timestamps.

[![enter image description here](https://i.sstatic.net/efioQ.png)](https://i.sstatic.net/efioQ.png)

Zoomed in showing the transition between two files where there is a (nearly) 1 second overlap between what should be the end of the first file and the start of the next file.

[![enter image description here](https://i.sstatic.net/9VA4k.png)](https://i.sstatic.net/9VA4k.png)

**Tags:** raven, signal-processing, time-stamps

> **Comments:**
> **username_1**: Can you confirm that ALL files are short, or could it be that on average they correspond to the requested sampling rate.  This will happen when time is used to determine file close/open operations.  
> **username_0**: Yes all the files are short, and all by the same number of samples.  

---

## 1 answers

### Answer by username_2 on 2024-03-13. Score: 2 | Accepted answer

> **Does Raven set the time of ALL files based on the timestamp of the first file? Or does it update with each subsequent file name?**

According to the Raven Pro 1.5 documentation (which only includes new features in 1.5):

> If you open a sound file or sequence with the paging option, then Raven will display the date and time in the paging configuration panel at the top of the window, and you will be able to set not only the page start time as an offset from 0 (which is an existing feature of Raven), but you will also be able to set the page start time as an absolute date and time.

I think the scenario of having a mismatch in sample-clocks and time clocks is actually a fairly common, but not often acknowledged scenario. My prior experience related to this comes from the other direction: my files tend to have extra samples (due to the sample rate being a tiny bit higher than expected).

I think your second screenshot answers the question. Raven provides several ways to navigate through multi-file datasets. These include clicking on the sliders within a page, buttons to advance pages and a drop-down with the names of files. If you've enabled the "Use clock-time axis labels" feature then Raven also provides some options to navigate by date and time.

When calculating dates and times, Raven appears to use the elapsed time since the start of the file. However, **by default the Begin time (s) and End time (s) measures are just counting the number of digital samples in the "Sound window" divided by the nominal sample rate. Raven has it's own concept of "Sound windows" and this depends on which files are included in the sound.**

Raven's default accounting of samples and potential discrepancy with dates and times can create difficulties when trying to use third party software to locate portions of audio that correspond to Raven Selection Tables (e.g. loading a Selection in R or Matlab). However, Raven provides some additional columns that can be added to help line things up in an unambiguous way. In your second screenshot you've already added the "Begin Date Time" column. Additional columns that I suggest adding to resolve any ambiguities between samples, files, and clock date-times are:
Begin File,
End File,
Beg File Samp (samples),
End File Samp (samples),
File Offset (s)

In brief, these columns will include the first and last files for the *selection* (rather than the Sound Window), as well as the within-file sample numbers with 1 corresponding to the first sample of Begin file (rather than the first sample of the first file in the Sound Window).

It sounds confusing, and I'm not sure whether my response will actually clarify anything or just confuse things further. But hopefully by adding these extra columns you'll then have all the info you need to finish answering the question yourself?

> **Comments:**
> **username_0**: Thanks this is really helpful for two reasons (1) just knowing I'm not the only one with time/sample mismatches to deal with :) and (2) it gives a viable reason for the inconsistent axes labels and measurements + a workable solution to deal with it if I'm taking the selections outside Raven. I think adding those measurement columns should be a default minimum set!  
> **username_0**: I bolded the bit about the sound window and samples because that really clarified it for me.  

---

