corrupted file
I have two copies of the score I'm working on. One that opens and one which crashes musescore when I try to open it. What happened was that I was working on saving every several minutes. The most recent openable copy is bethena-20, and the first un-openable copy is bethena-21.
As I recall what I changed between 20 and 21 was I was adding crescendo markings and dynamic notations, f, mf, mp, etc.
I couldn't open bethena-21 in the nightly build I was using, so I downloaded the most recent build, and I see the same result. When I try to open it, musescore crashes and quits.
I cannot upload the files because they exceed the maximum size. So I'll tried to gzip them and upload them. I got the following message.
The selected file bethena-20.mscx.gz could not be uploaded. Only files with the following extensions are allowed: jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp xml mxl msc mscz mscx mscz, mscx, ts mid midi ly zip eps patch svg ove drm mss cap gp3 gp4 gp5 gpx qml tg.
I have uploaded the files to google drive and here are the URLs.
https://drive.google.com/file/d/0B0_NJI9serd3dEJPcjJobnpxcU0/edit?usp=s…
https://drive.google.com/file/d/0B0_NJI9serd3ZHVJZkhoNl9QU1U/edit?usp=s…
I will now begin again with version bethena-20 and save in smaller increments, to try to identify which operation causes the critical corruption.
Comments
I've noticed something very strange about the bethena-20 file. It seems to be saved with the wrong notes. It looks like it was saved in a state which confuses the concert pitch. The instruments in the score are "auto-transposing" instruments: English horn(F) and oboe d'amore(A).
The previous version bethena-19 seems to have the correct notes saved.
This file can be obtained from https://drive.google.com/file/d/0B0_NJI9serd3Ul9VM2x0cjJJWVU/edit?usp=s…
I don't quite get how a score can have 4 instruments, but 10 parts?
Did you create that score with 25bc366, or just opened it today with it?
It is not to big to attach, if savead as mscz.
bethena-21 seem beyond repair, it doesn't open at all and may crash MuseScore
Looking into it (with a text editor) shows that it got created (or last saved?) with d438623, a version that is 22 days old now.
So this is to be expected and there are enough warnings about than when working with the nightly builds...
Ah, I see now: those instruments are hidden (and muted). Maybe that is even the actual problem, similar to http://musescore.org/en/node/25472?
The crash is almost certainly a duplicate of #23396: Hairpins become corrupt (no end spanner / tick2 == -1), leading to crash. Unfortunately, what we really are steps to reproduce the corruption - I've got no shortage of already-corrupted files already :-(.
The transposition issue might just be an artifact of creating a score in one build and expecting it to work in another. In general, this often works, but with all the transposition work being done over the past couple of weeks, I fully expect to need to throw away all work done during this period, just as the numerous warnings on the nightly builds have always said might be necessary.
If on the other hand this score was created in the latest build, then again, what is needed more than already messed up score is a series of steps to recreate the problem. And in any event, I don't actually see the problem - could you describe in more detail what you perceive to be wrong? Just looking at the first measure of the English horn part, I see a concert key of one sharp, first few notes E D F# E. Turn concert pitch off, and I see a key of two sharps, first few notes B A C# B. Isn't that correct?
As for scores having more parts than instruments, that's perfectly possible. In this case, there are actually a lot of instruments; most are just hidden via the checkboxes in the instrument list. You can also assign an instrument to more than one part. I've considered doing this to allow me to work with just the strings in an orchestra arrangement, etc.
Hi Marc, as for the transposing issue. If you play the piece marked bethena-20 you'll notice that it sounds horrible, all the harmony is wrong. But if you play the one marked bethena-19 you can here the good harmony. Do you see the same notes when you look at bethena-20 an behtena-19?
Hi Marc, you commented about "if the score was created in the latest build", what do you mean by that? Is there a way to create a significantly sized score in a build which is one hour old? Perhaps you know a trick about entering data that I have not figured out yet.
xml ex- and import for example
MusicXML would indeed be one way, yes. but I wouldn't necessarily trust that, either. As far as I know, that code has not yet been updated to use the new TPC mechanism.
Anyhow, I didn't literally mean it had to be the exact same build, of course. It's been a couple of days since the last transposition-related changes, a couple of days before that since any truly "architectural" changes I think. But anything created using a build from before the transposition work started, or during the first few days of that work, is almost certainly going to be throwaway.
So if I understand correctly, the issues isn't that bad things happen when toggling concert pitch - it's that the pitches themselves are wrong in the first place. Probably nothing to be done abut that. You could try transposing manually, but that's broken right now too when it comes to transposing instruments.
Hopefully not too much longer before this is all sorted out, but meanwhile, trying to use development builds for anything but testing purposes is just plain a bad idea when it comes to transposing instruments*, and posting issues involving transposition without clear steps to reproduce from scratch is probably not very productive.
*Officially, of course, using developments builds for anything but testing purposes is a bad idea period. But we all know 2.0 actually works well enough for enough things to make it tempting, and many of us have given in to that temptation. Still, transposing instruments is where I draw the line right now. Plus I am careful about the things involving parts or mmrests that I know to be problems that are already reported in issue tracker, like #23396: Hairpins become corrupt (no end spanner / tick2 == -1), leading to crash and #25253: Multimeasure rests corrupts multi staves instruments.
Hmm, I don't think this is clear yet at all. As far as I can tell the corruption is a duplicate - the crash occurs in exactly the same spot as in the issue I linked to, for exactly the same reason (hairpin with no endSpanner tag). And also as far as I can tell transposition is a non-issue - the observed behavior is the expected result of loading a score created with an incompatible earlier build.
If my understanding is correct, this issue should simply be closed. If not, then more information would be required.
(sorry, inadvertently changed the title, but I'm still thinking this should probably be closed)
I believe this is a duplicate of issue #25481
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.