Closed malcolmsailor closed 1 year ago
In fact it seems that there are a number of other such cases. I just made a big table and queried it for all alt_labels that contained the '.' character. Nearly all occur in op130. I looked at the op95 example and in that case the annotator didn't expect the alt_label key to persist. In all the op130 examples I looked at, in contrast, the annotator seems to have expected the op130 label to persist, leading to all the following chord symbols being in the wrong key in the table. For example, in mn 20 of n13op130_01, the key persists as B-flat, rather than moving to the dominant F.
mn mn_onset filename alt_label
286 148 3/8 n11op95_02.tsv ii/.bIII
63 20 0 n13op130_01.tsv V.I
536 173 0 n13op130_01.tsv I.i64
73 37 0 n13op130_02.tsv II.ii
147 30 0 n13op130_03.tsv I.I6
313 63 1/2 n13op130_03.tsv IV.I
77 56 0 n13op130_06.tsv V.I
257 195 0 n13op130_06.tsv I.I
567 455 0 n13op130_06.tsv I.ii6
591 470 0 n13op130_06.tsv IV.I
The rule has been (since the ABC) that a key change cannot occur (only) in the alternative label. Thanks for looking these up!
The case you show from op95 is not a key change, but an over-generalization of the principle that labels beginning with b
, at the time, needed to be preceded by a .
. Looks like I should do a cleanup. As you noticed, this will require looking into the score at each point to see what the correct key is.
As you can see, on the downbeat of m. 30, there is a chord with an alternate label, either "IV6" or "I.I6".
The issue is that the alternate label changes the key, and the analysis from that point proceeds in that key, but the harmonies tsv file remains in the other key (which is V).
I'm posting this issue in part because I'm curious what the correct behavior is. When an alt label has a key change, should that key change persist?
(Another minor note about this extract is that the annotator seems to have neglected the C-flat at the end of m. 30.)