Incorrect MEI on Salzinnes 021v #4
Comments
|
Including experts here so you can take a look. If you are planning to upload files with the correction, please don't do it yet. Let's first coordinate on the best workflow to curate the |
|
It's also not the right note names, which is strange... Going to put it in Neon to take a look here. |
|
Thank you @annamorphism! Feel free to play around with the file and see what the error is about. We will provide a new set of MEI files that have automatic corrections in them applied. Presumably, we would like you to use those new files in Neon whenever you are finalizing your corrections/revisions. That'd result in a much cleaner production set of files. The new MEI files will be added to this repository. |
|
Something very weird is going on here. Several of the pitches are mislabeled (but showing up in the spot they are labeled as); others are mislabelled AND in the wrong spot (as though there were e.g. a G2 clef). |
|
I've also played around with this and I think the problem is the invisible clef in line 1105 @annamorphism mentioned. The behaviour in the screenshot above is really similar to what we found in issue DDMAL/Neon#650, where having a clef within a syllable makes the neumes behave really weirdly. In this case, the behaviour is even weirder, because that clef has no line, so it doesn't... exist? This explains the pitches, because the default line for a clef is line 1. It also explains why, even when I deleted the offending neumes, putting them back in didn't solve anything, because the invisible clef was still busy with its shenanigans. I removed that clef in the MEI and uploaded the file again, and the problem was gone. I have no idea how an invisible clef came to be, but I don't think this will be a big problem, especially when DDMAL/Neon#840 is implemented. |
|
@JoyfulGen I tried playing around with it too, and agree that the issue has to do with the clef being inside a syllable. I'm not even sure how it came to be--the syllable should by rights be a linked syllable with precedes and follows, but it isn't, so I can't reproduce the exact situation. Maybe this was being corrected when linked syllables were being altered in some way? I do think I know how the invisible clef got to be there--it's a case of DDMAL/Neon#686 . What's interesting about this special case is that the offending clef gets ignored when rendering the MEI files (so it's also a case of DDMAL/Neon#650 means the glyphs would have been in the right place when the corrector downloaded the MEI, and didn't show up in the wrong place until we re-uploaded it. However, all of this is, it seems, just extra problems on top of the one that @dchiller posted, namely the shared coordinates of the two neumes. What's a little weird here is you would expect the neume components with the shared coordinates to be in the same place, but they aren't. Even after the weird clef is manually deleted, here they are as separate neumes: but in the MEI file they (still) have identical coordinates: If you take out the ligature, though, they bounce over to the right! What's also quite strange is that by rights this ligature shouldn't exist in the first place. The x-coordinate of the first neume in the ligature is to the right of the second; meanwhile the y-coordinate of neume no.1 should be about a third below neume no.2, not (as labelled) a half step above. How did this happen? The mystery deepens.... |
|
Now, what would happen if we were simply to delete one of the neumes with the duplicated coordinates? If it's the one outside the ligature (the first zone defined but the third of the neume components) things are basically OK. We get this gaptoothed fournote neume in orange: It still does something weird with respect to the ligature: The pitches are a little weird, too: even though I manually deleted the line0 clef, the new one doesn't seem to kick in until after the orange guy, so the pitches say F4E4G4F4 and then start with A3G3 on the new syllable. Still, it's nothing that can't be fixed by dragging everybody to the right place. BUT if we decided to delete the other of the duplicated neumes (ie the second defined zone; the component itself is the first half of the ligature) things get weirder. We again have a gaptoothed orange guy here with the last two pitches labeled G4F4, but weirdly the first two are E4 and F4 despite showing up on the same line. If we ignore that and try to insert the missing neume component anyway, it eventually decides it would like to be at the same y value (but not x value) of the new neume component: All of this is pretty weird; the point is that in this file it does seem to make a difference which duplicated neume we decide to delete. On the other hand, I have no idea how the problems of this file came about in the first place, so we shouldn't see issues like this too often. |
In the Salzinnes 021v MEI file , there is an error starting at approx line 1091
production_mei_files/cdn-hsmu-m2149l4/cdn-hsmu-m2149l4_021v.mei
Lines 1091 to 1127 in 5c06b0b
This section of the MEI is included in this part of the image (see end of first shown staff to beginning of the second shown staff):
This was discovered because the bounding boxes associated with neume components on lines 1107 and 1109 have the exact same coordinates, but the neume components are different.
The text was updated successfully, but these errors were encountered: