Brent already said it, that type of syncing is HARD, particularly on mobile devices, particularly when isolated from the raw native API’s as with Corona.
The problem is, by the time the song ends, and the event propagates to your listener, it’s far too late to start another song (or same song at new seek point) without interruption – guaranteed lag of at least the length of the now-empty sound buffer in the BEST-case scenario.
What you really need is a low-level event like “audio system just filled the last buffer, so audio WILL BE ending in (buffer_size/play_frequency) seconds, so prepare to start feeding it new data from an alternate source to pre-fill the next buffer before this one runs out if you want uninterrupted audio.”
But no way you’re getting THAT event! 
What you could do, perhaps?, is have say 5 1-minute clips of varying tempos, that individually loop cleanly. Reserve two music channels, and open the first two streams, immediately pausing the faster one. (so the faster one is pre-buffered, ready to play on a moment’s notice) First one just keeps looping, until some later point (under your control) you fade it out simultaneously starting the second (faster) channel. You also then pre-load the NEXT faster song back into the first channel, ping-pong style, in preparation of doing it all again, until the last (fastest) clip which just loops forever.
fwiw,hth