Triplet recognition somewhat spurious (issues with score of Kospoth's Sym. C, 2nd Mvmt)

[hmmueller]

In the last measure of the first sheet; and the last measure of the thrid sheet, triplet "3s" are not all recognized.

On the first sheet, this is - for me - "more or less ok", because the measure is shown in red = "something is off here". I could assign manually "TUPLET_THREE" to the two unrecognized "3s" in the second violin.

• However, selecting each "3" was somewhat difficult: It seems that one must click on a pixel that is "colored enough"; allowing a click in the vicinity might be helpful.

On the third sheet, the second "3" in the 2nd violin is overlooked - but the measure is not shown in red, so it appears to be "ok". Only in the exported MXL, one can see the problem:

It would be great if the "triplet misstep" at least is somehow recognized (but a perfect recognition is of course preferable ;-) ).

Zipped files (pdf, omr, log, mxl): Scannen0017.zip

H.M.

[hmmueller]

Here is another - not too harsh - triplet recognition problem, this time with quarter triplets (i.e., no beams) - just for illustration: On sheet 2, in m.13, only the first triplet in 1st and 2nd violins is recognized. Manually adding a TUPLET_THREE, however, is easy. (In a first OMR attempt, one of the 3s wasn't even recognized as 3, and only a TUPLET_SIX was suggested in the classifier window; but of course, manually forcing a TUPLET_THREE also works then.

Zipped files (pdf, omr, log, mxl): Scannen0005_1-5.zip

H.M.

[Altonss]

I experienced the same issue with the 3 of triplets not beeing recognised.

[hbitteur]

It would be great if the "triplet misstep" at least is somehow recognized (but a perfect recognition is of course preferable ;-) ).

What is happening is the engine had a problem in previous sheet (number 2, an exception I'll have to investigate). Thus it has no information about effective time signature in sheet number 3 (there is no time sig at beginning of sheet 3).

If I manually enter a 2/2 time signature directly into sheet 3 (same time sig as in sheet 1), then the engine immediately flags out 2 measures, one for a non-recognized beam, the other for this non-recognized tuplet-3.

[hbitteur]

I re-launched transcription from scratch on the whole book, and did not observe any exception this time. Strange.

[hbitteur]

Exporting results to MusicXML and looking at it from MuseScore gives pages and pages of empty measures (with just a whole rest in each measure).

Looking at it from Finale is different. It takes a rather long time for Finale to load the data, but the presentation is OK, identical to the input score image.

On a second thought, I realized that many parts in the input score have the same name in the same system. For example first sheet, first system begins with 2 parts both named "Ob.":

How come! I have always thought that a part name was a kind of identity within its containing system. So I expected something like "Ob1." and "Ob2.". And the same applies for other parts, like "Hn. (C)" or "Vl."

This is a big shock for me. Management of logical parts is one of the new features of Audiveris 5.3 released yesterday. And I'm realizing it can't work with this score input. I don't understand how Finale was able to survive and display a consistent score.

How should I modify the logical parts management, if we can't trust the part name?

There is one workaround, something not to be proud of. It's to tell Audiveris to ignore part names and base its collation of physical parts into logical parts only on parts physical configuration (number of staves, number of lines in staves, vertical rank within the system) but ignoring the part name.

Before 5.3, Audiveris ignored the part name, an approach which allowed to work correctly in your case. Sounds like I'll provide a processing switch to allow this physical-only approach.