File won't open - corrupt new. Please view!
Ever since the new update I can no longer open this file. Can anyone else open it? I really need this file, all my backed up versions of this won't open either. The app just crashes (Mac) with no explanation.
| Attachment | Size |
|---|---|
| Toccata.mscz | 73.71 KB |
Comments
File seems to have been created (at least last saved) with MuseScore 2.1 (on Mac).
MuseScore 2.2.1 crashes on opening it, on Windows.
But the latest development build from the master branch can open it. Exporting it as MusicXML there, and importing that in 2.2.1 shows a whole bunch of corruptions, but it loads without crashing when ignoring those.
The score has many 11-lets and other such strange tuplets, but maybe you can start with the xml and fix those corruptions?
What version are you trying to open it with?
In reply to File seems to have been… by Jojo-Schmitz
ubuntu studio 17.10 - attempting to open the file with AppImage 2.2.1 caused an immediate crash. It opened perfectly in 2.1 with no visible unusual tuplets but exporting as XML exposes lots of unusual tuplets.
In reply to ubuntu studio 17.10… by underquark
Indeed it opens just fine in 2.1 (Portable Apps on Windows), but these 16th cadenzas in measures 14 and 15 are tuplets (select a note and watch the Tuplet button in Inspector becoming active). However, no tuplet number shows.
Seems we have a regression in 2.2 here?
In reply to Indeed it opens just fine in… by Jojo-Schmitz
Yes, the tuplets look like the problem. I extracted the MSCX from the MSCZ file and inspected it with an editor and there are 8/11 tuplets, etc.
In reply to Yes, I saved it as mscx file… by underquark
These tuplet markings have been made invisible, and the score is set up to not show invisible items...
There also 30-, 20-, 19-, 17-, 16-, 10-, 9-, 8-, 7-, 6-, 5-, 4- and triplets later in the score
The crash is a division by zero in Fraction::operator -=(). Apparently the denominator of a tuplet ratio is being calculated as 0 during the santizeTuplet() step. It seems this is due to the duration an element of a tuplet is being calculated as 1/512 and we are trying to convert that to a fraction but it isn't valid. The new (for 2.2) DurationType::isValid() should, I think, do an extra check that for t.isValid() before attempting arithmetic on the result. But the end result will be that we fail to sanitize the tuplet, and I have no idea if that will lead to further problems. Although the file opened in 2.1, it seems quite likely these tuplets are corrupt.
In reply to The crash is a division by… by Marc Sabatella
FWIW, on this particular file, simply adding the check for t.isValid() at the end of TDuration::isValid() works and allows the file to open, with a debug message printed to the console that we were unable to santize the tuplet. No idea if the end result is really the same internally as it was on 2.1 or what other bad effects might result. But it's just one tuplet that is a problem.
So a proposed fix is to add a check for t.isValid() by replacing the last line of TDuration::isValid() with:
return (t.isValid() && (t.fraction() - f).numerator() == 0);
In reply to FWIW, on this particular… by Marc Sabatella
Now in the issue tracker as #271161: Regression: Crashes on certain tuplets due to failure to sanitize
In reply to The crash is a division by… by Marc Sabatella
I'm still using 2.1 to test all of this, so I had no problem opening the file.
Checking to see which tuplets may be causing the problem. These are the tuplets that say the entire one is not selected when they actually are.
I'm working backward (just cause that's where I started).
Measure 129: all 8-lets - actually this one only causes a problem because it is nested. If you chose the 5-let there is no problem
Measure 108: 8-let
Measure 103: 8-let
Measure 100: 16-let
Interesting notes: The 8-let on the last beat of measure 71 does not cause a problem. The is the only 8-let that does not cause a problem.
All problem tuplets (those that won't copy) end the measure.
Edit: in spite of the large time difference this is a cross post with Marc's last post. Which tuplet is causing the problem for 2.2?
In reply to I'm still using 2.1 to test… by mike320
Is there a way for me to download 2.1?
In reply to Is there a way for me to… by Ayden_Kael
https://ftp.osuosl.org/pub/musescore/releases/MuseScore-2.1/
In reply to Is there a way for me to… by Ayden_Kael
Or more generally: https://musescore.org/en/download#older-versions
You may want to keep 2.2.1 installed and in addition put the 2.1 portable app onto your machine, for that particular score.
In reply to Is there a way for me to… by Ayden_Kael
I wouldn't recommend using 2.1 at this point - 2.2 fixes way too many crashes and corruptions to want to go back just on account of this. In fact, it was almost certainly 2.1 that created the corruption in the first place; it just didn't notice it. Instead, let's focus on fixing the corruption caused by 2.1 in your score, so you can then use 2.2 safely and hopefully avoid further corruptions.
Based on my analysis combined with that of mike320's, it seems the problem is in measure 100, although the ill effects actually bleed over into 101 as well. So here is a version of your file with those measures cleared out. It will load with no corruptions or crashes into 2.2.1, and then you can re-enter those measures based on this image of how they look loaded into my test version of 2.2.1 with my proposed fix:
In reply to I wouldn't recommend using 2… by Marc Sabatella
thank you! - all for your help