mscx file saved under 3.0 nightly (70b00e6) crashes musescore when loading
I saved a score using the highly build, saved to .mscx but now when I try to load it musescore crashes.
I'm including the score file and also the crash log.
| Attachment | Size |
|---|---|
| Shackles-shift-8th.mscx | 1.82 MB |
| musescorecrash.txt | 81.9 KB |
Comments
After the crash, I downloaded the newest highly, MuseScoreNightly-2016-10-09-1850-master-cfbff1e.dmg, and it seems to have the same problem.
In reply to After the crash, I downloaded by jim.newton.562
It's an imported and corrupted MIDI File.
The 2.0.3 doesn't detect this, and, indeed, there is a crash by opening with a current nightly, ie: 423a066
This may "solved" by exporting this file, first, in MusicXML format. Then, no crash, the opening is possible after clicking "Ignore" in the warning window ( there is about twenty corrupted measures)
In reply to It's an imported and by cadiz1
Hmm, do I need to export it in MusicXML? Wouldn't I first have to open it first? Which I'm unable to do?
In reply to Hmm, do I need to export it by jim.newton.562
As said, this file (inport MIDI format) is corrupted. Please, before anything else, attach the source of this file.
In reply to Hmm, do I need to export it by jim.newton.562
You wrote:
Wouldn't I first have to open it first? Which I'm unable to do?
It opens for me in MuseScore 2.0.3 (ignore the warning).
In reply to It's an imported and by cadiz1
Some history of the file.
I first imported it from midi several days (weeks ago), then started massaging the file by hand to make it more appealing to the eye and ear.
The most recent massive change I did, was to select the entire score, excluding the first 1/8 count, then moved it backward in time by 1/8 count. This was discussed in the forum https://musescore.org/en/node/136516
I played this several times in the current session, then saved the file as mscx. BTW I always save as mscx, because this takes up less space in version control. I.e., only the diffs are stored for successive versions, whereas with the compressed format, every version in its entirety must be saved in the version control system.
Thereafter, on a different computer (same OS mac but different hardware, work vs home) I tried to open the file, and saw the crash. I haven't yet tried to re-open the file on the same computer which generated it.
In reply to Some history of the file. I by jim.newton.562
So in your version control you have a working file, just before the change causing the crash?
In reply to So in your version control by Jojo-Schmitz
I'll have to see whether any version in the VC can be opened before the infected one. Would that help?
In reply to I'll have to see whether any by jim.newton.562
It might
Can you attach the source midi file?
In reply to Can you attach the source by Jojo-Schmitz
I found it attached to another issue. Here it is again.
In reply to I found it attached to by jim.newton.562
Thanks.So, this Midi file (large one!) is openable with the current nigthly, right? (as with the 2.0.3).
![initial.jpg]( "initial.jpg")
![ex.jpg]( "ex.jpg")
As can happen with this format, there is much work to refurbish it (voices, rests, etc.).
And it seems that your attempt did not help the case, quite the contrary. With such a large score, it is really tedious to review all. Probably feasible, but long.
In reply to Thanks.So, this Midi file by cadiz1
When I have some free cycles, I'll try to reduce the test case to something smaller to still be able to reproduce the problem.
In reply to Can you attach the source by Jojo-Schmitz
Corrected MIDI file (shifted by 1/8 note to the beginning) and the resulting score:
The file loads in the nightly I installed yesterday.
676b0a3