1. Overview
Music notation editor with a documented project archive and export to MusicXML.
Category: Media & Creative.
2. Version and scope assessed
Version assessed: Source commit 4676f83f368f1afc9cad6815eb5401a2ec8aca2b; historical MSCZ archive readability and save/backup conditions.
3. Overall determination
Computing determination
4. Principle profile
| Order | Principle | Finding |
|---|---|---|
| I | Sovereignty | Not assessed |
| II | Longevity | Not assessed |
| III | Locality | ✓ Meets |
| IV | Transparency and Control | Not assessed |
5. Fundamental requirements
| Requirement | Status |
|---|---|
| E1 Independent access to essential information | ✓ Pass |
| E2 Practicable exit and migration | ? Not Verified |
| E3 Independent interpretation and recovery | ? Not Verified |
| E4 Continuing authority and custody over already-created work | ✓ Pass |
| E5 Governability of consequential actions | ? Not Verified |
6. Evidence and verification
- E1: The published Amazing_grace.mscz opened as ZIP with three members: container XML, a PNG thumbnail and score XML. The score identifies MuseScore 2.0.2 and format 2.06; standard XML parsing found four Part elements, 68 Measure elements, 175 Note elements and 118 Lyrics elements, including readable syllables. These are element counts, not a count of unique musical bars. No layout or playback was reproduced. (source), confidence high
- E2: MusicXML, MIDI, and PDF provide practical migration and publication paths, though not all notation semantics survive every format. (source), confidence high
- E3: MSCX is a readable XML representation, but complete independent reconstruction of layout, playback, and plugins was not tested. (source), confidence medium
- E4: Score creation and storage can be local without a hosted account. (source), confidence medium
- E5: The inspected save path writes through a _saving path and conditionally creates a backup before replacing the target. Backup creation requires both the caller's request and the user's setting; the backup helper only handles an existing MSCZ target. Not every save can therefore be assumed to retain an old copy. This identifies implementation conditions, not crash durability or the settings of a user's installation. (source), confidence medium
- sovereignty: A positive Sovereignty finding requires established E1, E2 and E4 in the declared scope. The existing access/exit/custody record for MuseScore Studio does not establish all three minimums. The prior positive finding is withdrawn; recorded storage and portability strengths remain facts, not a verified failure. (source), confidence medium
- longevity: E3 is not established for MuseScore Studio's existing essential-record scope. The previous Longevity finding is replaced by Not assessed, not a verified failure or a positive placeholder. (source), confidence medium
- locality: The core score workflow is local and account-independent. (source), confidence medium
- transparency: The positive control observations above do not yet establish whole-scope E5. The methodology requires that minimum before a positive Transparency and Control finding; the previous positive finding is therefore withdrawn to Not assessed, not changed to Does not meet. (source), confidence medium
- E3: The retained MSCZ is a MuseScore 2.0.2 score with independently readable notes/lyrics and structure. It does not establish current-version musical/engraving/playback equivalence, complete dependency recovery or a MusicXML/native round trip. Historical ZIP/XML readability remains a bounded positive observation. (source), confidence medium
- E5: The save path's backup conditions, autosave guards/error reporting and notation transaction undo/rollback entry points are concrete source controls. Effective save/overwrite settings, transient-copy retention and complete correction across the existing score/export workflow remain unestablished; source entry points are not executed recovery outcomes. (source), confidence medium
- E2: The former E2 Pass does not establish usable migration of the declared score's musical/structural meaning. Reading an older MSCZ and knowing export exists does not compare native and independent interchange representations. (source), confidence medium
- E5: The autosave timer follows the enable/interval configuration. Its save attempt checks for a current project, needAutoSave and canSave, and logs failure; old temporary autosave material can be removed as the active project state changes. This establishes conditions, not effective defaults or successful crash restoration. (source), confidence medium
- E5: Notation undo/redo delegates to the transaction manager; explicit rollback and commit end transactions with different flags and notify state changes. These are inspectable editing-control entry points, not proof that every plugin, save or exported representation can be rolled back. (source), confidence medium
7. Migration and recovery
Native storage format: Project archive (.mscz, a zip of XML), plus MusicXML export.
Synchronization or runtime model: Local desktop application.
Example export or inspection command (not verified against any particular version or data set): unzip -l score.mscz
8. Architectural strengths
Established strengths and their scope are recorded in the evidence and assessment findings on this page.
9. Architectural limitations
- The inspected score fixture was created by MuseScore 2.0.2, not the current application version.
- Backup creation is conditional and limited by the save path; crash-safe recovery was not demonstrated.
- Independent XML reading does not establish equivalent engraving or playback.
10. Assessment findings and remaining work
Assessment update: 23 October 2026
- Resolved: The published Amazing_grace.mscz opened as ZIP with three members: container XML, a PNG thumbnail and score XML. The score identifies MuseScore 2.0.2 and format 2.06; standard XML parsing found four Part elements, 68 Measure elements, 175 Note elements and 118 Lyrics elements, including readable syllables. These are element counts, not a count of unique musical bars. No layout or playback was reproduced. Source.
- Resolved: The inspected save path writes through a _saving path and conditionally creates a backup before replacing the target. Backup creation requires both the caller’s request and the user’s setting; the backup helper only handles an existing MSCZ target. Not every save can therefore be assumed to retain an old copy. This identifies implementation conditions, not crash durability or the settings of a user’s installation. Source.
- Open: Current-version MSCZ and MusicXML/MEI/MIDI round trips with notation/layout comparison; old/new release compatibility, actual interrupted saves and recovery, offline playback and export dependencies. E5 also needs effective autosave/backup settings, overwrite and export boundaries and evidence of usable correction after failed/interrupted save.
Assessment: The checked findings above now inform this application’s evidence and limitations. They resolve the stated questions, not complete recovery, migration or eligibility. Reproduction details and retained inputs are recorded in evidence/third-pass/batch-4/. The overall determination remains Insufficient evidence for the remaining requirements.
Human-readable criteria: Can a creator archive source material and editable state, reopen the project after version changes, and export important work in interoperable formats?
Rating reconciliation: 24 October 2026
E3 and E5 remain Not Verified for the existing declared scope. Longevity and Transparency and Control are Not assessed pending their required minimums. Sovereignty is also Not assessed because the required access/exit/custody minimums are not all established. The prior E2 Pass is withdrawn; its essential-record migration comparison remains incomplete. This is a targeted evidence decision, not a finding that the product fails. Existing E1, E4 and Locality findings were not re-certified.
- Resolved: The autosave timer follows the enable/interval configuration. Its save attempt checks for a current project, needAutoSave and canSave, and logs failure; old temporary autosave material can be removed as the active project state changes. This establishes conditions, not effective defaults or successful crash restoration. Pinned source.
- Resolved: Notation undo/redo delegates to the transaction manager; explicit rollback and commit end transactions with different flags and notify state changes. These are inspectable editing-control entry points, not proof that every plugin, save or exported representation can be rolled back. Pinned source.
Remaining: Current-version MSCZ and MusicXML/MEI/MIDI round trips with notation/layout comparison; old/new release compatibility, actual interrupted saves and recovery, offline playback and export dependencies. E5 also needs effective autosave/backup settings, overwrite and export boundaries and evidence of usable correction after failed/interrupted save.
Next without installing locally: Acquire a current native score plus MusicXML output with expected musical structure/dependencies and comparison results; inspect archives/XML here and reuse externally recorded save/undo/recovery observations for the same version.
The individual decision and provenance are retained in evidence/rating-reconciliation/batch-3/. Overall: Insufficient evidence.
Contribute verification evidence for MuseScore Studio
Have you tested clean-machine restoration, format migration, or failure rollback for MuseScore Studio? We welcome reproducible laboratory logs, synthetic test fixtures, and independent assessments to resolve open findings.
Read the evaluation protocol · Submit verification records on GitHub
Individually reconciled in rating batch 3 on 24 October 2026. E3/E5 remain Not Verified for explicit missing coverage; dependent unsupported findings corrected. 2 further bounded source questions resolved. E1/E4/Locality were not re-certified by this targeted review. The assessment procedure is described in the methodology.