Audiveris / audiveris

Latest generation of Audiveris OMR engine
https://audiveris.github.io/audiveris
GNU Affero General Public License v3.0
1.58k stars 232 forks source link

Import woes #490

Closed RJVB closed 3 years ago

RJVB commented 3 years ago

Hi,

I've been struggling with a guitar tab + score that I wanted to import (just the score). The source is a PDF but even after exporting it to TIFF (with the tab part masked out) there are lots of errors; like missing notes, measures or even staves etc. On 2 pages I could only get the transcription to complete by disabling the detection of elements that are common in guitar scores, and by bumping the max. heap size to 12Gb (-Xmx12G; restarting the app for each page).

I may have overlooked this in the manual but if it's indeed not mentioned how to increase that parameter it would probably be useful to do so.

Would it do any good to share the score with you (masked or unmasked), together with the .omr file? It's a copyrighted score so I cannot attach it here.

hbitteur commented 3 years ago

You can send me your input file by private mail (herve dot bitteur at audiveris dot org)

hbitteur commented 3 years ago

FYI, in development branch, there is an option to "deal" with tablatures. See pull-down menu Book | set Book Parameters. (this option will be available in the coming 5.2.1 release, but you can already pull and build the development branch)

Actually, it just recognizes tablatures of either 4 or 6 lines and simply ignores them. So, it does not process tablature content per se, but at least it does not try to find notes in them. This would save you the need to graphically "remove" those tablatures.

RJVB commented 3 years ago

This would save you the need to graphically "remove" those tablatures.

Good to know!

Trying to parse tablature when a regular score is also available is largely pointless but being able to transcribe tablature-only scores would be great (for those of us who don't want to bother learning to read them ;) )

hbitteur commented 3 years ago

Analysis of your example on first page: 1/ Resolution is too high. Your interline value is 28, it will lead to a waste of resources with no better result, if not worse. 2/ Staff line thickness is constant in a line but varies from one line to the other:

To fix this, at end of SCALE step, use menu Sheet | Set Scaling Data and manually change value of Line thickness from 2 to 3. Then GRID step gives good results.

3/ You selected support for small heads. And yes there are a few small heads in this sheet, but those in the middle of staff 2 have no related stem. And some standard black heads were mistaken for small heads. So, I unset the "small heads" option and got better results. Just 2 half notes to insert manually. And until PAGE step included, everything is fine (we'll have to insert the 2 grace notes manually but this is easily done) I'm done with first sheet.

hbitteur commented 3 years ago

On second and third sheets, all staves were recognized. A few measures exhibit a pink background.

Sheet 2:

Sheet 3:

And now sheets 2 & 3 are OK.

hbitteur commented 3 years ago

Good to know! Trying to parse tablature when a regular score is also available is largely pointless but being able to transcribe tablature-only scores would be great (for those of us who don't want to bother learning to read them ;) )

I'm one of those: I can read tablatures but not standard notation. This is the reason why I started developing Audiveris...

Now, transcribing tablatures is a totally different story than transcribing note heads. And I have enough work on "standard" Audiveris to keep me busy.

RJVB commented 3 years ago

Thanks for looking at this. I was hoping this score might have some useful training data in it, instead I got some training myself - appreciate that! I used to have the OCR done via the MuseScore website, but now that I have Audiveris myself I'll probably keep running it locally.

1/ Resolution is too high. Your interline value is 28, it will lead to a waste of resources with no better result, if not worse.

What resolution? If you mean the 400DPI of the tiff file; how could that lead to worse results when the tiff was generated from a purely digital and vectorial original?

2/ Staff line thickness is constant in a line but varies from one line to the other:

Strange, but could be a result of the pdf->tiff conversion.

3/ You selected support for small heads. And yes there are a few small heads in this sheet, but those in the middle of staff 2 have no related stem. And some standard black heads were mistaken for small heads.

Hmm, IIRC I unset the option for the 2 problem pages, but it's only when I had the complete score imported into MuseScore that I realised that many of these small heads aren't grace notes but are in fact novel-to-me notation for bends. I'm more interested in proper midi playback than in sticking to the original notation so those stemless small heads have gone.

R.

hbitteur commented 3 years ago

Generally 300DPI gives the best results with no overuse of resources. And Audiveris algorithm has been developed and optimized around this value. Granted, in theory any sufficient resolution should be OK. But the engine works with integer values of pixels in a binary view, so if it expects something (say a stem) with a thickness of 1 pixel, how does this translate in a 450 DPI resolution? 1 or 2? Neither of these values is really "correct".

I checked the PDF input, all staff lines on sheet 1 have a thickness of 1 pixel, except lines 4 & 5 for first staff (thickness of 2 pixels). With PDF input, there is no need to tweak the results of SCALE step. So, yes, PDF -> TIF conversion created the problem.

Final advice: if you encounter memory problems, don't hesitate to swap the sheets, via pulldown menu "Book | Swap Book Sheets" : all sheets, except the current one, are swapped to disk (that is: stored to disk and deleted from memory). Only when you move to another sheet, this other sheet will get loaded back from disk if so needed.