audiveris
audiveris copied to clipboard
problem to detect note heads of 2 voices with same tone but different length
In the above score in measure 13 lower line are two notes of same tone but different length. Audaveris does not detect them as different object but as one "complex" symbol. So it is not even possible to manually correct this problem.
The "reason" for this mistake is that just one long stem is visible, while in fact there should be two shorter stems, one above the other. When we do have shorter stems, Audiveris correctly handles them. I have some examples somewhere.
Perhaps, the engine could specifically detect that case: heads that are located on each side of a long stem, far from either end of the stem, and decide to cut the stem in two parts. The problem is that today, a stem without a properly located ending head is discarded as invalid.
We could also offer the user the ability to manually "split" the stem; This would be enough to allow the re-construction of separate chords.
What is interesting: up to step "heads", the notes are recognized, and step "stems" even connects the stem to the notes (the upper part). It is step "reduction" that finally removes both notes.
Yes, that's the way it works:
- Retrieve stem seeds
- Retrieve not too bad heads
- Retrieve not too bad connections between stem candidates and head candidates
- Reduce all this graph, using contextual grades, incompatibilities, exclusions.
In the case at hand, incompatibility was detected (because there was no good head found on (long) stem top or bottom, hence the stem was discarded, and the heads without stem could not survive either)
Proposal: The engine could build a histogram of lengths of all stem candidates in the whole sheet. Then detect that this stem length is significantly longer than average, and that there are attached candidate heads in canonical locations with respect to potential "half-stems". It could then consider splitting the long stem in two opposite "half-stems".
All this sounds feasible. But, as usual, beware of collateral damages leading to false positives. I know of scores with really long stems, embracing 2 staves!
At this point in time (REDUCTION), we have stems, heads and beams but flags will be processed later in SYMBOLS step. And a stem with many flags is longer than a stem with just one or no flag...
Wow, THIS is a really complex notation. Two voices in each line, chords over text over dynamic symbols over the first line then text again, more dynamic symbols, a line with drum heads AND phonetic syllables :o Maybe my idea I didn't mentioned here, because of some smaller problems (also not mentioned yet) and the lack of work force was a selection window that shows up before transcribing, where you can select some basic options, that the OCR know what to look for in the sheet.
Yes, prompting the user for guidance right before the set is OCR'ed is a good idea. I already put it on the 5.2 features list.
can now be solved by adding a stem manually and so ignore the wrongly detected "long" stem.