On Thu, Jun 17, 2010 at 4:22 PM, Michael von Glasow <michael@vonglasow.com> wrote:
OK, here's another try. I'm now using the round function from math.h. Run this patch against the same version against which you ran my previous patch (not against the patched version).

Still noisy in that last decimal place.

--- reference/track/subrip-output1.srt 2010-06-16 19:25:15.000000000 -0500
+++ /tmp/gpsbabel.33946/subrip-output1.srt 2010-06-19 18:26:52.000000000 -0500
@@ -1,2265 +1,2265 @@
 1
 00:01:42,000 --> 00:01:43,000
 10 km/h
-19:02:27 Lat=45.49047 Lon=9.15105
+19:02:27 Lat=45.49046 Lon=9.15104
 
 2
 00:01:43,000 --> 00:01:44,000
 7 km/h, 176 m
-19:02:28 Lat=45.49048 Lon=9.15103
+19:02:28 Lat=45.49047 Lon=9.15102

 
 
One thing that may be: since we're working with values that were obtained by converting degrees/minutes to decimal degrees, we might get some uneven values internally. There's a

We do that all the time.   The noise is way beyond the available precision in a double; we round-trip these losslessly in zillions of places.


Conclusion: if the latest patch fails, we might want to test based on the GPX file, which uses decimal degrees already and thus eliminates the possibility of any different behaviors in conversion affecting output. Yes, Cygwin and Mac would still produce different SRT files when fed NMEA, but the error would be +/- .000005 degrees, which is around a meter or even less, 

I wonder if we're overthinking this.  We have *lots* of formats writing floating point numbers as ascii test that provide stable results across platforms.   What's different?   We don't manually round things in most other formats.

RJL
 
-----Original Message-----
From: Michael von Glasow [mailto:michael@vonglasow.com]
Sent: Thursday, June 17, 2010 22:07
To: 'Robert Lipe'
Cc: 'gpsbabel-code@lists.sourceforge.net'
Subject: RE: [Gpsbabel-code] New module for geotagging video files

hmmm... don't think it's the printf this time, more likely the int typecast as that's where the rounding happens. I'll go into McGyver mode and see what I can do...
-----Original Message-----
From: robertlipe@gmail.com [mailto:robertlipe@gmail.com]On Behalf Of Robert Lipe
Sent: Thursday, June 17, 2010 21:50
To: Michael von Glasow
Cc: gpsbabel-code@lists.sourceforge.net
Subject: Re: [Gpsbabel-code] New module for geotagging video files

Don't have time to put it in a debugger right now, but this is a no-kill.

I think the printf brothers round everywhere.

$ cat /tmp/x.c
main()
{
  printf("%f\n", 2.0/3.0);
}
0.666667

RJL

$ ./testo subrip
Running testo.d/subrip.test
--- reference/track/subrip-output1.srt 2010-06-16 19:25:15.000000000 -0500
+++ /tmp/gpsbabel.15981/subrip-output1.srt 2010-06-17 14:44:55.000000000 -0500
@@ -1,7 +1,7 @@
 1
 00:01:42,000 --> 00:01:43,000
 10 km/h
-19:02:27 Lat=45.49047 Lon=9.15105
+19:02:27 Lat=45.49046 Lon=9.15105
 
 2
 00:01:43,000 --> 00:01:44,000
@@ -11,7 +11,7 @@
 3
 00:01:44,000 --> 00:01:45,000
 6 km/h, 177 m
-19:02:29 Lat=45.49050 Lon=9.15102
+19:02:29 Lat=45.49050 Lon=9.15101
 
 4
 00:01:45,000 --> 00:01:46,000
@@ -26,7 +26,7 @@
 6
 00:01:47,000 --> 00:01:48,000
 20 km/h, 177 m
-19:02:32 Lat=45.49056 Lon=9.15088
+19:02:32 Lat=45.49056 Lon=9.15087
 
 7
 00:01:48,000 --> 00:01:49,000
@@ -41,17 +41,17 @@
 9
 00:01:50,000 --> 00:01:51,000
 30 km/h, 178 m
-19:02:35 Lat=45.49068 Lon=9.15062
+19:02:35 Lat=45.49067 Lon=9.15062
 
 10
 00:01:51,000 --> 00:01:52,000
 31 km/h, 173 m
-19:02:36 Lat=45.49073 Lon=9.15054
+19:02:36 Lat=45.49073 Lon=9.15053
 


On Thu, Jun 17, 2010 at 2:38 PM, Michael von Glasow <michael@vonglasow.com> wrote:
Here's the patch for the aforementioned hard and clean way, including new reference output. The SRT file looks OK now, with no more odd roundings. Since all rounding is now done explicitly and cleanly and the precision of the value passed to sprintf matches the length as per the format string, the code should thus be immune to platform-specific whims in that respect.
 
Please have a look at it and let me know if your output now matches mine.
 
Michael
-----Original Message-----
From: Michael von Glasow [mailto:michael@vonglasow.com]
Sent: Thursday, June 17, 2010 20:14
To: 'Robert Lipe'
Cc: 'gpsbabel-code@lists.sourceforge.net'
Subject: RE: [Gpsbabel-code] New module for geotagging video files

I've just had a look at it; since the NMEA file is difficult to analyze as it uses degrees/minutes rather than decimal degrees, I have also looked at the GPX file I created from the NMEA file a while ago (also with Gpsbabel, 2.1.7 beta, on the same system).
 
Basically, at 19:03:06 we get the following latitude values:
My SRT: 45.49184°
Your SRT: 45.49183°
GPX: 45.491830000°
 
So it seems that on my system, sprintf does indeed not truncate but round, converting 45.491835° to 45.49184° - numerically correct but then my explicit rounding is superfluous. On yours, however, 45.491835° becomes 45.49183°: either your system truncates without rounding, or it rounds in a different way: incidentally, we are dealing with the ambiguous case of rounding .5, and it might be that Cygwin + Win round that to 1 whereas MacOS rounds it to 0.
 
Interestingly, both our systems come up with the same longitude of 9.14807° (the exact value according to the GPX trace would be 9.148063333°). Again, the calculated value passed to sprintf would be 9.148068333°, here clearly both systems round it up.
 
From your output I assume that for 19:03:04, your output matches mine, with:
Lat=45.49183 Lon=9.14808
 
the GPX reads
lat="45.491826667" lon="9.148075000"
 
In that case, both our systems would round up.
 
If the last assumption is correct, then:
1. I incorrectly assumed that sprintf truncates rather than rounds, hence the explicit +0.5 in reality introduces errors.
2. sprintf on Cygwin differs from the implementation on MacOS in that .5 becomes 1 on Cygwin and 0 on MacOS when rounded.
 
Which leaves us with two options:
1. the easy way - just drop the +0.5 and thus get no errors, but leave the treatment of the .5 case to the whim of the platform; while not really a practical problem for videomapping, as the error is 1.11 m in north-south direction and (here in Milan) some 79 cm in east-west direction, it would cause testo to report differences on some OSes
2. the harder way - perform all the rounding and truncating explicitly before passing the value to sprintf - something like ((int) ((value + .000005) * 100000)) / 100000.0
 
I'll make some experiments with option 2 and let you know.
 
Michael
-----Original Message-----
From: robertlipe@gmail.com [mailto:robertlipe@gmail.com]On Behalf Of Robert Lipe
Sent: Thursday, June 17, 2010 02:35
To: Michael von Glasow
Cc: gpsbabel-code@lists.sourceforge.net
Subject: Re: [Gpsbabel-code] New module for geotagging video files

Thanx, I've committed this and it does expose a problem that we need to solve.

It looks like there's some numerical instability between the way your system and mine (an iMac running 10.6) converts these.   That explicit attempt to round (sprintf rounds for us...) looks suspicious.  Can you please investigate?

RJL

./testo subrip | head -30
Running testo.d/subrip.test
--- reference/track/subrip-output1.srt 2010-06-16 19:25:15.000000000 -0500
+++ /tmp/gpsbabel.1566/subrip-output1.srt 2010-06-16 19:31:58.000000000 -0500
@@ -191,157 +191,157 @@
 39
 00:02:20,000 --> 00:02:21,000
 0 km/h, 192 m
-19:03:05 Lat=45.49184 Lon=9.14807
+19:03:05 Lat=45.49183 Lon=9.14807
 
 40
 00:02:21,000 --> 00:02:22,000
 0 km/h, 192 m
-19:03:06 Lat=45.49184 Lon=9.14807
+19:03:06 Lat=45.49183 Lon=9.14807
 
 41
 00:02:22,000 --> 00:02:23,000
 0 km/h, 192 m
-19:03:07 Lat=45.49184 Lon=9.14807
+19:03:07 Lat=45.49183 Lon=9.14807
 
 42
 00:02:23,000 --> 00:02:24,000
 0 km/h, 192 m
-19:03:08 Lat=45.49184 Lon=9.14807
+19:03:08 Lat=45.49183 Lon=9.14807
 
 43
 00:02:24,000 --> 00:02:25,000


On Wed, Jun 16, 2010 at 3:09 PM, Michael von Glasow <michael@vonglasow.com> wrote:
> -----Original Message-----
> From: Michael von Glasow [mailto:michael@vonglasow.com]
> Sent: Sunday, June 13, 2010 17:19
> To: 'Robert Lipe'
> Cc: 'gpsbabel-code@lists.sourceforge.net'
> Subject: RE: [Gpsbabel-code] New module for geotagging video files
>
> OK, I'll try to get some reasonably short data.
> At the very most I can provide a regression test
> case, i.e. a GPX file with an SRT file created from it and a
> test that does the same conversion again and compares the results.

here's some sample data with the output of two different conversions:

gpsbabel -p "" -t -i nmea -f "subrip-input.txt" -o
subrip,gps_date=20100409,gps_time=190227,video_time=000142 -F
"subrip-output1.srt"

gpsbabel -p "" -t -i nmea -f "subrip-input.txt" -o
subrip,gps_date=20100409,gps_time=190527,video_time=000142 -F
"subrip-output2.srt"

As you can see, the difference between the two is the sync point: the first
example chooses it in a way that the GPS trace starts after the video,
resulting in the first subtitle being around 1:42 into the video; the second
one specifies a different sync point in the GPS trace so that the first few
minutes of GPS data will be discarded and subtitles start right at 0:00:00.