Automatic Bar/Measure Correction when importing old files

• Feb 16, 2019 - 03:26

Hi, Gang!!!

I wonder if the development team could add an automatic bar/measure correction, when we are importing files from MuseScore old versions and/or MIDI files.

Because some reasons... Sometimes we get the infamous message: "Corrupted file. Measure Nr. xxx is not into expected size".

Why not to fix it automatically, with the nearest value? ???

Just an idea!!!

Blessings and Greetings from Chile!!!



@jotape1960 - nice idea!

I frequently use MusicXML import in order to get a score transferred from Sibelius to MuseScore, and corruption is a frequent problem. Fixing one corrupted measure in a single instrument in a large orchestral score is not easy, and sometimes I have to remove the entire measure for all instruments and then insert the missing measure. That involves a lot of data input in order to repair the gap.

It would certainly be useful if the MusicXML import dialogue had an extra option:
Delete content from all corrupted measures? Yes/No

And of course we should then be able to copy the confirmation message with all the measure numbers + stave numbers of the emptied measures. Re-inputting the notes into the empty measures is much easier than trying to repair corrupted measures.

In reply to by DanielR


When possible, I insert a measure, copy & paste all but the corrupt instrument, then reenter the notes to fix the corruption then delete the offending measure. This usually works and speeds up the fix a corruption problem. You don't have to fix slurs that start before and end after this measure, but you do have to fix the slurs and ties with an end point in the measure.

BTW, I like Juan's idea, you should submit a suggestion at

In reply to by DanielR

I wonder if you can add the automatic inspector to avoid any kind of corruption whatever the process is (create a new score, editing and/or saving an score).

I'm talking about an automatic testing of the measures/bars lenght (size), testing all voices (because this issue is always related with some voice with more or less times per bar).

In reply to by mike320

I'm not a programmer. I wish to know about that!!!

But... Isn't a basic mathematical issue here???

I mean... Let's say we are working on a 4/4 score. Well, we know we only can have, per bar:
1 whole note
2 half notes
4 quarter notes
And so and on...

I think the program just have to add and compare with the possible maximum length of each bar!!! Simple (to say, hi hi hi).

if that future automatic inspector found some bar with an out-of-range rhythm figures... Very simple, folk!!!

The program could change the figures to "put" all of them "inside" the maximum possible value.

That's all!!!

Well, I know it is very easy to think and write. I repeat, I'm not a programmer, so I don't have any clue about the necessary algorithm to get this.

In reply to by jotape1960

Problems mostly arise when you have tuplets like a 6th-let where each note is worth .1666666667 beats, 2 are worth .3333333333, 3 are worth .5 4 are worth .6666667, 5 are worth .83333333 as you can see there are different rounding errors introduced when you take them 1 at a time versus 3 or 6 at a time.

In reply to by mike320

I can figure that, mike320.

But, I guess there should be a way to "fool" the system when we have those tuplets issues.

When I was in college, I learned a 4/4 measure will be able to have just 128 "tics" (spanish word related with the clock ticking sound, I don't know which is the right English word to this).

So, the program has to know that value: 4/4 measure maximum length = 128 tics.

Any summary above or below that value will be... A corrupted bar!!!

If we use tuplets, each tuplets group full length is equal to some major "normal" value figure. And that final "normal" figure can be divided by 2 (avoiding the .3333333333333 values)!!!

So... I guess there should be a way.

You can do it!!! You always can do it, man!!!

In reply to by jotape1960

Tic (tick) is the same word used in the program. A measure is divided into 480 ticks in MuseScore. As you say, there is always a way to work with the rounding issues. There are so many special cases to help with the corruptions issues that they start contradicting one another, so someone came up with the idea of using fractions since in my example, 2/6 is always = 1/3 and there are no issues with rounding. The hope is that this will fix a lot of problems.

In reply to by mike320

mmm... I can not to follow that math...

Yes, 24 * 5 = 120, And 120 * 4 = 480.

But... Why to chose "24" as base number???

It seems "32" is a more "computing world" number, so...

32 * 4 = 128 ticks per beat, and 128 * 4 = 512 ticks per bar.

Whatever... The human limit is around 96 ticks per beat, at 120 quarter notes per minute. (as I read somewhere).

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