Myriad Blog 1.3.0 Friday, Dec 19th, 2014 at 07:11pm 

Dev News Friday, Jun 30th, 2006 at 05:13pm
Projet PDFToMusic, étape 18
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
 3 comments.

Dev News Thursday, Jun 29th, 2006 at 05:10pm
Projet PDFToMusic, étape 17

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

Dev News Wednesday, Jun 28th, 2006 at 04:58pm
Projet PDFToMusic, étape 16

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

Dev News Tuesday, Jun 27th, 2006 at 04:52pm
Projet PDFToMusic, étape 15

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

Dev News Monday, Jun 26th, 2006 at 05:18pm
Projet PDFToMusic, étape 14

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

Dev News Thursday, Jun 22nd, 2006 at 05:10pm
Projet PDFToMusic, étape 13

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
 1 comment.

Dev News Wednesday, Jun 21st, 2006 at 04:25pm
Projet PDFToMusic, étape 12

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
 3 comments.

Dev News Monday, Jun 19th, 2006 at 05:02pm
Projet PDFToMusic, étape 11
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
 1 comment.

Dev News Thursday, Jun 15th, 2006 at 04:59pm
Projet PDFToMusic, étape 10

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
 1 comment.

Dev News Tuesday, Jun 13th, 2006 at 05:13pm
Projet PDFToMusic, étape 9

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

Dev News Thursday, Jun 8th, 2006 at 04:51pm
Projet PDFToMusic, étape 8

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
 2 comments.

Dev News Wednesday, Jun 7th, 2006 at 04:54pm
Projet PDFToMusic, étape 7

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

Dev News Monday, Jun 5th, 2006 at 08:32am
Projet PDFToMusic, étape 6

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

Dev News Thursday, Jun 1st, 2006 at 04:32pm
Projet PDFToMusic, étape 5

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


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Dev News
Technical
Mood
Memories
Myriad Life
To be seen
30 previous days
Apr 2006
May 2006
Jun 2006
Jul 2006
Aug 2006
Sep 2006
Oct 2006
Nov 2006
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Jun 2007
Jul 2007
Aug 2007
Sep 2007
Oct 2007
Nov 2007
Dec 2007
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jul 2008
Aug 2008
Sep 2008
Oct 2008
Nov 2008
Dec 2008
Jan 2009
Feb 2009
Mar 2009
Apr 2009
May 2009
Jun 2009
Jul 2009
Aug 2009
Sep 2009
Oct 2009
Nov 2009
Dec 2009
Jan 2010
Feb 2010
Mar 2010
Apr 2010
May 2010
Jun 2010
Jul 2010
Aug 2010
Sep 2010
Oct 2010
Nov 2010
Dec 2010
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Jun 2011
Jul 2011
Aug 2011
Sep 2011
Oct 2011
Nov 2011
Dec 2011
Jan 2012
Feb 2012
Mar 2012
Apr 2012
May 2012
Jun 2012
Jul 2012
Aug 2012
Sep 2012
Oct 2012
Nov 2012
Dec 2012
Jan 2013
Feb 2013
Mar 2013
Apr 2013
May 2013
Jun 2013
Jul 2013
Aug 2013
Sep 2013
Oct 2013
Nov 2013
Dec 2013
Jan 2014
Feb 2014
Mar 2014
Apr 2014
May 2014
Jun 2014
Jul 2014
Aug 2014
Sep 2014
Oct 2014
Nov 2014
Dec 2014
Dec 19th, 2014 at 05:03pm 
Article from Olivier Guillion
Acam Winter étape 24
Dec 18th, 2014 at 04:49pm 
Article from Didier Guillion
ACAM sur Mac étape 7
Dec 17th, 2014 at 05:04pm 
Article from Olivier Guillion
Acam Winter étape 23
Dec 16th, 2014 at 04:55pm 
Article from Didier Guillion
ACAM sur Mac étape 6
Dec 15th, 2014 at 05:08pm 
Article from Olivier Guillion
Acam Winter étape 22
Dec 13th, 2014 at 09:33am 
Comment from Antoine Bautista
0 + Album...
Dec 12th, 2014 at 05:00pm 
Article from Didier Guillion
ACAM sur Mac étape 5
Dec 12th, 2014 at 05:00pm 
Article from Didier Guillion
ACAM sur Mac étape 5
Dec 11th, 2014 at 04:58pm 
Article from Olivier Guillion
Acam Winter étape 21 et autres
Dec 10th, 2014 at 11:55pm 
Comment from Didier Guillion
Re: ACAM sur Mac étape 4

Top of page
Last update:  (c) Myriad