2
$\begingroup$

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

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

enter image description here

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

$\endgroup$
2
  • $\begingroup$ 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. $\endgroup$
    – WMXZ
    Commented Mar 6 at 19:58
  • $\begingroup$ Yes all the files are short, and all by the same number of samples. $\endgroup$
    – selene
    Commented Mar 7 at 1:09

1 Answer 1

2
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ 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! $\endgroup$
    – selene
    Commented Mar 13 at 15:24
  • $\begingroup$ I bolded the bit about the sound window and samples because that really clarified it for me. $\endgroup$
    – selene
    Commented Mar 13 at 15:25

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.