This really isn't the best way to go about doing this. Using Audacity, Adobe Audition, Goldwave, or really any similar software, you can look at actual sample data instead of time data, to easily line up the waveforms visually (and precisely) and get absolutely perfect loops.
Not to say your loops didn't turn out perfect, but you've almost certainly made things more difficult for yourself than they needed to be
Out of curiosity, what software did you use?
I used Goldwave's "set marker" option after zooming down to the very smallest segments of the wave form, which gave me the exact time code at 5 decimal places. To make absolutely certain the loops were bit-perfect, I would copy the highlighted section and then paste at end of selection to compare the wave form. After undoing and redoing several times, I could see if there were any changes in the positioning of the peaks and valleys and adjust accordingly. Once I knew the loop positioning was "dead-on-balls accurate", I then took the 5-decimal time code and multiplied that by 44100. This gave me a sample entry of 3 decimals places which I then used winamp to enter the LOOPSTART data with. I've since been playing through FF7 with my music tracks, and so far the loops have been absolutely perfect. Obviously there's always a chance of a data entry mistake with that many tracks to edit, but it will take me some time to play through the whole game to find out if there are any errors.
Another thing I took into account was instrument bleed-over. Some tracks have this at the intended loop point, and so I made sure my loop points were well past any bleed-over, keeping the entire track intact.
Edit: Actually come to think of it, I could have used sample-based position instead of time code-based. I just didn't think of it at the time. Ah well, the end result comes out the same, even though I gave myself the extra step of multiplying the time code by 44100 to get the sample data. It seems the time code is rounded off to the nearest sample, so my 3-decimal entries are probably being ignored by the ogg code. It ends up being the exact same point anyway. For example in "tender", the time code gave me a sample position of 919786.203, which is rounded off to 919786. I checked in Goldwave, and this is still the exact same point in the track.