Unreadable file: days of work lost due to Musescore corrupting my score

• Nov 22, 2018 - 17:00

Hi all,

This is a problem with Musescore that seems to have prevailed for many versions of the software, but it is now the second time I have fallen victim to it. I was working on a score in v2.3.2 on my Windows 10 OS laptop (64 bit) and saving every time I finished a section of work on the score (autosave was also on, set to 2 minutes). However, after I saved the score the last time, I did not exit Musescore and instead left the program running on my laptop overnight. All content was saved at this point. The power cut out at my house and my computer eventually died with the program running. The next time I opened the score, Musescore gave me the classic "Cannot read file" error message, even though it was the correct size (48KB) - I tried to open in Microsoft Word afterwards, and it said the file was corrupt.

When I went into my AppData files, I found an autosaved version with the correct DATE. It was the type with a randomly generated string of letters for a name and 0KB in the file. Obviously that wasn't useful for anything because Musescore couldn't open the file.

When I turned on hidden files, I found a ".mscz," version of my file in the location of the original, now corrupted version. I noticed that the "last edited" date on this file was several weeks before my most recent editing session. After renaming it as instructed in other forum threads, the score did indeed open, but as expected I was missing about 80% of my nearly completed score.

I'm nearly certain that my work is permanently gone, but I thought I'd make a thread anyway if only to raise more awareness about this problem. Musescore developers truly need to fix this bug. I'm sure most people reading this have similar sad stories, but because of this problem I have honestly lost somewhere from 30 to 40 hours of painstaking work as this was quite a detailed and lengthy score. I've attached the original corrupted file below. If anyone has more information about this topic or would like me to provide more information about what led to this on my end, I'd be happy to share.

Best,
Thomas

Attachment Size
Hide and Seek (Imogen Heap) Acapella Arrangement.mscz 47.83 KB

Comments

• Nov 23, 2018 - 05:22

You say you are on Windows 10. If you accepted the defaults when setting up your computer then your Documents folder is probably on OneDrive, meaning it is automatically backed up to the cloud, and older revisions are kept automatically. In which case, all you need to do is log into OneDrive online, browse to that location, and restore the previous revision.

If you elected not to use OneDrive, then I'd certainly recommend moving over to it now. It can be a lifesaver.

Reply

• Nov 24, 2018 - 22:47

Mr. Buonanno has a point. "Someone has to fix this bug..."

For some reason this program crashed (again) when I simply added a note. Not a particularly lengthy piece (202bars) for two (2) instruments, nothing to jar MuseScore's psyche like 12/8 over 4/4 or bracketed rhythms.

It asked if I wanted to "restore previous session." I made sure what returned had the same file name and continued to work. Somehow two identical files showed up with the proper title and extension plus one of those ubiquitous xxx.mscz files. Why? Now I had to pick door number one (one of those with proper title and extension.)
Upon completion I saved the one I completed and listened to it and then went to put it on backups, to include thumbs.

Recap:

I finished it.

I saved it.

I saw it in its completed state.

I listened to it.

I went to back it up.

Poof. 30 bars disappeared.

It went from 57 to 55 KB!. I cannot find the full file on the PC after a search for all .mscz files, nor is it in hidden files.
I have to redo hours work (again)...unless you may have an alternative.

All the bells and whistles mean nothing if one has to repeatedly do work over again. So I would think this constant crashing I've noticed throughout the forum should be addressed by the good folks who put this all together.

My sarcasm is not directed at anyone on board, rather at the proprietor of the black hole my work disappears into.
Poof

Reply

• Nov 25, 2018 - 00:26

As always, in order to fix a bug, we need precise step by step instructions (and usually a sample score) in order to reproduce it.

The crash is a bug to be sure, and if you can show us how to reproduce it, we can start the process of fixing to. If a score ever comes up unopenable, that's a bug too, and again, with steps to reproduce, we can begin trying to fix it.

But having multiple versions of a file around and occasionally finding you've opened a different one than the one you saved - that's not a bug. If you added 30 measures and saved the results, that file is somewhere (unless you saved over it with another version, which I suppose.is possible too). Mostly it's just a matter of you retracing your steps to understand where you saved it. Even here, we are willing to help however we can.

Reply

• Nov 25, 2018 - 02:43

Not for a second did I doubt I'd get help here. I retraced as best as I could. I simply don't know what happened beyond that.
My main point was to express my concern about all the crashes I've witnessed here, many more costly than mine. While I'm sure new versions and builds, etc will continue to make MuseScore even better, the fact remains that constant crashes are extremely frustrating, thereby rendering such improvements as mere frills - a Lamborghini with loose wheels.

Thank you for your attention, Marc and to jm6stringer. (the Virtual Store has empty shelves!)

If you think it will help or prevent a future snafu, I have affixed one of the identically titled scores. It ended abruptly at bar 182 and was to have continued to the final bar, 202. I finished it and made one change to the score properties ( a corrected spelling ), clicked save and that's it.
In the hidden folders is a [.Amaretto.mscz,] with the same date modified and same size, 55 KB (should be 57), but this one won't open.

Attachment Size
Amaretto.mscz 54.84 KB

Reply

• Nov 25, 2018 - 10:26

You wrote:
In the hidden folders is a [.Amaretto.mscz,] with the same date modified and same size, 55 KB (should be 57), but this one won't open.

FWIW: To open that (hidden, backup) file in MuseScore, delete the leading dot and the trailing comma. Also rename it so it doesn't have the exact same name as the real file (which exists in the same folder).

See:
https://musescore.org/en/handbook/file-formats#msczcomma

Reply

• Nov 25, 2018 - 16:43

As I said, when people report crashes and give us enough information, we make it a very high priority to fix them. And in any case, the vast majority of crashes do not actually lead to lost work - the autosave file allows you to continue where you left off with only at most two minutes of lost work.

This only fails in two cases:

1) The cases where, for reasons no one yet understands, the file gets completely clobbered and left full of zeroes. We're not even 100% sure this is related to crash - some people have reported this happening even when there was no crash. This is indeed an extremely serious problem we'd love to fix, but so far, no developer has ever been able to reproduce it.

2) The cases where a user reports he opens a file and sees missing work. I realize you were trying your best to manage your files in a way that would protect you, but there is absolutely no way MuseScore could have done anything to cause this. Opening a file and finding missing work means one thing and one thing only: you didn't open the file you thought you had saved the additional work to. Either you saved the additional work to a different file, or you saved it to this file and then overwrote it with another version. There is no code anywhere in MsueScore or anywhere in Windows that could ever cause saved work to disappear from within a file - software just doesn't work that way.

Since you say there was a crash in this process, my money remains on the likelihood that your most recent file was saved not where you think it was but instead to your Virtual Store, so see the links mentioned elsewhere for information on that.

Reply

• Nov 25, 2018 - 18:06

I see...

There is a certain apprehension when doing a lengthy or involved work, that there will be a crash. Sometimes it was for, say, turning on the synth, another time for a large copy and paste, other times for merely breathing.

Not a complaint, just an observation: I know the auto save works, but...
When it returns post-crash I (I expect others) am not sure how to react.
Restore session? Of course.
Save? A little late, but I click yes.
Then I check the file title. It seems okay. (I now ask myself how I managed to save to a different file when all seemed fine.)

It seems we cannot prevent a crash. Maybe I (we) should be clearer on what to do after a crash. I accept that I likely caused it. That's easy.The problem is I don't know how.

One question: You stated " for reasons no one yet understands, the file gets completely clobbered and left full of zeroes"

After a session I copy the file to another folder. Does this protect the copy? Or should I give the copy a different name? (sonata > sonataBKP )

Thank you.

Reply

• Nov 25, 2018 - 19:11

After a crash, when you say restore session, the restored file is not your original score - it's the last autosave version. If you then hit "save" instead of "save as", the results depend on a lot of factors - which version of MuseScore, what OS, whether you started MsueScore from the program icon or by double-clicking a score in your file browser, etc. So I personally would never want to depend on that. After a crash, I would personally recommend always using "save as", making sure the folder chosen is one I want to use, and giving the recovered score a new name, then continuing to work on that.

When you say you checked the file title after the restore and save, that's half of it. You also need to check the folder it was saved to. My guess, again, if that it saved to a different folder than you expect - if on Windows, and especially if using anything prior to 2.3.2, there's a good chance the score was actually saved to your Virtual Store, which is why we keep asking if you've checked that.

Anyhow, again, if you are positive you saved your file with your most recent work, then MuseScore has done it's job. Now you must do yours and try to figure out where you saved it. First step is to answer the question we keep asking: did you follow the instructions to check your Virtual Store?

To answer your last question: the "clobbering" of a file I am referring to (fillng it with zeroes) is something MuseScore is apparently doing. A file is "protected" against clobbering in this sense if you never save to that file using MuseScore. So if you make a copy of a file, then that copy is protected until you open that score, work on it, and hit Save, at which point it is just as vulnerable as any other file, which is to say there is around a 0.000000001% chance of it getting clobbered (I have been a heavy MsueSore user for eight years, creating literally thousands of scores, and have never once had this happen, and I think the vast majority of MuseScore would report the same, but indeed, there have been a handful of reports among the many millions upon millions of scores created by MuseScore over the years).

Reply

• Nov 25, 2018 - 21:14

@Marc, Mike, jm6stringer

I use 2.3.2 Windows 10 and always use the same folder for current work. I always save it there.

Now I see that after a crash I take what returned, give it a new name and then "save as" to the folder. That's clear.
The backup will be in a folder untouched by MuseScore.

I re-worked the missing 2KB and now have a full 57KB version on thumbs, thereby protecting it from the jolly cybergnomes. (I think)

Thank you for your clarity and patience. There is much to absorb here...it's fine.

Reply

• Nov 29, 2018 - 13:51

@Marc Sabatella

I thought you might appreciate an FYI to add to your own experience base and check my homework at the same time:

Another score crashed, in the 350th bar, for eight instruments. (It seems crashes are more prevalent as the size of scores increase, as I noticed Muse responds more sluggishly as one progresses.

I went to my Muse folder to find score, say TITLE.mscz. There it was. It returned with 63 KB, not 65. I did as you said: I renamed it and "saved AS" with a new name (TITLE1)
I went to the folder and there was suddenly a TITLE.mscz with the full 65 KB as it was where I left off. (where did it come from? 'twas not there before.)
I then renamed IT and saved AS TITLE2, which is the one I am going to continue working on. (IS that correct?)

2.3.2 windows 10

Reply

• Nov 29, 2018 - 21:59

Definitely larger scores are more likely to crash. As always, if you can reproduce this, please start a new thread, attach score & steps. That said:

I personally have never ever had a problem with an unreadable score, I don't do any of the things you describe, nor do I recommend any specific alternate workflow. If it pleases you to make copies, by all means, do so,whether by copying the files or by using save as. but whatever the scheme, make sure you completely understand it so you don't end up confusing yourself and end up opening the wrong version of a file. That's got to be what happened here. Again, there is absolutely no possible way MuseScore magically changed your file size. Somehow, you didn't save in or copy to the folder you thought you did, were looking in the wrong folder for it later, or something like that.

So, do you really have one folder on your system called "Muse"? That's not the default, it would normally be MuseScore/Scores, underneath your Documents folder. So, what is the exact pathname of the folder you are talking about? Are you always making your copies in that same folder when making copies? Are you verifying you are always saving to that same folder when using Save As?

Probably when you figure out what you are doing wrong now, you'll be one step closer to figuring out what you did before as well...

Reply

• Nov 30, 2018 - 00:34

Thank you, Marc

To clarify.

My folder is MuseScore2. In Documents. There is another folder in Documents for copies untouched by MuseScore app. Completed work goes on thumbs.

I did not make it clear. There was no error. Everything remained readable. It simply crashed and disappeared as I clicked on N (note input). So... I went to MuseScore2 folder and found file Greetings.mscz. (63KB) and (re-)opened it. It opened in the app. So, as you've (and others) suggested in previous post, I renamed it Greetings1 and SAVED AS to MuseScore2 folder.

When I looked into the folder I saw another Greetings (original name) now with 65KB. I did nothing to prompt that. It was not there earlier.

Now...because the surprise file had all 65 KB I wrote (nothing lost) I renamed it as well: Greetings2, SAVED AS to MuseScore2 and continued to work on it, now almost completed.

I know what I did wrong in previous occurrences: I kept working on what turned out to be a different version. Okay. But this occurrence, of the original FULL version just popping back into the file, unprompted , is new...and I thought you'd like to know.

Reply

• Nov 30, 2018 - 06:40

Again, there is quite simply no way what you are describing could possibly be happening, so somehow you must be missing some detail. If you had a file called Greetings.mscz and it was 63KB, then you opened it, did a Save as to call it Greetings1.mscz in that same folder, there is absolutely no way the original Greetings.mscz could magically change in any way. Maybe you accidentally hit save first before save as? But I'm also confused, you say the file wasn't there, and yet you also say you opened it? So of course the file was there, it just had a different size? Or maybe you are confusing the backup file - name starting with period and ending with comma - with the real file? That would indeed appear only upon first saving the file. There's no real reason it would be bigger than the original unless you worked on it first, though.

Reply

• Nov 30, 2018 - 14:01

I've given this serious consideration. Decades ago I used to troubleshoot military radar, back when transistors were new and vacuum tubes were still overheating. (yes, I'm that old, er...seasoned). I respect that the more complicated a system, the more it is likely to hiccup. Trust that I am also painfully aware of my own infallabilty.

My hiccup theory:

When you put something in a folder, it is often not entered in alphabetical order. When the folder is re-opened, that file will be in its alphabetical order. Is it possible that after the crash it was sent to the folder and sat on the bottom of the long list, therefore out of sight when I entered the folder?

Remember, after the crash, MS asked if I wanted to save (or discard). I clicked save and went to the folder. I saw the 63KB version and opened it, then I SAVED AS with a new name (greetings1) and put it back in the folder. That is when I saw the 65KB version. Maybe MS put it in the folder after the crash (when I clicked save) but I did not see it because it was on the bottom of the list out of view only to return to alphabetical order after I re-opened the folder.

Let me say my purpose here is not trying to prove a point or gratuitously condemn something I do not understand. With all the help I've received here and work I have been able to get done I feel I should help in any way, which includes reporting what I suspect are anomalies. To be sure, during an anxious moment I may have mis-recalled a step.

Reply

• Nov 30, 2018 - 18:08

No doubt, files showing up at the end of the list at first is an easy way to miss something and could explain a lot. However, it still doesn't quite make sense. If I read what you are writing literally, there was a file called Greetings.mscz, 63K, at one point. Then you say there is now a new file that wasn't there before, same name, 65K. But you can't have two files of the same name in the same folder. This is one reason I can say what you are describing is flat out impossible. It's within the realm of possibility that the 63K file simply got bigger (although againkt here is no code in MuseScore itself to do this, that would be a gliotch in your operating causing it. But there is no way you have two files both called Greeting.mscz in that same folder.

My best guess is this second file was actually the backup, as I said - not in fact the same name, but with a period at the beginning and comma at the end. This much would be normal. I'd expect it to be the same size as the file you just opened though, and have the same content. What is possible, though, is that you left out one detail: when you opened Grettings.mscz, MuseScore may have asked if you wanted to restore your previous sessions, and you may have said yes? That would result in MuseScore giving you the autosaved version, which could indeed have additional info in it. And if that is what you in fact saved as Greetings1.mscz, then everything else you say falls into place.

Reply

• Nov 25, 2018 - 03:26

Could you please interrogate the proprietor of the black hole in you computer so we can figure out what is causing files to lose data? 😁

I suppose that won't happen. The bug reported by the OP is a known bug that has been driving people crazy for a decade. If anyone could put their finger on the cause, I suspect fixing it would be the number one priority. Until then, we can only hope the bug is accidentally fixed in version 3 or someone can help reproduce the bug. I've talked to several people about what they were doing, but I haven't been able to reproduce the bug in spite of trying.😒

Reply

• Nov 25, 2018 - 15:23

I see...quite a problem. I guess my precautions are futile, such as constantly saving, and after each session listening to the entire piece to make sure it's all there and then copying to another folder.

There is one thing: after I listened to it I noticed that I misspelled my own name - I went back in File/Score properties to capitalize the R and then clicked save. I checked the R was capped and then I went to make copies only to notice 57 KB became 55.

The irony is this was supposed to be a fun piece which I never cared to publish. Assuming this goes on at Finale and Sibelius, I take comfort in not paying for the aggravation. :-)

Reply

• Nov 30, 2018 - 21:03

I might have a number of workarounds.

First, the .name.mscz,v hidden backup file is created from the original score the first time you save a modified score. It is then never updated again… until you close the score and reopen it. ⇒ Cheap way for one-generation backups once in a while.

Second, save often and then copy the score away or, much better, put it under version control (e.g. with CVS) or into a git repository.

Third… version control and git work much better with plaintext files anyway, so you’d want to be saving as .mscx not the default .mscz. The developers don’t like me for saying this, as it’s supposed to be a debugging format only (you’ll lose any embedded images that way, too), but it’s plaintext XML, easily displayed, checked, etc.

Furthermore, this sounds very much like a bug in the saving of the PKZIP archive container that the .mscz file format is, so by saving as .mscx it is extremely likely you’ll just avoid the (buggy? probably some kind of race condition.) code.

Also, don’t leave musescore running when you leave the computer for a while. At the very least, close the score (see above), but perhaps also exit the application (that makes memory leaks and spurious corruption less likely).

Another issue might be the operating system. Saving a file often involves saving to a new file then moving the contents into place. Operating systems (all of them, Windows®, the Macintosh OSes, Linux) and the filesystems they use often cheat with that, so that a crash or power interruption will lead to similarily corrupted files. This didn’t happen for you, but the suggested fixes are much the same, mostly: put it into version control (which will automatically copy the contents away into the repository).

Perhaps Marc could do a café about putting scores into a local git repository. It also makes synchronisation much easier: I push the git repo from my desktop to a server I have access to, then pull from there on the laptop, so I can continue where I left off, and have all scores. I can even work on the same score on two systems (with caveats such as slur renumbering, so if you don’t know XML and manual merging, stay off that) and have advanced undo (since I archive a lot of intermediate versions, I can revert to all of them, looking for when I introduced a mistake). And saving into MSCX and looking through the diffs is a form of enlightenment.

Reply

• Dec 1, 2018 - 00:07

Actually, I have no issue with using MSCX the way you describe, and in fact, improvements were made to the format over the summer specifically to make it more "diffable" (see View / Score Comparison Tool for a good use of this). We don't want people depending on details of the format, but it's fine to save and archive it that way. Do keep in mind that it won't save a thumbnail, though, and thus browsing your scores can get slower. And I'm sure you're right that saving as MSCX would eliminate most chances of hitting that zero-filled file bug.

Interesting idea to do a "cafe" session on using version control. I don't do this myself but might just give it a shot!

Reply

• Dec 1, 2018 - 00:18

The only thing slow with MSCX is the damn File Open dialogue, which insists on creating a thumbnail, even if I double-click the file so the dialogue should immediately close.

To add insult to injury, there’s no preference to turn off the thumbnail display.

Even more insulting is that the forced, unwanted, thumbnail display makes the rest of the dialogue so small that my wonderful, describing, score filenames (see http://www.mirbsd.org/music/free/ for examples) don’t fit (on my 1024x768 laptop screen).

Perhaps I ought to file a bugreport about this…

If you do a Café session about it, I suggest having worked with it yourself for 2–3 weeks beforehand. Things can be a bit tricky at times, other than the “local repo (just git init .), never sync anywhere, and just commit stuff” basics. It’s better to be familiar with what one is explaining ☻ (I admit, I do this all the time, but I’d need prep time to structure things before explaining it, too.)

Reply

• Dec 1, 2018 - 00:41

@mirabilos

The position of your kind post suggests it was a reply to me. Let me say at the outset that I appreciate it, but it would be unfair of me to pretend I understood more than two sentences. I understand English, some Italian and enough Russian and German to find the nearest restaurant. I do not understand FILESPEAK or any of this about extensions, formats, etc. Not yet, anyway.

To me CVS = pharmacy.

"Git" = "get" south of Dixie.

As for what I did understand, the suggestion to "save often" is noted. I always do, and save to another folder as well. Another member has suggested a different format to save as well.

You've mentioned not to keep MuseScore running. I often wondered about that. I always close the file when I leave the PC and exit when through, lest Fate provides a power failure at a critical juncture.

I will refer to your thoughtful post at a time I become more tech savvy.

Please excuse my candor...it helps prevent my head from exploding when I am confronted by all these terms...

...and accept my thanks.

joe

Reply

• Nov 26, 2018 - 02:27

@Jm6stringer
Yes, when I checked the virtual store I found several very old Musescore files from about a year ago, but nothing from this particular score that I've lost work on. I'm not quite sure why that is the case. I'm beginning to think that I've been subject to the 1 in millions statistic mentioned above in terms of having a "clobbered" file. But again this is not the first time this disappearing act has happened to me so I also am open to the possiblity that I'm screwing something up on my end. Are there any other locations in may have been temporarily stored?

Also, @pennevodka make sure you've checked all the users' Virtual Stores - my laptop came with a public user, a user named after the manufacturer (ASUS) and then a third, personal user. The personal one was the only one with anything in Virtual Store. Don't know if that helps, but give it a shot.

Reply

• Nov 26, 2018 - 13:08

@Thomas.Buonanno

Thanks. It turns out I only lost 30 measures and re-wrote them. The last time it was over 200 and I've been apprehensive ever since. Reading your post increased my apprehension. (Awful.) Then mine occurred.

There are 2 Virtual Stores here one in empty the other, interestingly enough, contains a config to one of my planetariums, which only increased my suspicion that Musey found a black hole in that cyber universe.

By coincidence last night I stumbled upon a you-tube presentation on TV. One guy did a lengthy screed on what's wrong with Sibelius. I agreed that the set-up is nearly incomprehensible as compared to ours and in many ways not very intuitive.But one thing I noticed was that Sibelius also has files which cannot open, etc. I say this in case you thought about jumping. Over there you pay for the headache.

It seems it is software in general which befuddles even the most experienced users.

Good luck.

Reply

• Nov 30, 2018 - 14:56

Having suffered similar issues, I found a good work practice for reducing work effort loss is to export incrementally the work as an XML file, and I also check with the OS file browser the time date and size information as I save. At least that way you know you have done all you can to reduce the issue. I've never experienced failure to save on a small arrangement :)

Reply

Do you still have an unanswered question? Please log in first to post your question.