Request a Repair function or utility to fix broken internal score representations
This is NOT a bug report, but I need to give examples of the kinds of problems I've encountered and show that it's tedious, difficult, or sometimes just impossible to otherwise correct them.
I have often found that after many cuts and pastes in a measure, particularly with tweaking sixteenth and eighth notes or triplets to get a rhythm right, the number of beats in that measure became corrupted. That could often be corrected by deleting its notes, combining the rests to change them back to a whole rest, then re-entering the notes. If that doesn’t work, or if a whole rest refuses to go in, it may not even be possible to delete the entire measure, but pasting something else in instead may work. If not, you’re out of luck; can’t be fixed, period. Re-entering the entire score from scratch is out of the question if it's long and complicated.
These many cuts and pastes have also corrupted the play pointer such that stopping and resuming play causes it to jump to an entirely new measure elsewhere in the piece. Of course this becomes infuriating because it’s beyond the user to fix unless caught very early after the edit that caused it. The workaround is to stop playback, scroll back to the desired starting note, reselect it or a neighbor, and press play again. I tried the 1/3/13 nightly build, and it behaves the same as 1.2, indicating that the problem is in the mxcz file, not the playback code.
Also, I’ve copied and pasted in measures from elsewhere in the score only to find that they display correctly, but sometimes one of the notes won’t sound when the measure is played back! The solution is to delete and re-enter the note. Sometimes the pasted notes will show and play properly but one note of a chord won’t change color when selected. Sometimes the note is in the correct place on the staff yet sounds a different note than is displayed.
Request: All the above problems could be corrected by a new MuseScore utility or repair function that would internally scan the mscz file to detect such inconsistencies, and fix them, perhaps asking how to deal with something that’s ambiguous.
I have a score that still contains many of these examples; I can submit it if a developer wants to study these issues.
Comments
It's something I wondered about too. Maybe as a 1.2 plug-in?
About the soundless notes, you maybe encountering the same as me. Try saving, quitting MuseScore and re-opening.
I'm encountering the first and third bugs everyday as well. the second one you mentioned is new to me.
The first bug is truly the most annoying one, usually you must copy anything that comes after the measure and delete it. Never happened to me that the measure could not be deleted. But, I don't think the corrupted measure is noticed during playback, so don't let this bug annoy you unless it's during the time you put notes in the spoken measure.
The third bug really is just annoying... But the solution is simple as u pointed out.
In reply to Hello, by HolyEyE
In my humble opinion, any reproducible issue in the current trunk that causes either a crash or (worse) loss of work should be considered a showstopper for 2.0. We cannot accept these, as they cause real harm to the end user.
I am (right now!) having exactly the same problem. I have a bar with half a beat missing: it's in 3/4, so if you paste a dotted minim (3/4 worth) into the bar, it deletes the first quaver of the _next_ bar. I have been struggling for some time, deleting n bars, reinserting n bars, pasting bits back, and I have still not completely resolved the issue. The *major* problem is that I can't look at anything except the blobs on the page: somewhere underneath there is a logical structure, which I could probably diagnose. As it is, I have no way of knowing which bit I really need to excise to cure the problem.
Sorry, this isn't very specific, except to note that the problem is not unusual. My impression is that there are usually tuplets involved somewhere nearby, and that the way in which tuplets are handled is somehow not very robust. For what it's worth, the initial symptom today when I opened the score I'm working on was a barline replaced by a space, followed by about six barlines about 1sp apart; when I tried clicking and deleting one of these phantom barlines, the six became about 10-12... hmm.
I am using 1.1; can't remember quite why.
In reply to Currupted scores by Imaginatorium
some bug with tuplets had been fixed with 1.2, but there seem to be still some left.
Try 1.2 first. Then try a nightly build, if that loads the score, export as xml and import that in 1.2 to be able to continue working with a stable version
Hi RAngell -
I'm not a developer. (I've never even been over to look at the Development pages.)
I see a couple of difficulties with an analysis and fixup utility for MuseScore files.
For 1.2, there is no new development going on. All the effort is now on 2.0. I believe the developers want to focus their attention on that.
For 2.0, I suspect the format of the MuseScore file is still somewhat undergoing changes. That would make it really difficult to write and maintain a tool like the one you are requesting.
Aside from that, if the developers knew the kinds of things that could go wrong in a score, it would probably make more sense to fix the underlying bug in MuseScore in the first place. :-)
I've "repaired" a total of 2 (two) MuseScore files on these forums (thus far). The scores were crashing MuseScore. My qualifications for this were only being familiar with XML and knowing something about music. My justification was that these scores were totally useless otherwise. Luckily, they were both pretty easy to diagnose and fix.
(In my opinion, directly fiddling with MuseScore XML files by hand is fraught with peril and you are unlikely to get any help or support if you do this, so I don't really recommend it.)
I agree that a repair tool would be a great thing and I add my vote for it. If one of the developers wants to take this on, it would be super! I think it would also be a "labor of love". MuseScore is open source; how are your coding skills? (I ask this only partially in jest.)
Just my opinion...
Fifist
Sally
In reply to Tool by Fifist
Indeed, for 1.2 no new development or even bug fixing is being done. All effort is focused on 2.0. Therefore I would kindly ask everyone who complains about the issues mentioned in this thread, to verify if the issue does or does not reproduce in 2.0. The goal here should be to get a quality 2.0 release. Issues that do occur in 2.0, need reporting and fixing !
And yes, I am a developer.
In reply to Indeed, for 1.2 no new by Leon Vinken
Of course it's important to prevent it happening in the first place :).
However, it was more about fixing the files before they go into 2.0 - I thought a 1.2 plug-in could be developed which runs the file through a problem test and possibly fixes it. I wasn't suggesting a 1.3 release.
Maybe this could be done in addition to a fix in 2.0 of incoming corrupt scores?
I resolved this issue by exporting to MusicXML and re-importing. Some formatting was lost; make sure you have a backup.
In reply to I resolved this issue by by Hello71
In the intervening years since this thread was started, MuseScore 2 was completed and released with the following relevant changes:
1) An automatic corruption check when opening a score
2) Bugs that caused these corruptions were isolated and fixed (though nothing to automatically fix already-corrupt scores created with earlier versions)
3) Optimizations to allow for fixing those corruptions quickly and easily—see How to fix a score that contains corruptions
4) And the playback issue was completely and totally fixed, corruptions or no corruptions.
In reply to In the intervening years by Isaac Weiss
My problem was that there was no rest there to expand, only notes. I didn't think of deleting the notes though; thanks!
Whilst some of this has been implemented, it would be interesting to see one remaining function.
Sometimes I'll get errors when opening a score via Terminal (on Mac) about a zero slur or unmapped drum note.
In reply to Whilst some of this has been… by chen lung
These are debug messages, might be leftovers that should have gotten removed from 'production' code