Les polices de type TrueType, Adobe Type 1, Adobe Type 1C,Type 3 et une police dérivée du TrueType, le Type CiD type 2, ont été uniformisées en un ensemble de commandes de tracé. Ceci nous permet d'avoir un module de tracé commun pour toutes les polices rencontrées et ainsi pouvoir comparer plus facilement les glyphes. Certains fichiers PDF encodent les glyphes des polices, non pas sous forme de tracés vectoriels (courbes de Bézier) mais d'images bitmap monochromes. On peut repérer ces fichiers au fait que, lorsque l'on augmente l'échelle de visualisation du PDF, certains caractères deviennent crénelés. Ceci a été traité et uniformisé. Afin de valider nos extractions, un visualiseur de document PDF est mis en place. Ceci nous permet de contrôler "de visu" ce que nous "comprenons" dans un fichier PDF et servira vraisemblablement ultérieurement à montrer le document chargé à l'utilisateur. Lors de l'analyse du document, les glyphes sont isolés et tracés dans une image en niveau de gris. Cette image est donc prête à s'interfacer avec le module de reconnaissance de caractère en cours de mise au point par Olivier. La plupart des fichiers PDF avec police se chargent plutôt bien, nous allons maintenant nous plonger sur la catégorie 2 : fichiers PDF sans police de caractère incluse. |
|
|
by Didier Guillion | | | |
|

Le travail sur ce projet a débuté depuis trois semaines. Nous attaquons maintenant le problème posé par ce que nous avions appelé précédemment la catégorie 2. Dans cette catégorie, les textes sont dessinées en utilisant des commandes PDF sans aucune référence à une police ou indication de début et de fin de caractère, contrairement à la catégorie 1. L'extraction des caractères en est difficile mais nous construisons un algorithme de décomposition de chemin PDF qui donne de bons résultats. Là aussi, tous les tracés sont convertis dans notre ensemble de commande de tracés communs. En l'état, nous traitons 99% des documents musicaux PDF en notre possession, mais de nouveaux cas particuliers peuvent encore survenir... La prochaine étape sera de rendre tout ceci plus propre (pas mal de sources ont été écrits/réécrits plusieurs fois et sont un peu de guingois) et de le valider sur un maximum de fichiers PDF. Comme nous avons choisi d'extraire les caractères un par un, il va falloir réfléchir à un module qui raboute (concatène) les caractères isolés en mots, (voire phrases) associés à une position précise sur la page. Plusieurs personnes nous ont écrit pour nous soutenir dans ce projet PDFToMusic et nous les remercions de leurs avis et conseils. Dans notre esprit, nous essayons de converger vers une généralisation de la reconnaissance de caractères musicaux et de création de structure de partition. Cette "couche", qui recevrait des symboles bruts non reconnus et en produirait du MusicXML, MIDI, document Melody/Harmony ou autre, pourrait être alimentée soit à partir de l'extraction depuis des documents PDF, soit à partir d'images scannées. Si cela pouvait fonctionner, cela aboutirait à un programme d'OCR entièrement nouveau. Un genre de Super-OMeR... |
|
|
by Didier Guillion | | | |
|

Il nous faut mettre en place une règle de décision qui détermine si une police est musicale ou non, avant d'invoquer la reconnaissance de caractère. Pour ce faire, on utilise la statistique de répartition des caractères sur la page. A partir d'une collection des lignes présentes sur la page, les aires des portées sont extraites, ainsi que les aires des systèmes, puis les aires des mesures sont calculées. L'algorithme de raboutage de caractères en mot a été écrit, on obtient donc une liste de mots associée à chaque page. Apparemment, le PDF fonctionne en Unicode pour l'encodage des caractères, cela tombe bien, Harmony Assistant est Unicode depuis peu... Nous allons fournir ici très bientôt les premiers résultats préliminaires. |
|
|
by Didier Guillion | | | |
|

Un tracé des caractères en courbe de Bézier a été implémenté, cela nous permet de faire avancer de manière drastique le visualiseur de document PDF. D'autant plus que l'encodage des différents types de polices a été uniformisé et que tous les tracés convergent maintenant vers ce module unique. Voici par exemple un fragment de partition, visualisé à l'aide du logiciel "Aperçu" qui utilise les fonctions de Mac OS X: Et le mème fragment, affiché à l'aide de notre visualiseur. Le résultat nous semble encourageant... |
|
|
by Didier Guillion | | |
| |
|

Les caractères musicaux sont maintenant isolés depuis le document PDF original. Une collection des différents tracé des glyphes est mémorisée sous la forme d'un fichier de donnée. Lorsque l'on rencontre un caractère, on le recherche dans la base de donnée, et s'il n'y est pas on le rajoute. Pour l'instant la relation entre le glyphe et sa signification (par exemple tête de noire, ronde,etc) se fait "à la main". Très bientôt cette tache sera confiée au module de reconnaissance de caractères développé par Olivier. L'analyse de la page détermine les ensembles de portées (systèmes), puis les aires des lignes de portées dans le système, puis les aires des mesures dans ces lignes, enfin, chaque caractère musical reconnu est collecté dans la mesure le contenant. Pour contrôler si ceci est correct, il faudrait redessiner ce que nous comprenons sur l'image de la page. Mais cela demanderait de réécrire quasiment un affichage complet de tous les symboles et nous ne sommes pas sur que cela servira dans la version finale. Nous préférons donc écrire (en fait réécrire puisque cela existe déjà en MyrScript) un exporteur au format MusicXML. Le format MusicXML a d'ailleurs de forte chance d'être un des formats d'exportation prioritaire de PDFToMusic. La procédure de validation est donc plus simple : créer un document avec Harmony, l'imprimer en PDF, le traiter avec PDFToMusic, recharger le MusicXML obtenu et contrôler les différences. Des premiers essais sont menés sur des partitions simples. Voici le document original créé avec Harmony puis exporté en PDF. Le PDF est chargé par PDFToMusic et exporté en MusicXML. Le fichier MusicXML généré par PDFToMusic est chargé avec un autre logiciel : Toute la chaîne de traitement est maintenant en place, mais il reste une part énorme de travail : comprendre et convertir le maximum des informations que l'on peut trouver dans dans une partition. |
|
|
by Didier Guillion | | | |
|

Plusieurs fichiers PDF, encodant les caractères sous forme d'images bitmap sans indication de début et de fin de symbole ont été localisés. Une catégorie a donc été créée pour les regrouper, ce sera la catégorie 3. Nous avons donc actuellement 4 catégories, divisées en sous-catégories : La catégorie 0 (zéro) : Ce sont les PDF n'incluant qu'une seule image non vectorielle de la partition par page du document. Non utilisable. La catégorie 1 : Les symboles musicaux sont délimités et dessinés à partir d'une police de caractère. La catégorie 2 : Les symboles musicaux sont délimités et dessinés à l'aide de tracés vectoriels (catégorie 2.1) ou d'images bitmap (catégorie 2.2). La catégorie 3 : Les symboles musicaux ne sont pas délimités et dessinés avec des images non vectorielles (catégorie 3.2). On peut supposer que la catégorie 3.1 existe (symboles musicaux vectoriels non délimités) mais elle n'a pas été rencontrée pour l'instant. Son traitement serait des plus délicat... Les catégories 1, 2 et 3 convergent vers le module de reconnaissance de caractère mis au point par Olivier qui a été connecté à l'ensemble et donne des résultats probants. La base de donnée des tracés est alimentée avec l'ensemble des données extraites des catégorie 1 et 2. J'hésite encore à généraliser ceci à la catégorie 3 car ceci risque de faire "enfler" la base de manière drastique. Le module de reconnaissance arrive à séparer les coulés et liés des autre symboles, eux aussi n'alimentent pas la base de donnée. Lors de l'analyse des PDF en notre possession, un cas particulier de la catégorie 1 a été rencontré. Certains fichiers ne codent pas les lignes des portées avec des commandes PDF (ligne, ou rectangle) mais utilisent un caractère particulier d'une fonte embarquée représentant 5 lignes horizontales sur quelques pixels. Ce cas devra être traité. |
|
|
by Didier Guillion | | |
| |
|

Les différents objets présents dans une partition sont isolés et classés selon leur catégorie : clefs, notes, silences, barres de mesures,etc. La position sur la page de ces différents objets va nous permettre de créer un "squelette" de la page : ensemble d'aire de portées divisées en aires de mesures. Le type de clef, et la tonalité associée à chaque mesure semble correctement interprété. Les objets plus élémentaires (notes, silences) sont associés aux mesures selon leur position. Il est nécessaire de mettre en place une analyse des "ledgers lines" (lignes de repérage) pour pouvoir trouver la portée lorsque le symbole est situé en dehors de l'aire des lignes de la portée. Ensuite, il va falloir associer à chaque symbole ses attributs : altération, paroles associées, ornements, etc. Les paroles posent un problème car il est difficile de savoir si un texte en pied de page fait partie du pied de page ou de parole associés à la dernière portée de la page. Dès qu'une nouvelle étape de la reconnaissance est validée, l'export MusicXML correspondant est écrit afin de pouvoir comparer visuellement le résultat. La partie analyse de document qui fonctionnait sur Macintosh depuis le début à été transférée sur Windows et compilée. Une fois de plus Acam nous à fait gagner un temps considérable de portage. |
|
|
by Didier Guillion | | |
| |
|

Il apparait maintenant de manière de plus en plus évidente que le MusicXML va être le format d'échange entre PDFToMusic et les autres programmes. Il va donc nous falloir écrire un importeur Music XML en C afin de pouvoir charger les fichiers obtenus avec Melody Assistant. Ceci implique qu'il serait donc possible d'intégrer cet importeur au Myriad Music Plug-In et donc d'utiliser le MMPlug-in pour afficher et jouer des fichiers Music XML sur le web. Bien sur, les fichiers devront être compactés car le Music XML est très verbeux. La question a été posée à M. Good, qui gère le projet Music XML, de savoir si un standard de compactage a été défini. Ceci a apparemment mis en chantier la version 1.2 du Music XML qui devrait proposer cette fonctionnalité. Pour exemple, un fichier Music XML de 100Ko est réduit à 4Ko une fois Zippé. Note: C'est avec plaisir que nous recevons vos suggestions sur ce projet, mais envoyez-nous plutôt un email, cela facilitera les échanges... |
|
|
by Didier Guillion | | |
| |
|

Une fois le document PDF analysé et affiché, nous voudrions que l'utilisateur puisse le jouer... Or, et c'est là le problème, il n'y a strictement aucune information sur l'instrument dans un document PDF. Souvent, le nom de la portée est présente, et quand on voit "Guitare" on doit être capable de savoir quoi faire... Mais ce n'est pas toujours le cas. Olivier à donc démarré l'écriture d'un module qui, à partir des informations présentes dans un document, essaie de déterminer quel instrument associer à chaque portée. Les critères sont, entre autre, la clef, la tonalité, la présence ou non d'accords, la tessiture, les groupes de portées définis... Nous prévoyons d'intégrer Virtual Singer dans PDFtoMusic, ce qui permettrait de chanter également les paroles. |
|
|
by Didier Guillion | | |
| |
|

Dans l'étape actuelle, nous travaillons sur la compréhension des symboles afin de recréer une partition valide. Les questions qui se posent sont très proches de celles que nous avons déjà rencontrées lors de la conception d'OMeR en 1999. L'approche est par contre totalement différente. Par exemple plutôt que d'adapter les durées de symboles à la métrique, nous allons faire le contraire. En reconnaissance de partition musicale, une simple erreur entre une barre d'accroche simple ou double par exemple (et c'est graphiquement très semblable) a de forte répercution sur la durée des notes et donc sur toute la structuration de la partition à partir de cette position. Les algorithmes utilisés devraient être beaucoup plus souples et limiter les éventuelles erreurs à la mesure. |
|
|
by Didier Guillion | | | |
|

L'extraction de données depuis un PDF donne une quantité d'informations terriblement précises sur les symboles et leur positionnement. Notre but est d'exporter un maximum de ces informations dans le fichier MusicXML résultat. Ceci a mis en exergue des lacunes importantes de l'import MusicXML d'Harmony Assistant. En fait, cet importeur est le premier d'une longue série d'importeurs qui se sont succédés : Encore, Finale, Tabledit, GuitarPro, etc. et en tant que pionnier il souffre de lourdeurs et de problèmes de conception assez pénalisants. Olivier va donc repartir de zéro et réécrire un importeur MusicXML, en C, qui sera la pierre d'achopement des échanges entre nos applications mais également entre nos applications et les applications extérieures. A terme, cet importeur sera vraisemblablement également disponible dans Melody Assistant et sera une composante du MMPlug-in qui pourra alors gérer les fichier MusicXML |
|
|
by Didier Guillion | | | |
|

La première version de l'importeur MusicXML, écrite en C par Olivier, a été intégrée au projet. Elle est considérablement plus rapide que la version MyrScript ! Le projet PDFToMusic a été lié avec la librairie Harmony de jeu de musique et des premiers fichiers simples ont été convertis depuis le PDF et joués. La question qui se pose est maintenant de faire un lien entre le PDF affiché et la position temporelle de jeu afin d'afficher la position courante par une barre verticale. Ce sera l'objet d'une étude ultérieure. Pour l'instant nous testons nos algorithmes de reconnaissance de caractère et d'export MusicXML sur des fichiers PDF d'origine différentes. Cela montre qu'il reste énormément de travail à faire... |
|
|
by Didier Guillion | | | |
|

Nous bataillons avec l'équipe du MusicXML pour savoir comment exporter la position graphique précise des objets afin d'avoir un rendu à l'écran identique dans les diverses applications. Ce n'est pas une mince affaire car c'est loin d'être normalisé. C'est assez frustrant de connaître au quart de pixel près la position d'un objet dans la mesure et ne pouvoir être sûr du résultat obtenu, ceci variant selon le logiciel. Nos préoccupations ont cependant été entendues, et la version en cours de développement du MusicXML 1.2 devrait, en théorie, clarifier la situation. Le principal travail de la journée a été de discriminer parmi les textes affichés sur la page, ce qui est un accord, une parole, un texte libre, un nom de portée, etc. Pour cela nous avons travaillé à partir de l'exemple de Sylvain M***,"Dimna Juda" de l'étape 11. Un casse-tête très intéressant... Après moultes déboires cela commence a fonctionner. L'export MusicXML a été complété afin de gérer les accords extraits. |
|
|
by Didier Guillion | | | |
|

Aujourd'hui, nous avons rencontré un nouveau type de document. Les différentes lignes (ligne de portée, barre de mesure) sont dessinées à l'aide d'images. Le problème a été partiellement résolu mais la conversion va nécessiter de nouveaux algorithmes de discrimination. Les paroles sont maintenant correctement extraites et associées aux notes, même s'il y a plusieurs lignes de paroles. De plus en plus de fichiers se chargent presque sans erreur. Olivier travaille sur l'importation MusicXML des coulés, liés et accroches. Nous commençons à réfléchir à ce que pourrait donner l'interface. Nous la voudrions simplissime. Du genre, une fenêtre pour représenter le document avec en haut un nombre limité d'icônes. Nous pensons revenir au principe que nous avions utilisé pour la version 1.0 d'Harmony. Plutôt qu'une palette flottante, les icônes seraient directement affichées dans la fenêtre du document, c'est plus gourmand en place écran, mais c'est la mode... Ce que j'aime bien personnellement, en tant qu'utilisateur, c'est de pouvoir définir les icônes présente parmi une liste de fonctionnalités iconisées. A priori, il faudrait, pour la navigation, "Plus une page", "Moins une page", "Augmenter/diminuer l''échelle". Peut-être "Aller à la page" avec une valeur numérique. Pour le jeu : "Lancer", "Pause", "Changer le tempo" . Peut- être, la possibilité de jouer un métronome, mais ce n'est pas sûr. Additionnellement, peut-être une icône pour exporter le document à moins que cela ne soit simplement une option de menu. Les formats d'exportation seraient MusicXML, peut-être MIDI et les pages sous forme de fichiers BMP. |
|
|
by Didier Guillion | | |
| |
|
|