Guitar pro import creates corrupted file
Open this file
MuseScore complains that the file is corrupted since several measures are not complete.
More examples
http://musescore.org/fr/node/49671#comment-229976
According to this post, 20% of GP imported files are corrupted.
Comments
I just checked some files quickly and it seems to be due to different causes.
- Full measure rests in the first GP3 files are imported as quarter note rest
- Some tuplets are not imported at all and lead to odd measure durations
wouldn't corruption make this critical?
And crash with this one (a .gpx file, already mentionned in first message in "More examples"), when you choose "Ignore" for opening the score with 8c06c3a
Juan Buscaglia - Milonga (Pro).gpx
EDIT: this file opens correctly with Beta2. But I don't understand very well a point.
By opening this file by GP6, I don't see fretboard diagrams on the score (only three chords names in all the score: see image)
In contrast, I receive three fretboard diagrams (blanks) at the same location, above these measures 38,39,40, with Beta2.
And if I delete these diagrams, there is no more crash by opening with the last Nighlty.
This bug is probably not going to be easy to fix as opening and saving the file again in TuxGuitar creates a file that is loaded in by Musescore without error. This means that I cannot trim the file down to a minimum working example to debug from, working from a full score with multiple instruments creates a lot of background noise. Unfortunately, we can't create GP3 files in the original software any longer as it's no longer available.
There are a few files I have that exhibit the same problem, I'll try and step through the file loading process in a bit more detail in order to make some sense of this.
FWIW, while corruption and crashes are bad, and you've all probably heard me go on about making it a goal to release with no known reproducible cases of either, an imported file coming in corrupt from the beginning bothers me much less - especially if it's basically the case that it was "corrupt" by our standards in the first place - than corruption caused by an editing operations. My beef against corruption is more about losing hard work in a score you've created from scratch.
Similarly, for crashes, my main concern is the potential for lost work. A crash on a file you've already been warned is corrupt bothers me less than a crash during editing. A crash on load would bother me less as well, *except* you might have unsaved work in another tab.
So for me, creating corruption in import is something I can live with, particular if we run the sanity check immediately upon import to wanr of the corruption. And a crash on editing of a score that were already warned about I can live with as well.
Meaning I personally would recommend focusing on *detecting* the corruptions on the import (perhaps just relying on the existing sanity check, perhaps expanding a bit), and avoiding crashes during import.
A fix in this commit a27e320e33. But more work needed.
Another fix in 96d5cebdb5
I padded the incomplete measure with rests. I didn't do it for GP6, not sure if it's a problem there too.
The original GP3 file now load without warning.
All the GP5 files too.
This GP4 has some remaining problems.
The 2 GP6 are still a problem.
Can't we do that padding with rest generally, when sanity check detects it?
Reducing to major, following Marc' arguments...
No, we can't. The padding is needed because of the way guitar pro stores notes, chords in the file. For MuseScore files, the padding could destroy the file since we don't know where the notes are missing. Also some cases are due to too many notes and padding would not solve anything in this case.
More tests by cadiz1
http://musescore.org/fr/node/49671#comment-230801
My feedback:
We can do our best to import GP files but unfortunately Garbage in, Garbage out. If the GP file is broken, nothing we can do
should_i_stay_or_should_i_go_ver4.gp3
MuseScore says that measure 42, staff 1 and 2 are corrupted. And indeed, 9 eighths notes in 4/4 measures. GP seems to let user enter whatever he wants, MuseScore is more strict regarding this and so he warns the user. The same case for several remaining files in the previous feedback. In this feedback, same for Queen, We will rock you.gpx, take a look to the first measure, first staff, too many notes for this measure.
léa.gp3
Very old GP file. Detected as GP1, apparently we don't support this? Jpirie, any idea?
In any case the error "Bad format" is good enough. At least we don't crash.
Hendrix, Jimi - Hey Joe (bbc).gp5
The first measure, staff 3 contains a true whole rest for 2/4 and not a full measure rest. I have a patch.
knights_of_cydonia_ver2.gp5
Something with tuplets and an incomplete measure, we probably have hard time trying to pad it.
Again, it's probably a problem of a measure being too full and so the warning is ok. The crash is the exactly the same than Juan Buscaglia - Milonga (Pro).gpx. Could be worth an investigation to make sure we don't crash on non corrupted file.
I think we are getting our best right now. If someone find a crash or a corruption caused by MuseScore and not present in the GP file, please submit another bug with (a link to) the file.
If I am not wrong, there is still a crash left. The following files crash when being imported.
Mark Knopfler - Darling Pretty (Pro).gp3
motorhead_ace_of_spades.gp5
andy_mckee_rylynn.gp5
green_day_holiday.gp5
green_day_wake_me_up_when_september_ends.gp5
green_day_wake_me_up_when_september_ends_0.gp5
Hendrix, Jimi - Hey Joe (bbc).gp5
high_hopes.gp3
hotel_california.gp4
knights_of_cydonia_ver2.gp5
I couldn't go into detail yet, but the crash is a programmatic one due to the assert:
Fatal: ASSERT: "gc->noteType() != NoteType::NORMAL"
in fileMuseScore\libmscore\chord.cpp, line 474
Windows 8.1, commit db6293f20
Well, that would happen if the code is trying to add a "normal" chord to another chord. We don't do that - only chords explicitly set to one of the grace types can be added to other chords.
The grace note problem is fixed in e96036e3f3
I put this issue on fixed. If you find other crashes, please open another bug.
Automatically closed -- issue fixed for 2 weeks with no activity.