Corruption with very large score, over 4500 measures

• Feb 23, 2015 - 18:18
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

The attached zip contains 4 files

  1. Empty.mscz, created with MuseScore 1.3, 4560 measures long, just needed to demonstrate the problem
  2. Let_us_break.mscz, created in MuseScore 1.3, the 'problem child'
  3. test.album, and album file using the above 2 files, may need adjustment in the path names, or even get build from scratch, by who ever wanting to reproduce this issue.
  4. test.mscz, the result of that album file, i.e. merging those 2 score into one.

You need a nightly build from today or newer to open test.mscz, older ones crash.

it shows 2 issues:

  1. either of the 2 melismas on measures 14 and 15, the word "on_" in voice 2, are causing a very long 'backward' melisma back to measure 13 of the "Empty" part of the album.
    Deleting those melismas in the orginal and creating the album again, and this bug doesn't show.
  2. the "Let us break" part, measures 4, 5, 8, 9, 12, 13, 14 have the voices screwed up, installed of overlapping, as voices should, they are after one another. Select one of those measures to see what I mean. That score alone looks OK, it just does this in an album.
Attachment Size
Test.zip 32.93 KB

Comments

• Feb 23, 2015 - 18:42

Putting "Let Us Break" first in the album doesn't show this problem, but that's not helpful.

MS crashed when I just clicked on the small notes in "Let Us Break" when that score was in second position in the album.

Reply

• Feb 23, 2015 - 20:55

One of the issue could stem from the order of dynamics while importing 1.3 files.
Measure 4 has a dynamic on voice 2 on the second half note, while there is a whole note in the first voice. When creating this notation in 2.0, the file is saved with one half note, the dynamic, and a half note. When opening and saving a 1.3 score, the file is save with dynamic, and the two half note. The dynamic is enclosed between two tick tags to move backward (after the whole) and then forward. I believe this causes issue when reloading the file. It's not visible in the single file, but the album amplify the problem.

Reply

• Feb 23, 2015 - 21:58

Yes, bad lead... next one is a lot more simple. We are getting tick value from the file like 8933760... and we call
int fileDivision(int t) const { return (t * MScore::division + _fileDivision/2) / _fileDivision; }.
MScore::division is 480... I think we are out of the limit.

Reply

• Feb 24, 2015 - 07:20
Status (old) fixed ⇒ active

unfortunately I still see the problem. To a lesser extent, now that melisma goes back only 118 measures (in my original album), but it still does and those screwed up measures still exist too.
I can't currently reproduce though with the examples attached to this issue...

Reply

• Feb 25, 2015 - 15:06
Status (old) active ⇒ fixed

Apparent caused by a corruption elsewhere in that large score, identified by the new sanity check and fixed...

Reply