problem to recognize noteheads that stick together (same chord - second distance)

[Bacchushlg]

In the appended score there are several chords that have noteheads of a second distance. None of them is recognized, and most are detected as a complex structure containing both noteheads plus the stems.

If I manually correct the trioles, in some cases they assignement goes to the system above or below, in this score this happens in measure 55 top line.

[Bacchushlg]

I have created a simple score from Musescore to be able to better analyse the problem. Here all noteheads are detected properly, because they never stick together completely - but:

• in the 5th and the last measure the lower voice is assigned to the bass line (when I open it in Musescore)
• all notes are exported as quarter notes (very curious, because the beams seem to be recognized properly)

Tests are performed with dev-version 5.1 (29.01.2018)

[hbitteur]

What do you mean with "chords that have noteheads of a second distance"?

[Bacchushlg]

Maybe my english knowledge is too bad. In German it's "Sekunde": Prime, Sekunde, Terz, Quart,... It concerns measure 53ff.

[hbitteur]

My English is not that good either! I'm French. Don't worry. I will check your input image.

Regarding the second example (ChordTest), here is what I get: The SCALE step is fooled by this artificial example: there are so many whole rests, all with exactly the same height, in the page that they are (wrongly) used to define page beam height (something which is done very early, by simply looking at the histogram of vertical run lengths in the image). So, SCALE step ends with a beam scale value of 15 (rather than 11, for the few real beams). Subsequently, these beams are not recognized as such during the BEAMS step... Etc.

[hbitteur]

By editing the ChordTest image, so that only the top system is kept, Audiveris works correctly. Here are the resulting voices (numbering voices is not easy, by default voices are numbered from top to bottom in each part, which is not what the user would expect here). Can you re-assign voices in MuseScore?

[Bacchushlg]

ok, you are right: the test was really too far from a real score. My initial idea was simply to verify the problem with the chords - which is not present in this case.

By the way: je suis moitié francais moi aussi - a cause de ma femme, qui est bretonne ;-))

[hbitteur]

Nobody is perfect! :-)

[hbitteur]

Back to your top example, here is what I did: 1/ Downscale the image by half (resolution was too high, rejected by Audiveris) 2/ Make the rather thin beams collected as beam runs during the SCALE step. I had to modify the constant minBeamLineRatio (in sheet.ScaleBuilder) from 2.5 to 2.0 (done in menu Tools | Options). because there is a check in ScaleBuilder which requires that beam typical height is at least minBeamLineRatio times the height of typical line. Otherwise the beam in the histogram is not considered as a valid beam peak, and the beam scale indicates "extra" for extrapolated, together with the message: "No beam key found, guessed value 11". The value is then guessed with respect to the typical interline value, giving 11 in your case.

OK, so now, beams are correctly recognized (except a few beam hooks, perhaps just too thin, I'd need to check further). But we have this problem at end of measure 39, first staff, with 2 stems that are way too long, and they get discarded during the REDUCTION phase. Have a look at end of step STEMS, and you'll see the pb. I'm afraid I can't do anything here: the stems are technically correct, but the image is crowded, and pixels from note heads are taken as part of stem candidates.

Now, regarding the manual assignment of a triplet in measure 55, top staff, I was able to reproduce the assignment to the system above. It's obviously a bug! I'll correct this immediately.

[Bacchushlg]

What about the chords marked in red: do you get them recognized?

[Bacchushlg]

one more problem that I did not notice so far: the "sharps" in the beginning of the line are not recognized. Curious: I meanwhile noticed on other scores, that often the sharps are ignored in the top note line - for the 2nd they are mostly recognized.

[hbitteur]

Regarding the 5 locations (numbered according to music flow):

1. Half (just the lower one). See picture below.
2. Both
3. Both
4. None (same problem: 2 stems that go too far in opposite directions, making the note head not correctly located WRT the related stem)
5. Both

[hbitteur]

Bug fixed for the tuplet-related staff (in "development" branch)

[hbitteur]

Regarding the beam scaling in SCALE step, perhaps we could offer the user the ability to modify some of the scale retrieved parameters. To be investigated.

[Bacchushlg]

I have built the new sources and loaded the above score. What exactly did you fix with the new version? It's not really obvious to me. At least for the recognition of the tuplets, I don't see improvements - should I?

[hbitteur]

When you manually assigned the tuplet. You said: If I manually correct the trioles, in some cases they assignement goes to the system above or below, in this score this happens in measure 55 top line. I just corrected this bug. That's the problem with putting a bunch of bugs within the same issue. We no longer know which is which. :-)

Regarding the tuplet recognition by the OMR engine, it's much more complex because of the OCR mistake in first place. Now, I'll address the pb with key signature.

[Bacchushlg]

Ok, it's understood. This works fine now! I simply miss-understood the comment of your commit...

[hbitteur]

Abscissa gap between clef and key signature was a bit too wide (case of staves with treble clef). I tuned the parameters, it's ok now.

Note that the natural-only key signatures are not recognized and not handled by OMR engine (case of the last 2 staves). Also, the engine is not able to handle naturals mixed with sharps or flats within the same key signature. Such improvement is postponed until we have the patch classifier.

[Bacchushlg]

about the parameters: they are part of the options, so that I might try this too?

[hbitteur]

about the parameters: Yes, we can!

In theory, the OMR engine is just a bunch of algorithms with no hard-coded constants. A source value is defined for each constant in a specific part of the source code.

All these constants can be overridden through the Tools | Options menu (and also through the command line interface -option key=value). These user modifications persist across application runs. And it's easy to undo any constant modification, and thus restore the source value.

But it's a low-level means: You have to find out the relevant constant(s) and they are numerous, plus you have to understand the role of the constants at hand.

[Bacchushlg]

I'd like to mention that the initial problem persists. And from my point of view it should be handled. I have a couple of scores where note heads are so close together that they are not detected as separate glyphs. And the worse the image, the more often it happens. The most critical case looks like this: The stems of the left notes are considered as one long stem (when assigning it manually). So it is impossible to assign both note heads later (one will be without stem...)

My proposual: The glyph analysis needs a special handling for note heads sticking together and a sort of stem splitter that looks for note heads nearby.

[Bacchushlg]

it seems that this can be better handled with the future analysis tooling. And it appears rather seldom - and can now be solved since manual adding of stems is possible. Therefore -> enhancement.