search

Grandemange / music21

Automatically exported from code.google.com/p/music21
0 stars 0 forks source link

MusicXml: incorrect accidental for pitch exception #73

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

from music21 import *
c = converter.Converter()
c.parseFile('score.mxl')
b = c.stream
sp = midi.realtime.StreamPlayer(b)
sp.play()

What is the expected output? What do you see instead?

File "/Desktop/music21-1.3.0/music21/musicxml/fromMxObjects.py", line 2481, in 
mxToScore
    raise FromMxObjectsException('cannot translate part %s: %s' % (partId, strerror))
music21.musicxml.fromMxObjects.FromMxObjectsException: cannot translate part 
P1: cannot translate note in measure 14: incorrect accidental 5 for pitch F4

What version of the product are you using? On what operating system?
music21 1.3.0
Ubuntu 12.10

Please provide any additional information below.

If I edit fromMxObjects.py and add the following lines to mxToPitch() before 
the exception the score plays as expected.  

I get these 2 lines printed out where it would have thrown.
mxToPitch...before throw..returning default pitch instead....mxNote=<note 
<pitch step=F alter=5 octave=3> duration=4 voice=1 type=eighth 
<time-modification actual-notes=3 normal-notes=2> stem=up staff=2 <beam 
number=1 charData=continue>>
mxToPitch...before throw..returning default pitch instead....mxNote=<note 
<pitch step=G alter=5 octave=3> duration=4 voice=1 type=eighth 
<time-modification actual-notes=3 normal-notes=2> stem=up staff=2 <beam 
number=1 charData=continue>>

I'm sure it has a note or 2 wrong somewhere, but atleast it plays.

                print("mxToPitch...before throw..returning default pitch instead....mxNote="+str(mxNote))
                p = pitch.Pitch()
                return p
                raise FromMxObjectsException('incorrect accidental %s for pitch %s' % (str(acc), p))

The attached score (Sonata_No._14_Op._27_No._2_-_Ludwig_van_Beethoven) comes 
from 
http://static.musescore.com/30321/cc9927b018/score.mxl

Original issue reported on code.google.com by shao...@gmail.com on 29 Oct 2012 at 11:04

Attachments:

GoogleCodeExporter commented 9 years ago 
Diving into the xml, the 2 errors are generated by backup blocks.

      <backup>
        <duration>48</duration>
        </backup>

Original comment by shao...@gmail.com on 29 Oct 2012 at 11:23

GoogleCodeExporter commented 9 years ago 
I'm not sure if this will be helpful, but here is an edited version of the xml 
down to where the error occurs.

Original comment by shao...@gmail.com on 29 Oct 2012 at 11:42

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi Shao Lo,
I was able to reproduce your problem both by "moonlight.xml" and 
"http://static.musescore.com/30321/cc9927b018/score.mxl" 
Looking at the xml:
<note default-x="227.02" default-y="-120.00">
        <pitch>
          <step>F</step>
          <alter>5</alter>
          <octave>3</octave>
          </pitch>
        <duration>4</duration>
        <voice>1</voice>
        <type>eighth</type>
        <time-modification>
          <actual-notes>3</actual-notes>
          <normal-notes>2</normal-notes>
          </time-modification>
        <stem>up</stem>
        <staff>2</staff>
        <beam number="1">continue</beam>
        </note>
And the accidental <alter>5</alter> does not make sense to me, because the 
value is usually -2 to -2. 
I tried using museScore to uncompress the mxl instead of loading directly by 
Music21; it succeeded and I could not find any alter=5 (that xml loads to 
music21 perfectly, too)
IMHO it looks more like there is a bug in music21 parsing mxl file. Will update 
if there is any new findings.

Original comment by OsbertN...@gmail.com on 5 Mar 2013 at 12:16

GoogleCodeExporter commented 9 years ago 
Hi Shao Lo,

To cut it short, there are lots of unreasonable chromatic alterations in the 
mxl file that trigger the error. The reason why MuseScore does not complain is 
because MuseScore simply ignores the erroneous alterations and by default set 
it to 0, at the expense of incorrect pitch.

If you open the file via MuseScore, you can spot some errors in Bar 12, where 
the last 3 eighth notes read D3, A3, C4, while the correct ones should be F#3, 
C#4 and E4. Extracted to xml file Line 3518 - 3555 shows the 3 notes are 
notated as:

D3(####), A3(####),C4(####)

Which, if you really count the sharps it adds up to the correct pitch.

There is no easy way to fix the file, but if you just want to read the file in 
music 21, you can replace all "alter>3", "alter>4", "alter>5" etc into 
"alter>0". However the file contain incorrect notes, exactly what you will see 
in MuseScore.

Since fixing musicxml file is not a music21 feature, I would suggest to change 
this issue to invalid.

Original comment by OsbertN...@gmail.com on 23 Mar 2013 at 1:20

GoogleCodeExporter commented 9 years ago 
Agreed that it's not a music21 error -- though I have seen some of these issues 
arise before from one musicxml creator, I think that I might put a patch to 
ignore |alter| > 4 since it's not valid musicxml. thanks!

Original comment by cuthbert on 9 Apr 2013 at 6:30