Incomplete voice in local time signature leads to corruption upon import

• Feb 25, 2019 - 14:56
Reported version
3.1
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

Opening the attached MuseScore 2 file in MuseScore 3 gives the following warning:

Bar 133, stave 1, voice 2 too long. Expected: 3/4; Found: 9/8
Bar 133, stave 3, voice 2 too long. Expected: 3/4; Found: 9/8
Bar 136, stave 1, voice 2 too long. Expected: 3/4; Found: 9/8
Bar 136, stave 3, voice 2 too long. Expected: 3/4; Found: 9/8

However, the MSCX code for the measures in question appears to be valid.

Observations

I tried deleting all measures in MuseScore 2, keeping only a small section around the problem measures. However, I found that the error was no longer displayed when importing into MuseScore 3, so the problem seems to be a special case with this large number of ticks.

Fraction calculations have recently been simplified. Before this happened the error was:

Bar 133, stave 1, voice 2 too long. Expected: 6/8; Found: 54/48
Bar 133, stave 3, voice 2 too long. Expected: 6/8; Found: 54/48
Bar 136, stave 1, voice 2 too long. Expected: 6/8; Found: 54/48
Bar 136, stave 3, voice 2 too long. Expected: 6/8; Found: 54/48

This version of the error was displayed even before the switch to Fractions from integer ticks.

Attachment Size
Mercury_extract.mscx 399.02 KB

Comments

• Feb 25, 2019 - 15:37

The problem is probably related to the presence of local time signatures in bar 80 (Harp 1) and bar 99 (Harp 2).

Here is Staff 1, Measure 133:

Mercury_extract_m133.png

Here is the MSCX v2 code:

      <Measure number="133">
        <Chord>
          <durationType>quarter</durationType>
          <Note>
            <pitch>77</pitch>
            <tpc>13</tpc>
            </Note>
          <Note>
            <Accidental>
              <subtype>flat</subtype>
              </Accidental>
            <pitch>80</pitch>
            <tpc>10</tpc>
            </Note>
          </Chord>
        <Rest>
          <offset x="0" y="2"/>
          <durationType>quarter</durationType>
          </Rest>
        <tick>190080</tick>
        <Chord>
          <track>1</track>
          <durationType>quarter</durationType>
          <Note>
            <track>1</track>
            <pitch>65</pitch>
            <tpc>13</tpc>
            </Note>
          <Note>
            <track>1</track>
            <Accidental>
              <subtype>flat</subtype>
              <track>1</track>
              </Accidental>
            <pitch>68</pitch>
            <tpc>10</tpc>
            </Note>
          </Chord>
        </Measure>

Observations:

  • Voice 2 is incomplete.
  • The local time signature is 2/4, but the given tick value of 190080 is equal to 132 bars the global time signature, which is 6/8.

Both of those are valid in MuseScore 2's MSCX, as demonstrated by the attached example which imports fine in MuseScore 3.

Attachment Size
Voices.mscx 13.58 KB

Reply

• Jan 19, 2021 - 12:25
Reported version 3.x-dev ⇒ 3.1

Pretty strange results in 3.6 (on Mercury_extract.mscx):

Measure 133, staff 1, Voice 3/4 too long. Expected: 9/8; Found: %5
Measure 133, staff 3, Voice 3/4 too long. Expected: 9/8; Found: %5
Measure 136, staff 1, Voice 3/4 too long. Expected: 9/8; Found: %5
Measure 136, staff 3, Voice 3/4 too long. Expected: 9/8; Found: %5

Simular on that other score:

Measure 2, staff  1, voice 3/4 too long. Expected: 9/8; Found: %5
Measure 3, staff  1, voice 3/4 too long. Expected: 9/8; Found: %5

These bogus messages are a 3.6 regression, not happening in 3.5.2 and as such probably earn me a brown bag, for fbe6949. Quite strange though, as that change is in 3.5 already, but only in 3.6 causes that bogus output? https://github.com/musescore/MuseScore/pull/7267 should fix that message (bit not the issue at hand here)

Reply

• Jan 20, 2021 - 03:00

Regarding the issue at hand, it is true that the scores are not corrupted originally, but they become corrupted upon load when gap rests are added for the purpose of filling in incomplete voices. The durations of the gap rests are incorrectly determined based on the length of the measure in terms of the global time signature, rather than the local time signature.

The error is here. It should be

    fillGap(expectedPos, f - expectedPos, track, stretch);
 

where f has been defined earlier to be equal to ticks() * stretch, which is the length of the measure in local ticks.

Making this change allows the rests to be created with the correct duration, meaning that the scores are no longer reported as corrupted upon load.

Reply

• Jan 25, 2021 - 11:36
Status PR created ⇒ fixed

Fixed in branch 3.x, commit 6484f5e96b

_Fix #284796: Incomplete voice in local time signature leads to corruption upon import

Resolves: https://musescore.org/en/node/284796.

Part of the process for verifying the internal integrity of a measure is to create gap rests when any of the voices in the measure are incomplete. The duration of the gap rest was incorrectly determined based on the length of the measure in terms of the global time signature, which caused a problem in the presence of a local time signature._

Reply

Fix version
3.6.1