Answers.Body: <blockquote>
  <p>I am wondering if this is just a Raven quirk, or is there something wrong with my files?</p>
  </blockquote>
  <p>I've experienced the same mismatch in Raven with my files, so I'm fairly confident that the issue you're experiencing at least in part a Raven quirk, but potentially also related to your dataset.</p>
  <p>I believe that this quirk arises from the way that Raven handles recording timing, and particularly the conflict between timing the number of samples since start vs. reading date and time from the timestamps embedded in the file name.</p>
  <p>Raven's ability to interpret the timestamps in file names is a fairly recent feature for this software (compared to the ability to load multiple files anyway). The main way that Raven keeps track of time for sequences of digital files is by counting samples for the nominal sample rate (i.e. the sample rate that comes embedded in the file metadata). If some of the wav files are incomplete, missing, or duty cycled, then this can cause a discrepancy between the clock times from the file names and the duration of recorded audio since the start.</p>
  <p>This is just speculation on my part, and I've never tried to confirm this is really what's going on. I suppose it could also just be a bug in Raven.</p>
  <p>Another workaround in addition to the one you suggested would be to navigate by choosing the file name instead of time. You can do this by selecting the file name from the File Drop-down instead of choosing the time (see red circled &amp; highlighted bit of screenshot).</p>
  <p><a href="https://i.sstatic.net/GPoH2KQE.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/GPoH2KQE.png" alt="Raven screenshot showing File dropdown" /></a></p>
  <p>Of course the feasibility of this workaround depends on how many files you have and how long they are. I have mostly continuous recording with hour-long files, so this workaround works well for me, but if you've got much longer or much shorter files it might be too awkward.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-11-04T00:49:30.223Z
Answers.LastActivityDate: 2024-11-04T01:14:04.067Z
Answers.LastEditDate: 2024-11-04T01:14:04.067Z
Answers.UserDisplayName: Brian Miller
Body: <p>I have a list file that consists of many audio files over a 4 month time frame. Lately, when I go to jump to a certain date and time, it will always jump to 6 hours after the time. For example, if I want to go to February 7th at midnight, I will enter in those hours and it will jump to February 7 at 6 a.m. I figured out a work around (I enter in 6 hours prior to the time I want to sample) but I am wondering if this is just a Raven quirk, or is there something wrong with my files?</p>
  <p>Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-11-13T17:02:37.823Z
Comments.Text: Are your recordings duty cycled or continuous?
Comments.UserDisplayName: selene
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-11-13T17:03:55.460Z
Comments.Text: This question/answer might shed some light on what you've got going on: https://bioacoustics.stackexchange.com/questions/1632/how-does-raven-paging-deal-with-imperfectly-continuous-data
Comments.UserDisplayName: selene
Tags: <raven><time-align><time-stamps>
Title: RavenPro jumps to wrong time
ThreadText: # RavenPro jumps to wrong time
  
  (Asked by: username_0 on 2024-11-01)
  
  I have a list file that consists of many audio files over a 4 month time frame. Lately, when I go to jump to a certain date and time, it will always jump to 6 hours after the time. For example, if I want to go to February 7th at midnight, I will enter in those hours and it will jump to February 7 at 6 a.m. I figured out a work around (I enter in 6 hours prior to the time I want to sample) but I am wondering if this is just a Raven quirk, or is there something wrong with my files?
  
  Thanks!
  
  **Tags:** raven, time-align, time-stamps
  
  > **Comments:**
  > **username_1**: Are your recordings duty cycled or continuous?  
  > **username_1**: This question/answer might shed some light on what you've got going on: https://bioacoustics.stackexchange.com/questions/1632/how-does-raven-paging-deal-with-imperfectly-continuous-data  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2024-11-04. Score: 2
  
  > I am wondering if this is just a Raven quirk, or is there something wrong with my files?
  
  I've experienced the same mismatch in Raven with my files, so I'm fairly confident that the issue you're experiencing at least in part a Raven quirk, but potentially also related to your dataset.
  
  I believe that this quirk arises from the way that Raven handles recording timing, and particularly the conflict between timing the number of samples since start vs. reading date and time from the timestamps embedded in the file name.
  
  Raven's ability to interpret the timestamps in file names is a fairly recent feature for this software (compared to the ability to load multiple files anyway). The main way that Raven keeps track of time for sequences of digital files is by counting samples for the nominal sample rate (i.e. the sample rate that comes embedded in the file metadata). If some of the wav files are incomplete, missing, or duty cycled, then this can cause a discrepancy between the clock times from the file names and the duration of recorded audio since the start.
  
  This is just speculation on my part, and I've never tried to confirm this is really what's going on. I suppose it could also just be a bug in Raven.
  
  Another workaround in addition to the one you suggested would be to navigate by choosing the file name instead of time. You can do this by selecting the file name from the File Drop-down instead of choosing the time (see red circled & highlighted bit of screenshot).
  
  [![Raven screenshot showing File dropdown](https://i.sstatic.net/GPoH2KQE.png)](https://i.sstatic.net/GPoH2KQE.png)
  
  Of course the feasibility of this workaround depends on how many files you have and how long they are. I have mostly continuous recording with hour-long files, so this workaround works well for me, but if you've got much longer or much shorter files it might be too awkward.
  
  
  ---
  
  