Encoding of accidentals #1
Description
Hello,
Thanks for this dataset! The semantic files seem to encode accidentals differently so that I fear that one can't parse them correctly, and perhaps you can help me to understand the convention you used by creating them?
My understanding of the encoding so far was that it is inspired by the PrIMuS semantic definition, but that CPMS decided to encode accidentals in what PrIMuS calls agnostic. With this in mind, this example makes sense to me:
https://github.com/itec-hust/CPMS/tree/main/semantic/training/6826807-5
D#4 is the only note with an accidental symbol, and thus the only note with an accidental in the semantic file. In particular, the F-notes don't get an accidental (which the semantic format of PrIMus would suggest), as the sharp comes from the key but not from an accidental symbol.
My issue arises with https://github.com/itec-hust/CPMS/blob/main/semantic/training/6546825-4/
The F4 note has a courtesy accidental which doesn't show up in the semantic file. But the true issue is that the B-Natural has no indication of that the natural symbol cancelled the key for this note.
When reading the semantic file of the first example, then the sharp of the key must be added to the F note to get the correct pitch. But in the second example the flat must not be added to the B note, and there is no indication in the file encoding which rule to apply then parsing the semantic files.
I just found this example, and it might make the issue much clearer: https://github.com/itec-hust/CPMS/tree/main/semantic/training/91103002-5 : The semantic file has four B-notes
note-Bb4_eighth note-B4_eighth note-B4_eighth note-B4_eighth
The first B-note received a courtesy accidental. The next two are Bb notes due to the key. However, the last B-note has a natural and therefore is a B-Natural. How would one tell the B-natural apart from the B-flats?