Understanding Timestamps
There are several different timestamps floating around.
One is the timestamp that mplayer displays. It looks like (the red circles) 
This is the most "accurate" timestamp, though sometimes when playing DVD's with vanilla mplayer this timestamp will magically "reset" itself half way through a DVD title. So you need to use mplayer-edl instead, which is downloaded for you as a dependency. Note also that this timestamp doesn't quite match the DVD's timestamp. See below. So basically you want the DVD timestamp, not this one.
This timestamp is "accurate" and is in "29.97" fps.
Another timestamp is the "OSD" (on screen display) timestamp of mplayer. Which also happens to be the 30fps accurate "DVD" timestamp used by most (I assume all) hardware DVD players/commercial software DVD players (don't use VLC for timestamps, BTW, it has totally off timestamps for DVD's currently). For example:
In order to get the OSD to display in mplayer in windows, run mplayer like mplayer.exe -font c:\windows\fonts\arial.ttf -osdlevel 1 -osd-fractions 1 and then hit the "o" key once it starts playing.
This timestamp is actually barely off. It's in 30 fps, when the movie is really in 29.97 fps. So at the end of a 2 hour movie, your timestamps will be like 8 seconds off "wall time." In this case, click on the "convert 30 to 29.97 fps" button, enter 7 (for 7 seconds, or enter 0:00:07.0), to get the "accurate" timestamp, which is 7.01 seconds.
Note also that "some" DVD's seem to actually have their on screen time in something like 30.03 fps (Snow White being one of them, I believe), so this button won't work in that case. Odd, I know.
So it turns out that just being in 30 fps isn't the only place that DVD timing is weird. Also, it's in 30 fps but the MPEG streams tend to start their first video packet with a time of like 0.28s. This means that if you were to have a ripped version of your DVD, and want to watch that, you'd need to offset your EDL by -0.28s. Also the DVD time comes in "timestamp" packets called NAV packets. They happen about once every 0.5s. But they're offset slightly, too. There'll be one at 0.0s, then, for instance, one at 0.400000, with the mpeg presently at 0.614. So it's about 0.2 seconds offset from the MPEG timestamp, and also about -0.1s offset from the ripped version. So sensible cinema attempts to simplify this by noting in the edl that you're either using file timestamps, or DVD or using DVD timestamps, so it knows how to interpret them. The real kicker is that you seemingly can't "just" use the MPEG timestamps from the DVD, because they sometimes reset half-way through a DVD title (for instance, when it goes to a new VOB because it is switching DVD layers or switching to a header or trailer video segment).
For those curious, mplayer-edl doesn't seek very well. It can only seek to the beginning of a VOBU, which is about every 0.5s. I also had to tweak the timestamp display time to make it more accurate (which it should be), so mute should be accurate down to the frame level. Also the beginning of a seek should be frame accurate, but not the end. Note that you have to use the patched mplayer-edl for seeking to work at all, and for it to be frame accurate, for now.
mplayer edl's look like this (this is what is passed in, finally, to try and make it work):
100 105 1 # a mute 110 110 0 # a skip 115 120 0 1030 1035 1
see mplayer edl's
Also note that "mainlin" mplayer's OSD has a bug where anything past the decimal point is off. Use mplayer-edl version instead, which has slightly better accuracy. Ping me if you want instructions on how to use it in Linux/OS X.
Here is an image of the mplayer-edl play that tries to accomodate for these weirdnesses:
Hardware/commercial DVD players typically display the "DVD" 30fps timestamp. Some are a bit tricky, though. Some of them will calculate the display time "since the last seek occurred" so if you watch a movie straight from beginning to end, they will display the 29.97 fps total time. But if you ever seek once, you're hosed and it will reset to the 30 fps time. Typically most display the 30 fps timestamp all the way through. So timestamps you get from your DVD player will need to be converted to 29.97 fps, but only after doing a local seek to make sure that it's displaying the 30 fps timestamp.
Sensible Cinema assumes that timestamps are relative to the start of the DVD's mpeg stream, and are in 29.97 fps. Sometimes people will want to perform edits on a file instead. In this case one has to coordinate between the two (DVD and file). What happens is that in the DVD itself, the mpeg video will sometimes begin at, say, around timestamp 0.28s (I don't know why, but it typically does, and the number varies from DVD to DVD). This means that if you have a file version of a DVD, the file timestamps will be different than the DVD timestamps by 0.28s. So accomodate for this discrepancy, in the EDL you can note the DVD's starting offset, ex:
"dvd_start_offset" => "0.28"
You can get the number to put here via the "display information about current DVD" button.
Also in order to get the "mplayer-medium-EDL" to work most precisely, you'll want to add this value as well, so that it can calculate itself against the start offset:
"dvd_nav_packet_offset" => [0.866667, 0.944217]
This is just a reading from the beginning of the DVD telling us where the MPEG stream is relative to where the DVD says it is.
One way to obtain higher precision is to enable the OSD (on screen display which has the current timestamps--use the 'o' key), then, when you get to a part you want to edit, move it into slow motion, or use the '.' key to advance it frame by frame and pinpoint problems. You can also hit the "preferences" button and set your "buffer" time to 0, so that it gives you a closer accuracy to what you'll be hearing/playing back. Note that this "buffer" time is only used in "normal" mode so any editing you do in advanced mode always has it set to 0, to allow for more precise editing.
After you're done with an EDL, please submit/upload it to us so others can share/benefit from it :) Also any feedback/questions is welcome.