First: the position of the tempo change is stored in bars
I don’t think so.
- From the screenshot in the @raiatea’s post above it seems to me that the musical time is expressed in much smaller units than bars; apparently, the unit is the MIDI pulse. The usual value these days is 480 or 960 PPQ, so the audio marker at 480 corresponds to 1 crotchet (quarter note). I mean, we can assume that our colleague placed the first tempo change on bar 480, this is not, strictly speaking, impossible, just… interesting. That’s quite a far-out zoom factor for doing tests.
- What slightly worries me here is that the PPQ base of 480 (“the usual value these days”) is “these days”-dependent, software-dependent, and in fact settable in Cubase options. I missed the days when the “usual” value was 96, but still remember when the “usual these days” value was 192. Then it became 384. Today it’s 480, although e.g. Logic already uses 960 (larger number doesn’t mean increased load on the CPU or anything, it’s just a “sampling frequency” of MIDI.
- The map is a table with two columns: musical time in one column, time from clip start in the other (roughly so; the way the clip time is stored is… entertaining; it’s time — not BPM). Referring a bar, not a beat from the map requires the knowledge of the meter (strictly, of the number of crotchets in a bar), adding markers at precise moments where the meter changes, even if tempo remained unchanged. I’d say, quite a host of absolutely unnecessary self-inflicted complications. Also, this value is not in the iXML chunk dump in the screenshot. It cannot be the bar:
There is just not enough information to compute the clip offset from the bar number alone.