Encoding errors (probably problems with sic tool interacting with encoding errors) #3
Comments
|
This is somewhat related to mix-stem beams that |
craigsapp
changed the title
|
Here is a count of the digital scores that contain for i in */kern
do
for j in $i/*.krn
do
grep -l LO:SIC $j
done
done | wc -lwhich reports 3506 files, which is 45% of all scores. So about 10% of files with |
craigsapp
changed the title
|
Maybe do a random sample of the 327 files to see if the all originate from a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the score:
https://polishscores.org/?id=15xx:972
or
https://polishscores.org/?id=pl-gd--ee-1638--005-019
or on VHV:
https://verovio.humdrum.org/?file=https:%2F%2Fhumdrum.nifc.pl%2F15xx:972.krn
There are encoding errors that prevent display on POPC2 website (and VHV),
Looking at the score in VHV, there is a rhythm error around line 394, where there is a mixture of data and interpretations:
The
1enote should not be on the green highlighted line.Also the SIC command
!LO:SIC:v:o=*xywh-#67:4512,4594,3338,605does not make sense. The may be a mixture of a real SIC for a note being placed beforexywh-#67:4512,4594,3338,605rather than before the actual note that the SIC applies to (see next paragraph).A likely problem that could have happend is that the problem spine was originally:
Which has the LO:SIC coming before the non-null interpretation
*xywh-67#:4512,4594,3338,605. Whensicis run to make the sic substitution the sic is applied to the*xywhinterpretation rather than the1d\data token. If so, then I can reverse the process (but the order of the LO:SIC should be fixed by hand. I can add an option tosicso that it will not mix token types such as interpretations and data in this case. These cases can then be fixed by hand by changing the order line LO:SIC lines so that the files do not generate such errors when processed bysic.It does not happen often: there are three files with a total of 23 cases:
Bash command to check files:
(I separated by siglum in case there is a problem with maximum command line doing them all at the same time.)
Here is a check of the rhythm syntax in all files:
I am finding these rhytm errors (only the first one in a file is identified, and the
rcheckgives up):Searching for the string
Errorin thereport-rcheck.txtfile:grep Error /tmp/report-rcheck.txt | grep -B1327 files have rhythm errors (4% of the digital scores):
Click to see list of files and first case of rhythm errors
It would be useful to try to identify if this is an encoder error or a data processing error, or both (such as an encoder error in placing SIC immediately before a note, and not have any non-null interpretations getting in the way).
Adding a check to the
sictool to prevent replacing different token types might solve automatic process of encoding errors. A warning message can be generated whenver the token type will change with asicreplacement. Ther could be asicparameter to allow such change (but I cannot imagine a case where this would happen). Also I could compare the token types, and skip over interpretations when the substitution is a data token type. This might be the best thing to do (but will not catch cases where the encoder mixes up the LO:SIC of two interpretations, such as LO:SIC for a clef being intervened by a*xywhinterpretation).Creating a dry-run option for sic where it lists the substitutions that will be make would be useful. The the substitutions could be reviewed before actually doing the substitutions. Token type mixups could be flagged, and mostly this would be useful to look for same-type tokens such as a
*clefand*xywhinterpretation.The text was updated successfully, but these errors were encountered: