Timemap: proposal to represent score time as a fraction in each JSON object

[yucongj]

Currently in Timemap, the score time is somewhat represented in a field called qstamp, which is a number representing "the time in quarter notes from the start of the music to the start of the current event entry". For example (the last example in Timemap), the notation below would result in qstamps: 0, 1.333333, 2.666667, and 4 (offset).

However, representing score times as float numbers loses information when e.g., rounding $\frac{4}{3}$ to be 1.333333. This is problematic in applications where precise score times (as fractions) are needed, as converting from floats back to fractions could be ambiguious, and may result in incorrect fractions like $\frac{171}{128}$.

Since every score time is essentially a fraction (however complicated) that can be unambiguiously generated from the MEI file, why not preserve this information in Timemap? :-) I propose adding two fields to Timemap: (i) cfraction: a fraction representing the cumulative music time of a JSON object, with a quarter note worth $\frac{1}{4}$; and (ii) mfraction: a fraction representing this object's local position within the measure. The field names and other details can be determined in the future, but here's an example for demonstrating the idea:

The table below shows the values of qstamp, cfraction, and mfraction at the beginning of Beethoven_Op31_No3, and then the two triplets in Measure 8. For readability, the first column specifies the measure number (though this also could be included as a new field).

measure	qstamp	cfraction	mfraction
1	0	0/1	0/1
1	0.75	3/16	3/16
1	1	1/4	1/4
1	2	1/2	1/2
2	3	3/4	0/1
2	3.75	15/16	3/16
2	4	1/1	1/4
2	5	5/4	1/2
3	6	3/2	0/1
3	7	7/4	1/4
3	8	2/1	1/2
...	...	...	...
8	22	11/2	1/4
8	22.33333333333333	67/12	1/3
8	22.66666666666667	17/3	5/12
8	23	23/4	1/2
8	23.33333333333333	35/6	7/12
8	23.66666666666667	71/12	2/3
9	24	6/1	0/1
...	...	...	...

Such fractions can be directly calculated from the MEI file, maining using each note's dur attribute (e.g., dur=8 represents an eighth note), and when present, using the tuplet tag as well (which in this case would interpret dur=8 as the value 1/12 instead of 1/8).

I believe including these fractions in the Timemap output is a generic feature that can benefit a variety of applications, especially the ones that involve time stamps in performance recordings. This would certainly benefit my project (which involves audio-to-score alignment!) with improved robustness and easier debugging.

What do you all think?