MusicXML: request for more optimal calculation of "divisions"

• Nov 11, 2018 - 17:08
P2 - Medium
S5 - Suggestion

Calculation of "divisions" value is incorrect and poorly reflects what is notated on the score
version used : 2.3.2 build 4592407
anomaly description
a) Expected behavior
When a measure contains complex or irregular tuplets , the "divisions" value in the xml file (path :...part / measure/attributes/divisions) is expected to be the "lowest common multiple" and the backward/forward nodes be used only when this is (absolutely) necessary.
b) Actual Behavior/ observed situation
In the xml file (see attachments) the "divisions" value is inappropriate what leads the engine to Insert superfluous and undesirable backward & forward values ( micro movements) in order to keep the tempo...
Those inelegant values (mathematically speaking) lead the program who would read/parse the xml file to twist itself in knots….after a burden of work….
Alternate calculations (on the example) show that the “divisions” value should be 57 instead of 480 (see attachments)
Demonstration (see also excel sheet in attachment)
With "57 " instead of 480, results will be :
a) the tuplet of 19 notes (32nd) will require 19 * 6 = 114 divisions in 2 beats (i.e an half)
b) the (normal) quarter requires 57 divisions
c) and the two notes in the triplet require respectively 38 & 19 divisions , by considering that 57= 38 + 19 and 38 = 2*19.
d) backward and forward values are not necessary

1°) first measure of "happy birthay to you " created with musescore V2.3
2°) The xml file obtained by the "export" menu in musescore
3°) pdf with summary of current and expected data


Severity S3 - Major S4 - Minor
Type Performance Functional
Priority P1 - High

Sounds like you are suggesting an issue with MusicXML export specifically? Sounds like you are suggesting MuseScore dynamically adapt its "divisions" value according to the content of the score? Is this what other programs do? Can you also point to the relevant section of the MusicXML? I am no expert but have never seen anything like what I think you are describing, so more info would be helpful.

In reply to by Marc Sabatella

Workaround Yes No

a) Does this issue concerns specifically Musescore export function. ?
No doubt that the routine/algorithm used for writing the content of the xml file is questionable .
But in fact , there is also a major non-conformity in the “play function “ of Musescore. The sounds (let say their duration) produced through the speakers are not compliant/conform with what the listener can read on its computer screen. In the HBD example, the error in duration for the 19/16 Tuplet’s 1st note and the following ones_ is about 1% , precisely 0,811103 milliseconds_ (see calculations in attachment) . For sure whoever is singing the HBD song cannot see ( or ear ? ) this issue, even he/she is not yet completely drunk…
Note : Musescore can read (very well) the HBD Musicxml File previously exported . Therefore , a general comment can be made: what’s the hell !. What is the $)!.”? name of the person who approved the idea for musescore to record a given score simultaneously under 2 different files (an*.mscx and a *.musicxml) which are both xml formatted but with different content …
One must admit that the mscx design seems better . Especially because the concept of tuplet node between “measure and ”note”is adequately managed in the xml tree hierarchy .

b)Does Musescore dynamically adapt its divisions. ?
No, neither dynamically neither in real time. Musicxml documentation explains :” Musical durations are commonly referred to as fractions: whole notes, half notes, quarter notes, and the like. While each musical note could have a fraction associated with it, MusicXML instead follows MIDI by specifying the number of divisions per quarter note at the start of a musical part, and then specifying note durations in terms of these divisions.
MusicXML allows divisions to change in the middle of a part, but most software will probably find it easiest to compute one divisions value per part and put that at the beginning of the first measure. The divisions value of 24 in this example allows for both triplet eighth notes (duration of 8) and regular sixteenth notes (duration of 6).
See :…
Muse score is one of those software who puts the “divisions” value in the first “measure xml node”. It’s clear that the Musiscore engine reads/ analyses the whole score before writing the first line of the musicxml file. This reading allows to search and detect the note (or rest) having the shortest duration in the score.
Note: In my opinion, this way of recording this value in the first measure is obnoxious. If the “divisions” value is related to the whole score (or the part) it should be escalated higher, as an attribute of the “score-part” xml node . (as in the mscx.file)
Note : If we create a score with a bunch of 4/4 measures containing only a bunch of quarters , except for the ultimate note which is a 128th , then the first measure (in *.musicxml file) will contain a “divisions” value of 32 , which is correct (32 = 128/4)
Note: Musiscore calculations are correct in most cases including when measures contain some ordinary triplets. However when a measure contains 2 tuplets (a triplet and an exotic one), as shown in the HBD example, calculations are risky , to not say false.
Note: Only the first measure of the HBD song has been entered in Musescore.(see attachments). Thus , values in the xmlfile are only specific to that measure . The attached MusicXml file is not an extract of a bigger one.

Hi Marc,
Information about “divisions” element in musicxml can be found in :…

Musescore calculates the “divisions” value by searching the shortest note in the score. It writes this information in the first measure in the musicxml file.
This works well in most cases , including when there is ordinary tuplets. However as shown previously, in the HBD sample, the calculations are erroneous when a single measure contains two tuplets : a triplet and an exotic one.
This leads to a difference of about 1 millisecond (0,81111 ms ) in duration in the loudspeakers, for each note of the 19/16 tuplet.
See calculations about current vs expected values in the following attachment.
This is not a major issue but as demonstrated before for the HBD example a simple algorithm can produce an exact “divisions” value . Such a correct value would avoid the score reader to make micro-movements (backward and forward) along the track. Another advantage would be a musicxml file less verbose as the backward/forward nodes would be superfluous.

Title Calculation of "divisions" value is incorrect and poorly reflects what is notated on the score MusicXML: request for more optimal calculation of "divisions"
Priority P1 - High P2 - Medium
Severity S4 - Minor S5 - Suggestion
Status needs info active

OK, sounds like you are in fact suggesting we do a more sophisticated calculation of divisions in MusicXML files. Not sure how likely that is, but I've flagged this appropriately now so it can be looked at.

In reply to by dbegaud

Cause of the issue is that MuseScore's timing is based on 480 ticks per quarter note (which is obviously not divisible by 19 and thus causes rounding errors) and the MusicXML exporter uses the tick values instead of the actual fractional note values. Not entirely trivial to solve.

In reply to by Leon Vinken

And for the record, I do agree this issue results in MusicXML export which is sub optimal and should preferably be fixed. I do consider it a corner case, as I assume the tuplets used to be quite unusual.

Marc, MuseScore indeed dynamically adapt its "divisions" value according to the content of the score. Some other programs do, some don't. I prefer to do it as, IMHO, it tends to make the xml somewhat more readable.

In reply to by Leon Vinken

Hi Leon
You said "MuseScore indeed dynamically adapt its "divisions".;.
IMHO the word "dynamically adapt " is open to misinterpretation .
I'm sure you know that Musescore DO NOT adapt, trough an "on going process" , the divisions value "within the stream" or "in real time".
As the "divisions" is calculated before writing the first line of the xml file. The export function reads the entire score in order to search and detect the shortest note (or rest) duration in the score. Then , the notes (& rests) durations are based on this Lowest Common Multiple.

This way of doing things is cool and should be kept.
Nevertheless , there is some side effects.
This "divisions" value is currently recorded in the first measure when it should be recorded at the score node level in the xml hierarchy.
When we create a score with 3 staffs (one for the voice and 2 for a piano) ,we see that the "process" examine the 3 staffs (for the shortest note) and records the SAME "divisions" value in the first measure of part 1 (the voice ) and in the first measure of part 2 (the piano) . It's why I would suggest to place this "division" value at a score level where it should be logically located . Knowing that the Musicxml schema has no provisions to do that !

In reply to by dbegaud

I appreciate the suggestion, but this requires having the MusicXML specification updated accordingly first. As some MusicXML consumers do schema validation on the file being processed (including e.g. Finale and MuseScore), such a change would lead to an error when importing the file.