Errors while testing scores

[nasehim7]

Hi @hbitteur
There are mainly two kinds of error which I am facing while testing a bunch of scores.

1. Null pointer exception
   For example - Score: https://s3.ap-south-1.amazonaws.com/nasehim-test/3710186.mscz
   generates - 7 PNGs and 7 XMLs.
   for 6 of them, the control images generated are perfectly fine but for the third one, of these 7 files, it gives me a null pointer exception.

For reference - XML file: https://s3.ap-south-1.amazonaws.com/nasehim-test/3710186-3.xml
PNG file: https://s3.ap-south-1.amazonaws.com/nasehim-test/3710186-3.png

Terminal out:

WARN  []                  Features 337  | Error processing file data/input-images/3710186-3.xml
java.lang.NullPointerException: null
        at org.audiveris.omrdataset.api.SymbolInfo.getSmallShape(SymbolInfo.java:249)
        at org.audiveris.omrdataset.api.SymbolInfo.useSmallName(SymbolInfo.java:221)
        at org.audiveris.omrdataset.train.Features.convertScaledShapes(Features.java:217)
        at org.audiveris.omrdataset.train.Features.processFile(Features.java:253)
        at org.audiveris.omrdataset.train.Features.access$100(Features.java:82)
        at org.audiveris.omrdataset.train.Features$1.visitFile(Features.java:365)
        at org.audiveris.omrdataset.train.Features$1.visitFile(Features.java:353)
        at java.nio.file.Files.walkFileTree(Files.java:2670)
        at java.nio.file.Files.walkFileTree(Files.java:2742)
        at org.audiveris.omrdataset.train.Features.processFolder(Features.java:350)
        at org.audiveris.omrdataset.train.Features.process(Features.java:158)
        at org.audiveris.omrdataset.Main.main(Main.java:74)

2. Out of Bounds Exception
   For example - Score: https://s3.ap-south-1.amazonaws.com/nasehim-test/3709991.mscz
   I am getting out of bounds exception for all it's generated PNGs and XMLs.

Terminal out:

WARN  []                  Features 337  | Error processing file data/input-images/3709991-3.xml
java.lang.ArrayIndexOutOfBoundsException: 3168
        at org.audiveris.omrdataset.train.NonesBuilder.getOccupiedYs(NonesBuilder.java:205)
        at org.audiveris.omrdataset.train.NonesBuilder.insertNones(NonesBuilder.java:116)
        at org.audiveris.omrdataset.train.Features.processFile(Features.java:306)
        at org.audiveris.omrdataset.train.Features.access$100(Features.java:82)
        at org.audiveris.omrdataset.train.Features$1.visitFile(Features.java:365)
        at org.audiveris.omrdataset.train.Features$1.visitFile(Features.java:353)
        at java.nio.file.Files.walkFileTree(Files.java:2670)
        at java.nio.file.Files.walkFileTree(Files.java:2742)
        at org.audiveris.omrdataset.train.Features.processFolder(Features.java:350)
        at org.audiveris.omrdataset.train.Features.process(Features.java:158)
        at org.audiveris.omrdataset.Main.main(Main.java:74)

I am getting these error messages for couple of scores so wanted a help from your side to understand issue and get it corrected. Kindly help me understand this. :)

Regards,
Animesh

[hbitteur]

@nasehim7 Sorry Animesh, I'm running behind several projects at the same time...

I just checked the first case in your message (3710186-3.xml and 3710186-3.png), and I was able to reproduce the behavior.

Some shape names, read out of the .xml file, do not correspond to a valid OmrShape as defined by the OmrShape.java file. This is the case for:

• barlineEndRepeat (BTW, I noticed that you list the inner items in reverse order, from right to left),
• graceNoteAppoggiatura (but graceNoteAppoggiaturaStemUp exists),
• graceNoteAppoggiatura noteheadBlack (which is a long and invalid name),
• noSym,
• 4,
• 3,
• 2,
• restDot (but augmentationDot exists regardless of the augmented entity: a note or a rest),
• Flag1UpSmall.

Question: where do you get your shape names from? Is there an "official" document we could use, so that I can update the OmrShape java class.

Non-recognized symbol shapes, when annotated by a small scaling information, led to a NullPointerException when trying to assign them a "small entity" name.
This is now fixed in commit e2da9b2
Sorry for the delay

[nasehim7]

@hbitteur Hi Herve, No problem. I was busy in making the tuplet implementation like the way we finalized on Issue #22 in the meantime. Yes, I read the OmrShape.java and got to know from where the OMR is able to match the symbols. Sorry My bad, I must use the SMuFL name convention so that we will have an aligned name list and wash out the inconsistency.
I need to work on GraceNote Implementation. It will be sorted soon Herve. I will better the names according to SMuFL in the XML. Moreover, the symbols 4 , 3 etc. are part of compound Time Signature we decided in Issue #28. :)

If there's anything else I need to better, kindly let me know here. I will let you know the moment I'm done and we will discuss. :D

Have a Good Sunday,
Animesh

[hbitteur]

@nasehim7
Yes, we have to support the numbers involved in a time signature, such as 4, 3 or 2.
But in most programming languages (and notably Java, C/C++) "4", "3" or "2" are not legal idenfifiers.
So, I suggest to use identifiers such as "timeSig4", "timeSig3" and "timeSig2", etc, as defined in SMuFL specs on https://w3c.github.io/smufl/gitbook/tables/time-signatures.html and already defined as such in OmrShape.java class.

[nasehim7]

Okay Herve that will be a good thing to do :)
I will make the required changes in the code. :D

[nasehim7]

@hbitteur Herve, I have made all the changes on which we discussed:-

1. Made changes for using SMuFL names in the code
2. Corrected the RepeatDot Implementation to have left to right flow in the XML.
3. Done the Gracenote Implementation - now it analyses graceNoteAcciaccaturaStemUp, graceNoteAcciaccaturaStemDown, graceNoteAppoggiaturaStemUp and graceNoteAppogiaturaStemDown combined with the nested approach to locate all elements inside it - like note, stem, hook and slash (if it's acciaccatura) :D
4. Nosym was basically because of some issue faced during clef recognition, it is now corrected and working.

[hbitteur]

OK

[nasehim7]

@hbitteur Hi Herve, This is the link to the files I generated with our current Implementation of OMR work. I am into testing it more often but for your opinions as discussed with @lasconic to make things better, sharing with you because you surely know better.

Link: https://s3.ap-south-1.amazonaws.com/nasehim-test/data.zip

It contains somewhere around 13,400 files - XMLs and their PNGs.
I am also resolving issues I come across during testing.

Best,
Animesh

[nasehim7]

Hi Herve, I have closely tested first 165 scores from the 988 scores shared by lasconic and below are the symbols I assembled which the omr is unable to detect:

I have numbered the shapes for which I am not able to get the SMuFL names

graceNoteSlashStemUp : https://www.smufl.org/version/1/glyph/graceNoteSlashStemUp/
graceNoteSlashStemDown : https://www.smufl.org/version/1/glyph/graceNoteSlashStemDown/
graceNote16 // 1
graceNote32 // 2
graceNote32_After // 3
noteheadSlashHorizontalEnds : https://www.smufl.org/version/1.12/glyph/noteheadSlashHorizontalEnds/
noteheadSlashWhiteHalf : https://www.smufl.org/version/0.99/glyph/noteheadSlashWhiteHalf/
noteheadDiamondBlack : http://www.smufl.org/version/1.12/glyph/noteheadDiamondBlack/
noteheadTriangleDownBlack : http://www.smufl.org/version/1/glyph/noteheadTriangleDownBlack/
bracketNormal // 4
bracketSquare // 5
bracketLine // 6
sixStringTabClef : https://www.smufl.org/version/1.12/glyph/6stringTabClef/

I will make the edits accordingly and will list more here with further testing. :)

Best,
Animesh

[nasehim7]

I will be posting more additions to this comment:
Some of the classes missing in the OMR are -

1. Brass Techniques :
   http://www.smufl.org/version/latest/range/brassTechniques
2. Guitar :
   http://www.smufl.org/version/latest/range/guitar

These are some I have come across while testing. I will research more. :)

Best,
Animesh

[hbitteur]

@nasehim7
It's quite normal that some classes are still missing in current OMR list.
This list is meant to uniquely identify symbols that are likely to be handled in the short term future by an OMR engine like Audiveris.

This list will evolve with time, so it's a good idea for you to export symbols, even if their name does not yet exist in current OMR list. When we extend the OMR list, we'll use your SMuFL-derived names.

Thanks for your work
/Hervé