Projet de logiciel de lecture compatible LMS

[a supprimer merci]

Thierry, tu es en quelle version de LMS ?
Je vais regarder sur les forums.

---

J'ai terminé la deuxième version, qui récupère les données de LMS (enfin, pas tout, puisque je n'ai pas encore récupéré les noms dans leur version de "tri" - ex: sans le prefixe "The" pour les artistes...). Le temps de traitement pour récupérer les données de LMS est plus long que ce que j'anticipais - environ autant de temps que pour faire un scan complet de la bibliothèque LMS. Pour ma bibliothèque, qui compte presque 30.000 titres, cela prends entre 5 et 10 minutes. J'utilise le logiciel "LiveCode" pour écrire le programme, et je pense qu'il y a une option de compilation lorsque l'on génère un "executable", qui devrait accélerer les choses. Le code peut certainement être encore optimisé. 

Pour que l'affichage soit fluide, je récupère tous les fichiers d'images que je sauvegarde dans une version réduite (200x200) dans une base propre (associée à l'application), ce qui prends un certain temps (quelques minutes...).

C'est assez compliqué de répérer uniquement les modifications/ajouts, donc pour l'instant, il faut refaire un scan complet dans l'application (en plus du scan fait par LMS).

Je récupère les tags suivants de LMS:
- Albums: Nom de l'album, Titre, "album artist", année
- Titres: Nom du titre, numéro de disque et piste, album associé, artiste ("track artist"), compositeur, "conductor", "band" (je n'ai toujours pas compris d'ou viens ce tag), genre, commentaire

Les champs artistes, compositeurs... peuvent évidemment contenir plusieurs noms, qui sont bien séparés en fonction du paramètre défini dans LMS. Toutefois, lorsque l'on récupère ces noms avec les fonctions d'interfaces standard, les noms sont agrégés et repris avec une "virgule" comme séparateur. Ex: dans LMS, j'indique en artiste: "Duke Ellington;Johnny Hodges", ou le ";" est défini comme séparateur. Quand je récupère l'information dans l'application, cela deviens "Duke Ellington,Johnny Hodges".

J'ai donc deux versions à peu près opérationnelles (hormis l'envoi de la lecture vers les players):
- une qui reprends toutes les données de LMS (titres, albums, images)
- l'autre qui reprends les données de fichiers textes, et n'utilise LMS que pour la lecture des pistes

Dans la première solution (base LMS), l'avantage est que l'utilisation est parfaitement cohérente avec ce que l'on retrouve en utilisant les applications "standard" LMS. L'inconvénient, est que l'on hérite des problèmes de LMS (ex: ces disques récalcitrants qui ne se regroupent pas), et que l'on est limité par le "modèle" LMS... 

Si je reste sur cette option, et comme indiqué précédemment, il faut que je trouve un moyen d'identifier les "nouveautés" (car LMS ne fonctionne pas bien, puisqu'il s'appuie sur la date de modification des fichier, et ne gère pas une "date d'ajout"), et quelques informations complémentaires (lablel, libellé des disques dans le cas d'albums multi-disques, gestion des musiciens autrement que via les tags ci-dessus, etc...).

Dans la seconde solution (lecture LMS uniquement), c'est plus souple dans la structuration de la bibliothèque, mais les meta-données peuvent être différentes de celles de LMS... Ex: on crée un "album" en générant un fichier "tag" pour un ensemble de diqsues, qui pourraient être regroupés différemment que dans LMS. Dans cette solution, il faut trouver un moyen de générer les fichiers descriptifs par album "en masse" (ce que je n'ai pas encore fait, mais qui doit être possible avec un utilitaire de macros sous windows ou mac).  

Qu'en pensez vous ?

D'ici quelques jours, je ferai une version "executable" et vous la mettrez à disposition pour que vous puissiez tester (si vous le souhaitez).