Putting a tune in Albums transposes some notes an octave down or up --Bug or what?

• Nov 30, 2016 - 05:16

I import a tune from .mxml and it looks fine as a tune. When I create an album with it and another tune and then join them, the resulting set has some notes in the second tune moved an octave down. In one case, a tune in the key of G, all C and D notes are an octave too low. If I switch the order of tunes and the other tune (also in the key of G is second) all A and B notes are an octave high.

Does anyone have a clue what is happening? Is this a bug or am I misusing albums? I can post the tunes and album files if it helps diagnose the problem.

Thanks


Comments

Posting the scores would help. My guess is that one of the instruments in one of the tunes is a transposing instrument or uses one of the octave clefs (with the little 8 above or below), and when combined into an album, it uses the clef and transposition for the album instead of the original clef and transposition for that score. Albums are really only designed to work if all the scores in it have the same structure in terms of the arrangement of instruments and staves.

I'm not specifying any instrument and don't think there are the transposing keys. I'm attaching the two tune files, the album file, and the joined album.

The two tune files are
Golden Ticket.mscz
Rainy Night in Montague.mscz

I renamed RainyGolden.album to RainyGolden.album_.xml so I could upload it. It has Rainy Night first and Golden Ticket second.

The joined score is
RainyGolden.mscz

It's actually my wife who's doing the music. She plays contra dance music. I'm just providing technical support.

MuseScore seems like a great product, a step up from Noteworthy Composer. Thanks for the help.

Attachment Size
Golden Ticket.mscz 11.25 KB
Rainy Night in Montague.mscz 12.47 KB
RainyGolden.mscz 13.14 KB
RainyGolden.album_.xml 435 bytes

In reply to by JAGoldman

Also, there is no time signature in "Golden Ticket", which is in itself odd unless you went out of your way to do that. But I'm thinking all three of these effects (no time signature, no instrument, inconsistent transposition) are by product of importing a questionable source file (whether MusicXML or some other format).

Now that I see the joined score, though, I can see there is something else going on as well. It isn't *consistently* an octave off, some notes are off while others are not. This tells me that the problem is with the transposition of the instrument. MuseScore keeps track of the pitch in concert and transposed keys separately. Normally these should be in sync, but in "Golden Ticket", something is very off. You can see that by pressing the "Concert Pitch" button and noticing how oddly things are respelled.

So I think whatever caused the instrument to be missing is also causing the transposition error. Probably the best thing to do at this point is to go ahead and set the instrument to something reasonable - flute, say - and then fix the key and transpose. Then re-save the score. Now it should be OK.

In short, "Golden Ticket" is corrupt already. The problem you are seeing with albums is but one symptom of this corruption, but simply pressing the Concert Pitch button shows the problem with the original as well.

Question is, do you have any idea how did score got into this state?

In reply to by Marc Sabatella

We're doing a lot of export import to get this score.

We started in Noteworthy composer and save the tune as a noteworth txt file.
Save file as NWCtxt.
Go to http://nwc2musicxml.appspot.com/
Select Choose a NWC file… and select the NWCtxt file
Select Convert to MusicXML
Save the file from the web browser
Open XML file in MuseScore.

Problem probably starts in the nwc2musicxml.appspot.com conversion to MusicXML or maybe in the original NWC file.

We'll try your suggested fix.

thanks

In reply to by JAGoldman

Yeah, it definitely seems that by the time you got a MusicXML file, it probably had some issues that MuseScore struggled with. If you still have the MusicXML file you imported to create "Golden Ticket", it would be useful if you could attach it. That way we can see if it is truly invalid or if there is something we should be handling better than we are.

In reply to by Jojo-Schmitz

I believe the problem is the transposition tag in the MusicXML. It contains only chromatic = -4 and no diatonic.

I would propose to
1/ Fix MusicXML import in MuseScore to autofill diatonic if chromatic is present. See #148131: [MusicXML] import of transposing score with chromatic tag only
2/ Fix NWC2XML to output a diatonic tag with a meaningful value. See https://github.com/lasconic/nwc2musicxml/issues/25

Can anyone think about a case where chromatic != 0 but diatonic = 0 ?

In reply to by [DELETED] 5

Any suggestions on what I should do to fix these files, preferably using MuseScore, but I could also edit the xml file (or a suggestion on what I could change in Noteworthy composer).

Is there a way for me to get a copy of a build with the fix in? If necessary, I can try building it from the branch.

thanks for any help

In reply to by Jojo-Schmitz

The nightly version didn't help.

So I recreated one of the files in MuseScore and exported Mxml and then compared the two XML files.

I made three changes to make the XML files from Noteworthy Composer match the MuseScore XML:

1. The Noteworthy converter put the tag after the tag in some cases. MuseScore reported it as a bad XML file. Moving the tag to before solved the problem.
2. I deleted all transposes. They didn't make any sense in these pieces:
<transpose>
<chromatic>-4</chromatic>
</transpose>
3. For some reason the converter is putting in empty measures before some repeat bars. I just delete them
<measure number="9"/>

These seem to solve the XML import and weird transposition problems. We'll see if the albums behave themselves.

Found one other problem. In some cases, the converter doesn't put the right marking on the second (and last) close repeat. Instead of
<barline location="right">
<ending number="2" type="stop"/>
</barline>
It puts
<barline location="right">
<bar-style>light-heavy
</barline>
which causes MuseScore to put the correct close repeat number there but not the line above it. When the converter puts the second close repeat barline in, it sets the ending number to "1" not "2", but MuseScore treats it as 2 so it's an unimportant error.
Thanks

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