Audiveris: Open-Source Optical Music Recognition for Scores You Actually Scanned

What Audiveris does that a PDF reader cannot

A scanned score is pixels. A notation program needs symbols: note heads with pitches and durations, beams, slurs, text. The gap between the two is what optical music recognition closes, and Audiveris is an OMR application whose stated goal is to transcribe a score image into its symbolic counterpart so it can be played back, edited, searched or republished. The audience is narrow but real: people working from IMSLP scans, out-of-print editions, or any score that exists only as an image. Audiveris is not a notation editor in the MuseScore sense. It is a recognition tool with an editor attached for fixing what recognition got wrong. The README lists good recognition efficiency on real-world quality scores, support for scores of hundreds of pages, and availability on Windows, Linux and macOS. Those three claims together describe the intended user: someone with a large, imperfect scan and no patience for re-typing it.

Two components, several recognition techniques, one .omr file

The application is built around the tight integration of an OMR engine and an OMR editor. The engine is not a single model. According to the README, it combines ad-hoc methods for lines, image morphological closing for beams, external OCR for texts, template matching for note heads, and a neural network for all other fixed-size shapes. That mix matters when you are debugging output: a missing staff line and a misread accidental fail for different reasons and may need different corrections. The engine writes its music information into XML-based .omr project files, which the README says are fully documented, and the same data is reachable through the Java API. Export to MusicXML 4.0 covers a subset of that data, and the README states that other exporters are expected to build on OMR data later. The practical consequence: .omr is the complete record, MusicXML is a lossy but portable view of it. Keep the .omr file, because re-exporting from it is cheaper than re-running recognition.

Installing Audiveris on Windows, Linux or macOS

Since release 5.5 the project ships an installer per platform with a JRE bundled, so no separate Java installation is needed. The README points to the Assets section at the end of a release on the Audiveris Releases page, with .msi for Windows, .deb for Linux and .dmg for macOS. On Windows, winget and scoop can install the application directly. On Linux, a Flatpak package with a suitable JRE is available from Flathub. The handbook installation section holds the details.

winget install Audiveris

scoop install audiveris

flatpak install flathub org.audiveris.audiveris

For a development build you need git, gradle and a JDK; the README points to the sources page of the handbook for that path, and the repository root contains gradlew and gradlew.bat alongside build.gradle. Once installed, the workflow is: open the score image, preselect processing switches to adapt the engine to this particular score, launch transcription, then fix remaining mistakes by editing symbols. The README is explicit that the switches are chosen before transcription, so a second pass means changing them and re-running rather than nudging a model mid-flight. The bundled JRE is the detail that makes the binary route the low-friction one; the source route is a gradle build against a JDK, which is a different order of effort.

The 100% recognition ratio is not a bug report

The README says it plainly: significant progress has been made, especially on poor-quality scores, but experience tells us that a 100% recognition ratio is simply out of reach in many cases. The editor exists for that reason, not as a bonus feature. If your plan assumes unattended batch conversion of a hundred files with no human pass, Audiveris is the wrong tool, and the project says so before you install it. The correction step is manual editing of a few music symbols, which is fast on a clean page and slow on a dense orchestral score. There is a second boundary worth naming: MusicXML export covers a subset of the OMR data. Anything outside that subset lives in the .omr file and in the Java API, not in the exported MusicXML. If your downstream tool needs a feature outside the subset, the README does not promise it will survive the export. Finally, the README opens with a warning that audiveris.com and audiveris.net, note the .com and .net extensions, have nothing to do with Audiveris and are reported to be high-risk sites flagged as potential scams, with links redirecting to cryptocurrency and sports betting pages. Get the software from the GitHub Releases page or Flathub.

Audiveris against MuseScore and other routes to notation

People search for audiveris vs musescore, and the honest difference is direction of travel. MuseScore is a notation editor: you enter or edit music, and it plays and prints it. Audiveris reads music from an image. They meet at MusicXML, which Audiveris exports and MuseScore can import, so the two are commonly chained rather than compared. If your source is already a digital score in a notation format, you do not need OMR at all. If your source is a PDF of a printed edition, only the recognition step gets you started, and the correction pass happens afterward in whichever editor you prefer. The other route is manual re-entry, which is exact but scales with the number of notes, not the number of pages. Audiveris inverts that: cost is roughly per page plus a correction pass, which is why the README's claim of effective support for large scores, up to hundreds of pages, is the argument that matters. For a single page of dense handwriting, manual entry may still win.

Maintenance, release cadence and the AGPL

Audiveris is licensed AGPL-3.0. That is a strong copyleft licence, and if you plan to run a modified Audiveris as a network service, the obligations differ from permissive licences; read the LICENSE file and take your own advice on it, since this is not legal advice. The repository is not archived, and the last push was on 2026-09-22. Release 5.11.0 is dated 2026-07-11, 5.10.2 is dated 2026-03-27 and 5.10.1 is dated 2026-03-21. The README describes releases as typically every 6 to 12 months, each providing significant improvements, well tested and integrated. Development happens on the development branch; master is used for releases and only for them, and the two are merged when a release is made, per the workflow article. Upgrade cost is low if you use the installers: download the new .msi, .deb or .dmg and replace the old build. It is higher if you build from source, because you track the development branch and rebuild with gradle and a JDK. Nothing in the README describes an automatic update mechanism, so plan on checking the Releases page.

Editorial conclusion

Audiveris fits anyone who needs to convert scanned or PDF scores into MusicXML 4.0 and is willing to correct the output by hand, including large multi-hundred-page scores. It does not fit anyone expecting a one-click, fully accurate transcription: the README states that a 100% recognition ratio is out of reach in many cases. Before adopting it, verify the installer for your platform on the Releases page, and check that your downstream tool reads MusicXML, since that is the only export format the README documents. Note also that the .com and .net domains are flagged as unrelated to the project.

Frequently asked questions

Official sources

1. Audiveris/audiveris on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases