Importing 2.x scores with dotted tuplets into 3.x reports score as being corrupt and looses notes
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project
Came up in https://musescore.org/en/node/279724, sample score there
Comments
FWIW I could not reproduce from scratch; could be the particular file attached to that thread really does corruption that simply wasn't detected by 2.3.2. Further investigation required.
The problem is with the dotted tuplets (see #279099: Dotted tuplet has incorrect duration after save/reload). That problem has been fixed for scores that have been saved with the current revision of MuseScore 3, but there will still be a problem when importing older scores.
But there is no reason for these to be 9:8 tuplets of dotted sixteenths. Mozart certainly did not write it that way.
Here's a smaller example score indicating the problem...this is basically the last measure of the piano part of the score in question, saved in 2.3.2: one-bar-dotted-tuplets-2pt3pt2.mscz
Which in 2.3.2. looks like:
But when imported into 3.0 (3543170) gets reported as corruption and looks like:
In reply to Here's a smaller example… by ericfontainejazz
I remember one issue (most probably not solved with lower priority) which mentions similar problem. The actual problem there was the inconsistent of the mscx file itself. Tuplets were defined incorrectly in the file structure. MuseScore 2.3.2 somehow processes incorrect structure, but MuseScore 3 does not.
Well, the score is corrupt, so MuseScore is reporting the truth. The tuplets were saved with an incorrect baseLen, and so they have an incorrect duration upon load. Then Measure::checkMeasure() skips over the tuplet's reported duration and adds rests that it thinks are missing from the measure. The measure is completely wrong, anyway. It should look like this:
So basically it sounds to me (and someone correct me if wrong) that MuseScore 2 is what is wrong by producing and allowing an incorrect measure, while MuseScore 3 is right (both in detecting the corruption and in not allowing such a measure to be created). In that case I would vote to close this issue. If someone has such an incorrect score, they will unfortunately have to redo those measures after importing into MuseScore 3.
Thanks Eric! I tend to agree with you.
Loosing a note and corrupting a score can't really be by design. Issue came up again in https://musescore.org/en/comment/1131720
In the attached simpified score (derived from the example furter up, created in 2.3.2), the tuplet is defined as:
The 9 chords as
I can't detect anything illegal or unusual there.
Edit: baseNote 16th seems wrong?
3.x has it as:
That baseDots is the difference. Adding this into the 2.x file doesn't help though. No wonder: this had been added to 3.0 Beta via the fix for #279099: Dotted tuplet has incorrect duration after save/reload
Question is whether it is possible to gracefully detect and import such a score, adding that
baseDots
as neededProbably got to happen in
readTupletProperties206()
or right after it inreadTuplet()
, both in read206.cppthe latest builds from master (so for MuseScore 4) have the same issue.