Inserting measures can cause corruption

• Jan 7, 2023 - 21:29
Reported version
4.0
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
duplicate
Regression
No
Workaround
No
Project

OS: macOS 13.0, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223472200, revision: 5485621

To reproduce:

  1. Open score below

  2. Insert 9 measures after measure 38
    Insert measures here:
    Screenshot 2023-01-07 at 4.21.48 PM.png
    Result:
    Screenshot 2023-01-07 at 4.23.49 PM.png

  3. Save

  4. Close and Reopen the file. It now reports corruption
    Screenshot 2023-01-07 at 4.27.12 PM.png
    Screenshot 2023-01-07 at 4.27.33 PM.png

One thing I noticed in the score is that in many cases the reported measure number/beat number in the lower left corner is incorrect. That leads me to believe that the file is already corrupt in a way that is not being detected by musescore. See the screenshot below.. Unfortunately I do not know how the file got into this state. It started its life as a MuseScore 3 file that was converted to MuseScore 4. The latest version of the musecore 3 version I have does not have the wierd measure numbering behavior, which makes me think that the issue was introduced some time after the conversion happened.

Screenshot 2023-01-07 at 4.18.28 PM.png

Notice how it says beat 13 even though there are only 6 beats per measure in the selected measure. In addition, the selected measure is actually measure 9, not measure 6.

There are no good workarounds for this issue. The best one I have come up with is to export the file to MusicXML, import it into MuseScore 3, insert the measures there, fix the corruption there, and then open it back up in MuseScore 4. I was unable to fix the resulting corruption inside MuseScore 4.


Comments