Corruption importing MusicXML file with irregular triplet
Is there a work-around for this? I can go back to an earlier version of the file but will lose a couple of hours of work (no big deal...)
The piece is from a copyrighted file that I scanned (in Sharp Eyes, then imported as Music XML) so I would rather not upload the MuseScore file publicly. Please suggest how to provide the file non-publicly.
Comments
I just looked at the file in Sharp Eyes and it looks correct (and plays correctly). I presume the problem crept in when Sharp Eyes exported to music XML or when MuseScore imported the file. Here's a picture of the way it looks (as correct) in Sharp Eyes (please note the notes in MuseScore are a bit different... two tuplets in measure 53 rather than one tuplet that includes both tuplets) due to my struggles with trying to fix it.)
I also tried exporting from Sharp Eyes as MIDI then opening the MIDI file in MuseScore. There's some bizareness the way the tuplet was handled so maybe that indicates something (came in as a septuplet rather than a tuplet.
Thank you!
I have never used "SharpEyes", but I suspect the problem is with its export to MusicXML. The reason I say this is because I have tested creating a score in MuseScore of that single suspect measure:
![test-tuplet.png]( "test-tuplet.png")
And then I exported that musescore as MusicXML, closed the file, and then imported the MusicXML file, and it displays correctly as it was before I exported. To determine whether this is indeed a fault with "SharpEyes" or MuseScore, I suggest you try opening the exported MusicXML in other programs capable of importing MusicXML (http://www.musicxml.com/software/), and then report back only if you have determined that MuseScore's XML input is at fault.
Regarding midi input, I personally wouldn't advise using midi as a way to transfer scores between programs. Midi does not internally understand triplets, as midi files are just a collection of note on's and note off's at different times on different channels. To help guide musescore in interpreting the triplets in the midi file, you can tweak a bunch of the import settings. However, I tried exporting the suspect measure as midi but was unable to reimport the midi back into musescore...this is the best I could get after disabling detection of all tuplets except triplets and setting max quantization to 16ths:
So it seems MuseScore's midi input might not be able to detect this special case. Maybe your best option at this point is to just manually fix the errors after inporting the XML.
Maybe if you are afraid to post the entire MusicXML export of your copyrighted score, maybe could you delete all measures in "SharpEyes" except for the two measures you have already uploaded here and then only export and upload these two suspect measures as MusicXML
Even if the way it is notated is bizarre, the MuseScore example quoted in the OP is metrically correct: the crochet in the top part of measure 53 belongs half to the first triplet and half to the second triplet, each triplet being made of three quavers and totalling one crochet each.
The notation in #1 and #2 is more correct and less puzzling, but it is metrically equivalent. Is it possible that MuseScore originally proposed this notation and you modified it?
So, there is no real corruption, just an unusual -- and arguable -- notation choice (whether due to the scanning software, to its MXML export, to MuseScore MXML import or to MuseScore 'core', it is still to ascertain).
Anyway, to fix it, it is possible to delete the measure 53 of the top part and re-enter it, using the correct triplets.
I guess I still have a lot to learn about music notation (in terms of my assumption re: metrical correctness.)
MuseScore did report this as corruption upon reloading in the most recent version (perhaps this changed since the previous version).
Your suggestion re: deleting led to a fix, but there still seems to be something a bit odd in the way the program handles this. I'll post some screen captures later that show a perpetuation of incorrect timing (sort of the footprints of corruption, I guess).
Thank you for helping me fix this.
I think what might be lost here is that the *original* report - not what is shown in response #1 - does indeed appear to show a corruption. Measure 54, top staff, first two beats seem to be missing.
If you can get a MusicXML file contianing just those two measures and get it to fail, maybe you could post that?
Good suggestion - thank you Mark.
In Sharp Eyes I reduced the file to just the measures 53 to 55.
Then exported as MusicXML.
53 to 55.xml
Metrically that file seems to read correctly into Mozart
but reads incorrectly into MuseScore.
When I save in MuseScore, close then re-open I get a corrupted file.
"Measure 2 Staff 1 incomplete. Expected: 2/2; Found: 7/8"
53_to_55.mscz
So... per Miwarre's suggestion I can delete then recreate the measures successfully but this does seem to indicate some sort of incorrect handling of what I assume is a valid MusicXML file.
Trying to delete the errant tuplet just makes things worse, since invariably metrically inaccurate rests get inserted instead.
Thanks for your help Eric. Good suggestion.
Thanks for posting the XML file. That helps isolate the problem, and I can reproduce the error.
I notice when I import XML, the console log indicates that the import error is with the function "determineTupletBaseLen":
So apparently it fails when trying to fit a number of counts not divisible by 3 in a triplet.
Yes, thanks, I've changed the title to reflect what seems to be the source of the problem.
The MusicXML file is correct, but apparently MuseScores "end of tuplet" detection fails.
Solution found, will be fixed shortly.
Fixed in branch master, commit ffb20f3167
fix #69566 - corruption importing MusicXML file with irregular triplet
Fixed in branch 2.0.3, commit 934831fdd7
fix #69566 - corruption importing MusicXML file with irregular triplet
Automatically closed -- issue fixed for 2 weeks with no activity.