Test corpus piece madrigal51.mxl is incorrectly encoded.

[alexandermorgan]

This piece squeezes in two whole-note rests in a single 4/4 measure on several occasions (such as in measure 15 in the canto and alto parts) which throws off the offset readings of all following observations. This piece is currently used in two tests and should probably be replaced with another piece and removed from our test corpus. See measures 11-15 below, especially measure 15.

[alexandermorgan]

These are the two tests that use this piece:
https://github.com/ELVIS-Project/vis-framework/blob/995cb416021004c4d455956616e62527ebd9052c/vis/tests/test_workflow_integration.py

https://github.com/ELVIS-Project/vis-framework/blob/8db2b1498baed44bd68949c61129cca6fdf11550/vis/tests/test_indexed_piece.py

[crantila]

This might also be a problem with whatever's rendering your score. You can see the T, Q, B, and BC parts here have a huge space where the C and A have the second whole rest in the measure, so maybe the lower parts have an invisible rest?

Either way, I suggest fixing the file rather than replacing it. I'll take a look at it right now, because it seems easy to fix.

[crantila]

Called it. Look at those invisible rests in measure 15.

I wish I weren't this accustomed to how things go with MusicXML.

[alexandermorgan]

I agree that it would be relatively easy to fix these measures that are too long, but discovering this mistake really vitiates my confidence in the accuracy of this file. Either way, we'll have to change the expected values for the tests that currently analyze this piece once the file is corrected.

[crantila]

Ohhhh expletive. I didn't think that far ahead, but you're right. No matter, I've posted a version with the rests fixed here. It seems like it shouldn't matter whether the file actually corresponds to an Urtext of Monteverdi's score—as long as it doesn't contain anything too far off.

Anyway, I'll leave this to your best judgment. Poorly-encoded scores are just something we'll always have to deal with.