Just noticed another bug that is on handbrake's end. Even though I know it's not a VidCoder issue, per se, I thought it's worth mentioning since it does affect VidCoder. Not sure how long it has been a problem, since I don't usually trim videos by frame numbers. I'm currently using VidCoder 2.38beta (because it doesn't have the false 'failed encode' bug that also appeared in HB recently), and I also get the same results using HandBrake 1.0.1 GUI.
When selecting a range of frames, HB erroneously uses the ending frame number as the total number of frames. If you're starting at the beginning of the file with frame 0, or if you are starting in the middle and going all the way to the end of the file, you never notice anything, since you get the results you expect. But if you are trying to use a selection in the middle of the file, cutting frames off both the front and the back, it becomes an issue. So in my example, I have selected to encode from frame 3648 to frame 31529, which should be 27882 frames, but the logs for both VidCoder and for HandBrake indicate that it is expecting 31529 frames - the ending frame number. And then it only got 30397 frames, because it reached the end of the file. So my resulting video should have been only 19:22, but it ended up being 21:07, leaving me needing to cut the excess 1:45 off the end.
You're right; I just tested it. HandBrake labels them as "Start" and "End" in the JSON API so I do think it's a problem on their end. Opened HandBrake/HandBrake#502