V3 file extension should not be the same as V2

• Jan 29, 2019 - 20:09

V3 files are not compatible with V2, and therefore should have been assigned a new file extension.
It is expected that finished V2 scores with complex layout are not "reworked" in V3 but kept in V2 and that people keep V2 available on their computer because reading these files with V3 respecting the V2 layout is impossible (or requires possibly long rework of the file).
The choice to not implement V2 layout in V3 to keep the code manageable and maintainable makes sense (even if end users would have preferred otherwise).
But asking to use different folders and to remember which ones contain V2 scores and which ones contain V3 scores is a pity.


In reply to by frfancha

MuseScore 3 can open files from 2 and 1.
MuseScore 1 cannot open files from 2 or 3
MuseScore 2 can open files from 1 but not from 3.
Opening 1 files in 2 also requires redoing the layout.

1, 2 and 3 can be installed and running on the same computer, for exactly that reason.

In reply to by frfancha

Au contraire...
If you installed them in the 'natural' order, 1,3, 2.3.2, 3.0.2, the last one registers for opening mscz/mscx and can open them.
If you want to open a score with 2.3.2, either starte that ans use file open or use right-click > Open with.
My modus operandi since 9 years, for 1.x and 2.x, and now also for 3.x.

Changing extensions for 3.0 is not going to happen and way to late anyway. Just get over it, that bird has flown.

Who know, maybe 4.0 might change this, but I really doubt it.

In reply to by Jojo-Schmitz

<< If you want to open a score with 2.3.2, either starte that ans use file open or use right-click > Open with. >>
Which makes the recommendation to keep finished complex scores in V2 cumbersome.
Even more if you have to remember which one is V2 and which one is V3.
<< Changing extensions for 3.0 is not going to happen and way to late anyway >>
Could be done in 3.0.3 without problem.

In reply to by frfancha

And introduce an incompatibility inside the 3.x stream? Won't happen.

I still maintain some 400 1.x scores, which I can't (!) migrate to 2.x or 3.x)
I still use 1.x/2.x for small corrections to 1.x/2.x scores, like correcting a typo or athe odd wrong pict or layout glitch
I do create new scores with 3.x and I migrate older scores to 3.x if and when larger changes are due

Does one or more of the major OS vendors recommending changing file formats for this? I don't recall this being the norm for the many times other programs made similar changes to their file formats.

Using different folders is the default, so it's not really asking anything we aren't giving for free...

In reply to by Marc Sabatella

<< Does one or more of the major OS vendors recommending changing file formats for this? >>
Of course they do.
When file format was changed in a incompatible way in Office 2007, xls => xlsx, doc => docx ....
And the change was less important than MuseScore: Office 2007 can open xls/doc without needing to relayout your document, and Office 2007 can save doc/xls to allow older version to read it.
Here the gap between MuseScore2 and MuseScore3 is much bigger: you can't open V2 in V3 without relayout work, and you can't open V3 in V2 at all (I know MusicXML but if you go that way MuseScore is compatible with Sibelius).
Relying on folder doesn't sound like the smart advices you usually give, when you share a file would say: "Oh by the way look at the folder from which I have copied to know which version it is? All the ones in the Mozart Folder are V3 now, but the ones from the folder Bach are still V2 except the fugas which were already done...
And what about people having different folders with scores (which is natural), some of them already converted, other ones not? Are forced to duplicate the full folders tree to split V2 and V3?
For new users not having contact with other MuseScore users to share files it isn't a problem, but for all users having a important number of V2 files that is unmanageable.
I hear that the behaviour from V1 to V2 was the same, but repeating errors is not mandatory for MuseScore (I hope) and the number of MuseScore users and the number of carefully done V2 scores incompatible with V3 is much more important now than 4 years ago.

In reply to by Jojo-Schmitz

Forcing users to install many versions of a software just to be "compatible" isn't a good practice:

  • It forces users to spend more storage space to keep two, three or more versions of the same software;
  • It forces users to keep installed unsupported versions which may have security flaws;
  • It forces users to guess by divination which file was made with which version of the software (no, keeping subfolders with version numbers isn't acceptable as it forces users to go back and forth trying to find that score, and the file can be moved by mistake from one folder to another);
  • It forces users to rename scores to add the software version numbers, a bad practice because it's so easy for the user to write or overwrite the wrong version number, when the software can save automatically the correct version number on the file extension, which by default isn't selected to rename on good file managers (Windows File Explorer even hides by default the file extension to avoid the user renaming by mistake, and even when configured to show the extensions it doesn't select the extension when renaming a file). Also, an user receiving the file could think "v3" on the file name was meant to be it was the third revision of the score, not the MuseScore version needed to open it correctly.

Having one file extension for every version of the layout engine of the software is good because:

  • The installer can be made to not takeover the file extension if another version is already installed (as an example, LibreOffice installer on Windows asks the user if s/he wants to register .doc/.docx/.xls/.xlsx/.ppt/.pptx file extensions or not);
  • The software can still open all the earlier versions, even if it will change the layout shown to the user, warn the user the layout will be changed by opening on the newer version, and save the file with the new version extension (MuseScore 3 asks the user if s/he wants to reset positions of all elements, but doesn't warn the user that the layout will be changed even if s/he chooses to not reset the positions);
  • If the user doesn't have the newer version of the software installed, the operating system won't try to open the newer file extension on the older, incompatible, software to throw an error at the users' face, and the user will see before trying to open it that it's a newer file extension which needs a newer version of the software to be opened (when an extension isn't registered on the OS it will be shown a generic icon file or the file extension will be shown to the user) ;
  • Programming a software function to save on a new extension format is a matter of changing the line of code where it adds the file extension to the "File Save As" dialog (and also to the "File Save" routine) to write ".new_file_extension" instead of ".old_file_extension", so the excuse "Microsoft has many developers to do that to Office when they changed from .doc to .docx" is not valid. Check this example in C#:
    SaveFileDialog savefile = new SaveFileDialog();
    // set a default file name
    savefile.FileName = "unknown.mscx_newversion";
    // set filters - this can be done in properties as well
    savefile.Filter = "MuseScore NewVersion files (.mscx_newversion)|.mscz_newversion;

Also, how hard would be to add a program routine to MuseScore to automatically open the "Save As" dialog whenever an old score was opened and the user chooses to use the "File Save"? I can think of a boolean variable "older_version" which would be populated when opening the file and would be read by a "File Check older version" function to call the "Save As" dialog or the "File Save" function whenever the user uses the "File Save" menu option or toolbar icon.

(Sorry, but I can't contribute my developing skills to MuseScore as I am no developer, I am a PowerShell scripter which has some notions of C#, the language PowerShell was based on).

Also, the file extension is just to ease the user life and show a proper icon on the system shell, what MuseScore really uses to identify the files it opens are the so called "magic numbers" inside them, not the file extensions.

In reply to by joaopaulo1511

I think I found all the files on the source code that needs to be changed:

In the first, change the lines that have ".mscz" and ".mscx" could be changed to ".mscz_newversion" and ".mscx_newversion" (of course the lines that refer to the File Open Dialog should just add the new file extension instead of substituting it).

In the second, add lines to make the MSI file register the new extension.

In reply to by frfancha

I'm not sure if .doc was same format in Word 95, 97 and 2007, but .docx is completely different. When Microsoft introduced "x" file format I knew that I had to buy a new version of Office. Now, MuseScore is free and open source software and what most people do is just download new version.
Even if today backward compatibility is not perfect, it may be improved. Sooner or later, users will update, so in my opinion there is no point in introducing new file extension.

In reply to by frfancha

You say "of course" the major vendors recommend this in situations analogous to ours - can you please point me to the relevant link, then?

The situation with Word is very different than ours in many ways, and in any case, just because the Office team chose to do this with Word in a couple of specific situations doesn't mean the Windows team recommends everyone do it in all situations. I am interested in seeing the exact wording of the guidelines.

As for sharing files with others, if I needed to do that, I would say: "this is a MuseScore X file, be sure to treat it accordingly".

In reply to by Marc Sabatella

Microsoft recommends using a file type for a new application here: "https://docs.microsoft.com/en-us/windows/desktop/shell/how-to-register-…". It's worth noting that when a new version changes its behavior (such as its layout engine) in a way it no longer display correctly the file, or even no longer produces files compatibles with older versions of the software, it is a new application.

Also, Microsoft recommends using programmatic identifiers (ProgID) to register side-by-side applications here "https://docs.microsoft.com/en-us/windows/desktop/shell/fa-progids" and here "https://docs.microsoft.com/en-us/windows/desktop/shell/fa-best-practice…". Microsoft even provided as example the ProgIDs for Word.Document.6 and Word.Document.8, and in my machine there is also Word.Document.12 (the version which first registered the .docx extension).

Although I don't recommend using unsupported old versions (because security issues) of a software side-by-side with the new, supported version, using versioned ProgIDs allows for:

1) Retaining all installed versions registered to "Open With" the common file extension;
2) Allowing a user to install the software versions in any order without breaking the rule of making the newest version installed to be the default file extension opener (remember users are prone to errors);
3) Allowing the use of more than one file extension, as each .mscx/.msc2x/.msc3x/.msc4x (for example) would be registered to to its own versioned ProgID for MuseScore, instead of the same ProgID for all MuseScore versions as it has been the case.

Please, please change the file extension to make it easier for the user!

In reply to by joaopaulo1511

It’s too late now, no matter how good the arguments are.

By now, 3.x is stable, and changing anything will artificially break compatibility within an existing stable series with no means for compensation, where no incompatibility exists.

You had until December 2018 to bring forward these arguments. Now, the train has left.

I VERY STRONGLY support frfancha's notion. This has been bugging me since I started working with MS3 (it is my first transition between major versions), but was still trying to find the time to post. (disclaimer - I was part of the alpha/beta cycle and should have raised this then). In my opinion (and it is just an opinion, based on the below), the whole transition from v2 and v3 has been anything but transparent (since this issue has multiple touch points, I try to make a recommendation to fix, where I can. This is just a first attempt in most cases, the jumping off point for discussion):

  • When downloading a v3 file from MuseScore.com you have no way of telling what you are downloading. The link just states MuseScore, Open in MuseScore. Adding the version number could possibly be fixed on the ms.com back-end without changing the file extension, as I assume it determines the version when importing & parsing the file).
  • Before the app upgrade, it could not play V3 scores, and it has no way of knowing if something is a V3 score or not, other than trying and failing. (I did not test this myself, but remember there being issues).
  • When you Save As... a file, the string states "MuseScore File (*.mscz). This string is identical to MS2. Neither the string nor the extension give any indication that what one is saving, will be incompatible with older versions. I just logged #283063 "MuseScore File" string (under File -> Save As...) does not indicate which version you are about to save as.
  • Because you have no way of telling which version of file you are downloading, until you open it in a "too old" version (e.g. MS2 trying to open v3 file), I would suggest adding the version number to the end, e.g. .mscz3 . That should make it the the most recognizable to people still working with extensions, fix issues of mime type and file extension association if you don't install multiple MS versions in the correct sequence.
  • If this cannot be done for MS3, can we please decide and agree that not having an extension is a problem and be earmarked for a V3 to V4 transition? Personally, I don't see why this cannot be changed. We are rapidly releasing newer versions and are assuming users keep up to date on MS3.
  • I always though Guitar Pro having all those different extension versions was strange (.gtp, gp3, gp4, .gp5 ...), but I have to assume they faced exactly the same challenge we are, and I am sure their users thank them (or did not even know what they were not exposed).
  • Having a file that looks like your program should be able to open it, e.g. MS2 looking at a .mscz file, only to be told your program is too old, is just not great user experience.

In reply to by Jojo-Schmitz

State explicitly whether a downloadable .mscz file is MuseScore version 2 or 3 created. Hoping they look at it.

gp3/4/5 may look like a mess to someone who is used to seeing different versions of a program (MS Word) able to save to the same standardised file format (eg. Word 97 – 2003 (.doc)) across multiple generations, but it is an acceptable compromise for a small dev team (Guitar Pro, MuseScore) that would rather spend limited resources implementing new features than implementing backwards compatibility save filters.

For the dev team (who ultimately decide which features go in for the mere fact that they are coding and merging them) to adopt the single extension approach to avoid extension version sprawl is very unfortunate, since it implies that you deny there is any problem.

If you had to deal with this deficiency for years (like any MuseScore stalwart would have), and accept having to organise scores in folders by version number as a solution, not a workaround, you might consider that normal. But the fresh pairs of eyes that have not lived with this issue, see it very differently.

If users are worried, there is a reason.
and It is a bad habit to rush to release the new version and then say: "Too late to fix it now".

Programmers, Developers (and/or software companies) may think: "Let's endure; they'll get used to it automatically after a while", right?
A big "No"!

And yes: GuitarPro's approach is very positive. I have different versions of gp (n) files and I can work without problems.

File extension registration may have a number of difficulties (time, acceptance, generalize, etc.). But it is worth it.
When MuseScore invented the .sf3 file format, no one opposed it.
Well, why not mscz3?

In my humble opinion, while managing his files on a PC one has to pay great attention to ORDER. I have been used to it since eons ago, so I can't see any problem in storing my MuseScore files in different folder ierarchies based on the version of the files. Moreover, one could simply add a note somewhere on the score page, just as a common string of text in a small, non-intrusive font saying "MuseScore X document" (where "X" is the version of the program).

In reply to by Aldo

<< one could simply add a note somewhere on the score page, just as a common string of text in a small, non-intrusive font saying "MuseScore X document" >>
Sorry but this suggestion shows that you don't understand the issue.
You just can't open V3 with V2 at all, and opening a V2 with V3 will pop up a dialog box (reset yes/no), if you reset you get an acceptable score but changed compared to V2 and requiring some fine tuning, and if you don't reset you get a mess. So your notice in the score is completely useless, one way you just wouldn't see it at all by not being able to open the score, and the other way you already pretty well know that this score was still V2 by the reset process.
And, to be clear:
=> this issue is NOT that you can't open V3 with V2 or that you can't open V2 with V3 keeping the same layout, I understand the reasons behind that
=> the issue is about the fact that running V3 next to V2 on the same system, which is necessary due to the previous choices for people having large collection of complex V2 scores ad is recommended by the MuseScore gurus here, is much more complex than it needs to be by sharing the same file extension.
A) Scores are already organized by folders and forcing people to maintain a parallel structure for V3 and for V2 is poor, I want all my scores "Musique Piémontaise" in the same folder not some under V2 and other ones under V3
B) Double click score to open it in the correct version will only work for one of the version (at OS level you have to chose to associate the extension with V2 or V3), so for the "other" version you must open from the software or right click and select "open with", very poor experience.

In reply to by frfancha

What about the following solution:
provide a filter in a new version of V2 that allows to import V3-files while ignoring the new items that have been introduced with V3.
I think, this is not a big deal and would make everybody happy.
By the way: MS office did something similar by providing some sort of filter-plugin that allows older versions to lead newer version file formats.

In reply to by Bacchushlg

It wouldnt make anybody happy and doesn't answer the issue here being managing collection of V2 files and V3 files on the same system.
Plus, the layout engine being completely different between V2 and V3 makes your proposition undoable.
Finally if you really want to send score content from V3 to V2 you can do it by musicxml.

In reply to by frfancha

Sorry, but I don't agree: If a new version of V2 could read V3 files, I could open every file with this V2-version (which still supports all available plug-ins, for example).

But of course: the dev. effort for doing this must be acceptable. If layouts are really so completely different as you describe, then the only way is: musicxml.

In reply to by frfancha

I hope that some critical issues, e.g. security-relevant, would still receive attention.

I’d just patch them in the Debian package locally else… at least in distributions, software is typically maintained for longer, and I expect to be “maintaining” MuseScore 2.3.2 in Debian for another 2–5 years (with LTS now), although the scope is limited by stable update policy (i.e. security and critical bugfixes only). Collaboration on those, when necessary, will be welcome.

(This is because the next Debian stable is about to be released. I’ve updated the Debian musescore packaging with smaller patches from time to time before that, even going so far as to add new features. That being said, since musescore.com won’t ever see these new features for 2.x scores, you won’t have much luck with them except locally. Nothing incompatible, though.)

As for the file format… it’s waaaaaaaaaaaay too late to change it now anyway, and I’d prefer to avoid the gtp mess as well. I currently determine the format of a file by running xmlstarlet sel -T -t -m /museScore -v @version -n with the mscx file on stdin, then see whether the resulting string begins with 2. (MuseScore 2.x), 3. (MuseScore 3.x) or anything else (not prepared to handle it), but unfortunately, nobody wants to commit themselves to specifying at least parts of MSCX so I’m prepared to change/update my detection algorithm at any time. (The xmlstarlet command basically reads the “version” attribute from the (outer-most) “museScore” XML tag and prints it. Used to be regex, but one doesn’t parse XML with regex, period.)

In reply to by Aldo

"simply add a note somewhere on the score page, just as a common string of text in a small, non-intrusive font saying "MuseScore X document" (where "X" is the version of the program)."

That is what a file extension is there for, where you can see on face value which versions of a program will be able to open it. What purpose would the text / note you described serve, if you need to be able to open the file to read the note? If you got that far (opening the file), it is pretty safe to assume that the file is compatible with the version it was opened in.

I (as I suspect many others) use folders to organise files by something other than version number. In my case I have a folder per song/piece, with .mscz, PDF parts, midi, notes etc.. The only acceptable workaround I could come up with (that works for me), is putting the version number in the file name, e.g.
song.mscz for MSv2
song_v3.mscz for MSv3
This avoids the notes, the folders, having to tell someone that what I am sending them is a MSv3 file.

I Do believe it can be quite confusing, since (on Windows at least, and I guess it's the same almost everywhere), same formats are automatically opened by the same softwares, but I don't think it is a good enough reason to create a .ms3x or whatever file format.
However one thing I would add is an "open in Musescore 2" button in the message box appearing when you open a musescore 2 file. The one saying something like "your file will be relayouted".

In reply to by ecstrema

@Marr11317 Nice try, but that would require that MuseScore3 was able to detect if MuseScore2 is installed on your system and where (which is just impossible for portable version), without even mentioning that the "system" could also be another computer sharing the family NAS.

As @mirabilos said, its way too late for this now that MuseScore 3 has been released, and I'm not sure I would support it even if MuseScore 3 hadn't been released because while some programs do this, the vast majority do not.

However, what I would consider supporting is for development builds to use a different file extension to stable releases. This would make it easier for people to test development builds without fear of accidentally overwriting their main scores potentially making them unreadable by the stable release.

I don't expect the problem will be as severe in future, because future releases will undergo more testing and be more stable from day 1, hopefully to the point that there will not be the same need to support two versions at the same time.

MuseScore 3 was probably the last version to be released according to the waterfall model of software development. Starting from 3.0.1 we switched to an iterative model, which will result in issues being identified sooner and fixed faster. This should mean that the transition from MuseScore 3 to 4 will be a lot smoother than 2 to 3, so hopefully there will not be the same need for multiple versions to be in use simultaneously.

In the meantime, as suggested by various people above, you can make the transition from 2 to 3 easier by:

  • On your machine...
    • Keep scores for MuseScore 2 and 3 in separate folders (MuseScore does this by default).
  • When sharing with others...
    • Add "v2" or "v3" to the filename.
  • When publishing on MuseScore.com...
    • Mention the version in the score description (and comment here if you think the website should do this by default).

In reply to by shoogle


"its way too late for this now that MuseScore 3 has been released"
=> no it is not. MuseScore could perfectly save by default with a new extension starting from 3.0.4 e.g.

"the transition from MuseScore 3 to 4 will be a lot smoother than 2 to 3, so hopefully there will not be the same need for multiple versions to be in use simultaneously"
=> Perfect. So that means that introducing a new file extension now will be a one time operation and not the first step in a long series, so no 'GP mess' (as someone has called it) will be created

"Add "v2" or "v3" to the filename."
=> That's indeed necessary, and the ultimate proof that a different file extension IS necessary, having to ask users to "implement" it by themselves changing file name is [/censored]

In reply to by shoogle

And such a major change in a patchlevel version is against all rules of software development.

I’ve had a peek at files from other notation software, and all I looked at use the same file extension, and when you use newer features, you can’t use them with the older version. That’s normal.

In reply to by mirabilos

"I’ve had a peek at files from other notation software, and all I looked at use the same file extension, and when you use newer features, you can’t use them with the older version. That’s normal."

This comparison completely misses the main point: in these "other" notation software, opening a previous version file with a newer version preserves your layout and therefore keeping several versions of the software active on your computer is not necessary, and therefore, indeed, in these "other" notation software using a different file extension is not necessary. But it is for MuseScore V2/V3, and hopefully for the last time.

In reply to by frfancha

Just curious - have you actually tried opening a score created in, say, Finale 3.1 using each successive new version of Finale up until the change to MUSX in 2014 - did the layout really remain unchanged all these years? And opening a Finale 2014 today - no changes whatsoever? How about Sibelius when it implemented magnetic layout? Some real data would help the case here.

Certainly I've used any number of photo editing programs ("RAW" processing) in which opening the same photo in different versions would produce different results, in fact that's more the rule than the exception. So again, to me, this is perfectly normal and expect that it will happen from time to time, without the enormous nuisance of a change in file extension.

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