From Finale to Dorico: preserving old scores beyond Rosetta 2

I have been following the discussions about Finale, Apple Silicon and the eventual disappearance of Rosetta 2, and I am perhaps a little less worried about it than some others here.

My situation may also be slightly unusual. I have a large archive of Finale files going back to 1991. I no longer use Finale for new work — Dorico is my working notation program — but I do need to retain reliable access to those old Finale files.

The important distinction, at least for me, is that I do not need Finale to remain a complete working environment indefinitely. I do not need playback, audio plug-ins, MIDI hardware, Garritan, or even particularly good performance.

I need Finale to do four things:

  1. open an old Finale document;
  2. display it correctly enough for me to inspect it;
  3. allow the occasional small correction;
  4. export MusicXML.

The resulting MusicXML then goes into Dorico, where I check it carefully.

I deliberately do not batch-convert my Finale archive to MusicXML. There are too many files, and MusicXML conversion is not something I regard as an archival process that can safely be done unattended. Tuplets in particular can produce well-known surprises. My normal procedure is therefore:

Finale file → MusicXML → Dorico → check

and, if necessary:

Finale file → fix the offending tuplet or other detail in Finale → new MusicXML → Dorico → check again.

For the same reason I see little benefit in converting thousands of old .mus files to .musx merely for the sake of doing so. Finale 27.4.1 has so far opened my old files successfully. I would rather preserve the originals unchanged and maintain a reliable way of opening them when required.

At present I am keeping three separate routes available.

1. Finale 27.4.1 for Mac

Finale 27.4.1 itself is a Universal Binary and runs natively on Apple Silicon, so Rosetta 2 disappearing does not directly kill the Mac version of Finale.

Of course, this does not mean it will run on macOS forever. Finale is no longer being developed, while macOS certainly is. At some point an unrelated OS change may break something that nobody is going to fix.

Still, for as long as it works, this is the simplest route.

2. Windows 11 ARM in UTM, with the x64 Windows version of Finale

This already works for me.

One important detail here is that I use Windows 11 ARM, not x64 Windows under full CPU emulation. Windows itself runs natively as ARM64 in UTM, while Windows’ own x64 compatibility layer translates only the Finale x64 code.

Trying to emulate an entire x64 Windows installation in UTM is a completely different proposition. In my experience it is intolerably slow and not really usable even on a very fast Apple Silicon Mac. There is little reason to emulate the whole operating system when Windows 11 ARM can run natively and only the comparatively small amount of x64 application code needs translation.

In some ways I regard this as the strongest long-term archival option. I can keep a complete UTM virtual machine containing Windows, Finale and everything required to open the documents. The VM can then be copied to several drives and stored in several physical locations.

This seems considerably safer to me than buying an elderly Mac and placing it reverently on a shelf.

A years-old computer contains a years-old motherboard, power supply, SSD or hard disk, capacitors, display electronics and so on. Eventually one of them gets a vote.

A virtual machine image, by contrast, can be duplicated perfectly.

So rather than preserving one old computer, I would rather preserve several identical copies of the old computer as data.

For my particular Finale use case the virtual machine does not even have to remain a pleasant general-purpose Windows installation. It only has to boot, launch Finale, open a document and produce MusicXML.

3. Windows Finale under Wine

This currently works too, although on Apple Silicon the conventional Wine route has relied on Rosetta 2.

This is where recent developments are actually rather encouraging.

Apple has stated that normal Rosetta support will continue through macOS 27, while from macOS 28 Rosetta functionality will be restricted to certain legacy games.

But CodeWeavers has already demonstrated a native ARM64 version of CrossOver for macOS using a customised version of FEX to translate x86/x64 Windows code instead of relying on Rosetta 2. Their current ARM64 Mac build is still a preview rather than a finished replacement, but the important point is that the architecture already exists and runs.

So the future Wine path is potentially:

Windows x64 Finale → FEX → ARM64 Wine → macOS ARM64

rather than:

Windows x64 Finale → x64 Wine → Rosetta 2 → macOS ARM64

Wine itself has also been gaining substantial ARM64/ARM64EC infrastructure, so this is not merely a speculative idea about something somebody might perhaps write one day. The transition work is already happening.

Whether Finale works perfectly under the eventual ARM64/FEX Wine stack remains to be tested, of course. But my requirements are rather modest. I am not asking Wine to turn Finale back into my main scoring workstation. If it can open a 1994 score, let me repair one questionable tuplet and export MusicXML, it has done its job.

So I do understand the concern about Rosetta 2 disappearing, but for archival Finale access I do not presently see a catastrophe.

I see three independent layers of insurance:

native Mac Finale while it continues to work;
a frozen Windows 11 ARM/UTM Finale environment;
and potentially ARM64 Wine/FEX as the third route.

The most important thing, in my opinion, is to preserve the original Finale documents and at least one known-good environment capable of reading them.

And if that environment can be stored as five identical VM images in five places rather than as one increasingly vintage Mac in a cupboard, I am quite comfortable with that.

One additional practical advantage of the Wine route is that it is very lightweight.

First, it does not require a Windows licence or a complete Windows installation, and the whole environment takes considerably less disk space than a virtual machine.

Second, Finale itself does not need to remain permanently authorised for this kind of occasional archival use. The installer does need to be kept safely, though: after installation Finale runs for 30 days before requiring authorisation. If the Wine installation is later removed and Finale is installed again from scratch, that 30-day period starts again.

So for a machine whose only purpose is essentially open old Finale file → make a small correction if necessary → export MusicXML → continue in Dorico, Wine is potentially a very compact preservation tool.

The wine that nourishes me can be found here:
https://github.com/Gcenx/macOS_Wine_builds/releases

As you say, Finale 27.4.1 is a Universal Binary; and all accounts suggest it will work fine on OS27 Golden Gate, at least.

There is also “Denigma”, Robert PAtterson’s tool for converting Finale files without needing Finale – which may also provide improved conversion with future formats.

I would strongly recommend that you convert everything to XML as soon as possible. This can be automated, so shouldn’t be too much of a problem. Also PDFs, which will preserve the document in human-readable form.

Otherwise, you’ll be relying on Finale to work – right up until it doesn’t.

Has anyone tried to use Denigma with a Finale file that has a notorious tuplet error in it? Results?
Automatic conversion - I also covered it, why it is not an option.
I am sure that I do need Finale to work. There can be errors in the file that will render generated musicxml useless.

@benwiggy I tested Denigma with Finale file that has a tuplet error in it. The bottom line is: Working Finale remains necessary.

I have used Denigma with so-so results. What I have found is that Finale musx files exported to musicXML files is never really a great option. Yes, I can import them successfully into Dorico (meaning without application errors for the most part) but Finale files sometimes mislabel things (like measure numbers) during the conversion process.

When I use these XML files, I typically find that I need to create a new Dorico file with all the parts (including the proper initial clefs, initial time signature and initial key signature) and then copy and paste the notation from the XML into this new project file. Then I must go about making sure that stem directions are not forced and that no other corrections need to be made. The latter, depending on the length of the work, can be a bit daunting.

With that being said, I would still recommend batch converting all of your files and placing them on some sort of archive device that works for you. Having the XML conversions will give you another, albeit dicey, backup for all of your work.