Import audio using modified times (time stamps) does not work

[Roy Wallace]

The "Import Audio" feature, which is supposed to create an audio marker at the appropriate places on a gpx trace, does not seem to work when attempting to make markers from "Modified times (time stamps) of audio files".

Following is my attempt which fails:

1. Load JOSM (latest version, 1713)
   
2. Open gpx track (Timespan: Jun 28, 2009 5:35 AM - Jun 28, 2009 7:33 AM (1:57), attached)
   
3. Right click on GPS Layer, select "Import Audio"
   
4. Choose wav file (modified time Sun 28 Jun 2009 17:22:22 AEST, attached)
   

JOSM then warns me that "Some waypoints with timestamps from before the start of the track or after the end were omitted or moved to the start."

An audio file marker is then created at the start of the track. This seems wrong, as the marker should be well and truly within the bounds of the track timespan (17:22 AEST = 7:22 GMT, which is within 5:35 - 7:33).

The checked boxes in audio preferences are the following only:

• Display the Audio menu
  
• Display live audio trace.
  
• When importing audio, make makers from...
  
• * Modified times (time stamps) of audio files.
  

[Roy Wallace]

GPS track

[Roy Wallace]

Audio file

[anonymous]

Probably due to differences in time zones. I'll take a look

[anonymous]

Replying to anonymous:

Probably due to differences in time zones. I'll take a look

Just a wild guess, and sorry if I am stating the obvious, but don't Microsoft operating systems store the time stamps in the local time zone, at least in the FAT file system? In Unix-like systems, the file time stamp would be in UTC, and programs that view the time zone obey the time zone settings and the environment variable TZ.

[David Earl <david@…>]

Yes indeed - that was the first thing I was looking at. GPX stores timezone in its timestamps, though your file does not indicate any timezone, so it is assumed UTC I think, but I am checking.

Which are you using - windows or linux/mac? I assumed you must have been on some unix given you'd used tar and bzip which aren't typical Windows utilities.

[Roy Wallace]

Replying to david@…:

Which are you using - windows or linux/mac?

I am using Linux (Ubuntu 9.04). By the way, anonymous above is a different poster.

[Roy Wallace]

Regarding time zones, the output of ls -l --full-time on the sound file gives "2009-06-28 17:22:22.000000000 +1000". I presume the +1000 refers to the timezone, GMT+10.

Not sure if that helps, but there you are.

[anonymous]

Following is a patch which fixes the issue for me (i.e. the audio file is inserted in the expected place, somewhere in the middle of the GPS track).

It assumes that the audio file modified times are "based on the time zone where the program is running" (I think this is reasonable), and the GPS track times are UTC (certainly reasonable).

I would commit it myself, but seeing as I am new here, I thought I would pass it by you guys first. Please commit when satisfied:

Index: src/org/openstreetmap/josm/gui/layer/GpxLayer.java
===================================================================
--- src/org/openstreetmap/josm/gui/layer/GpxLayer.java  (revision 1713)
+++ src/org/openstreetmap/josm/gui/layer/GpxLayer.java  (working copy)
@@ -26,6 +26,7 @@
 import java.util.Date;
 import java.util.LinkedList;
 import java.util.List;
+import java.util.TimeZone;
 
 import javax.swing.AbstractAction;
 import javax.swing.Box;
@@ -948,7 +949,9 @@
         if ((Main.pref.getBoolean("marker.audiofromwavtimestamps", false)) &&
                 data.tracks != null && ! data.tracks.isEmpty())
         {
-            double lastModified = wavFile.lastModified() / 1000.0; // lastModified is in milliseconds
+            long lastModifiedLocal = wavFile.lastModified();                 // in milliseconds
+            int offset = TimeZone.getDefault().getOffset(lastModifiedLocal); // in milliseconds
+            double lastModified = (lastModifiedLocal - offset) / 1000.0;  // in seconds
             double duration = AudioUtil.getCalibratedDuration(wavFile);
             double startTime = lastModified - duration;
             startTime = firstStartTime + (startTime - firstStartTime) /

[Roy Wallace]

I've attached the patch now instead of inlining it (realise I probably should have done that to start with).

[stoecker]

Add a "[PATCH]" in the title line, so I can differentiate patches from other reports.

P.S. You cannot commit it yourself, as when you are new here, you have no SVN account for JOSM :-)

[David Earl <david@…>]

PLEASE DON'T INSTALL THIS PATCH anyone

I've had a chance to look into this now. While the patch may fix your problem, I'm afraid I think it isn't correct.

The lastModified call in Java returns UTC as expected. It's the GPX time that's wrong - it seems to be importing in one's current time zone not the timezone indicated in the file. More to follow...

[David Earl <david@…>]

Fixed for build 1721. Waypoint times were ignoring timezone (indeed there was a comment saying just that). Previously it hadn't been relevant because times were all relative (audio was started at the first waypoint and synchronized according to the difference, so as long as the difference was consistent it didn't matter what timezone the track was in). But now the ability to work from absolute (UTC) file time stamps on audio files makes this critical.

Roy, as I can't get the files with their exact timestamps preserved, can you test this with your original files please. I've checked it works by setting the filetime to the equivalent of 07:22 GMT in BST (i.e. 08:22) rather than AEST, and that works. I've also checked alternative representations of timezone in time strings.

[Roy Wallace]

Thanks David. Will test this ASAP.

I wonder though, if the GPX time was being imported incorrectly, why didn't this affect "Import Images" (which always worked for me). Wonder if there's another potential bug lurking there - just a thought.

[stoecker]

Note that I very like changed that code again switching to out DateUtils time reading.

The only change introduced should be that all non-TZ data is read as UTC.

[Roy Wallace]

Build 1721 has resolved the issue for me. Cheers.