Projet de logiciel de lecture compatible LMS

[chakiwi]

(11-29-2018, 08:26 PM)Bigga a écrit : Ou alors, si ce n'est pas trop complexe à réaliser en programmation, on peut imaginer un lien bouton "genres" qui ouvre une fenêtre popup où sélectionner le ou les genres que l'on souhaite.

Oui c'est une bonne idée

[a supprimer merci]

Oui bonne idée!

---

La lecture des fichiers "tags" (créés avec MP3Tag) est assez longue - contrairement à ce que j'anticipais. Le problème n'est pas le chargement initial, mais l'identification des modifications à posteriori. Il ne faut pas que tout cela devienne une usine à gaz... Ce serai tellement plus simple si il y avait une seule norme pour les tags !

[a supprimer merci]

Je pense que je vais changer de stratégie vis à vis des tags, et repartir sur les informations qui sont stockées dans la base LMS (qui est une base "SQLite", ouverte), et stocker dans des fichiers texte (un par album, défini dans l'arborescence des fichiers) uniquement les informations complémentaires:
- soit récupérées des tags, mais via une application externe (ex: création d'un fichier avec MP3Tag)
- soit maintenues directement dans l'application (et donc sauvegardées ensuite dans ces mêmes fichiers).

Si a terme une solution peut être développée pour gérer les tags avec un base externe (type Tonal) je regarderai comment l'intégrer. 

Reste à définir exactement le contenu du fichier.

Les informations suivantes sont stockées dans LMS, à partir de la lecture des tags des fichiers:

(1) Les tags de bases
- ALBUM, ALBUMARTIST, YEAR, GENRE, DISC, TRACK, TITLE, ARTIST, COMPOSER, COMMENT
(2) Tags "étendus" (pas définis dans toutes les "normes" de tags), et pas fréquemment gérées
- CONDUCTOR, BAND

Je vais partir du principe que les tags suivants sont communs à chaque album:
- YEAR, GENRE, ALBUMARTIST

Les informations présentes dans les tags (standard) mais non inclues dans LMS sont notamment:
- PUBLISHER (le label)
- SUBTITLE
- ORIGYEAR
- ORIGALBUM (album d'origine)
- WORK et MOVEMENT
- INVOLVEDPEOPLE

Les informations qui me semblent utiles, et qui pourraient donc être lues à partir des fichiers texte sont:
- la date d'ajout dans la bibliothèque (qui n'est pas bien gérée dans LMS)
- le label
- la date/lieu d'enregistrement, mais c'est possible de l'indiquer également dans le champ commentaire
- les musiciens
- autres informations libres (commentaires, liens, etc...)

Je vais continuer de partir de l'hypothèse qu'un album est stocké dans un répertoire unique (qui peut contenir des sous répertoires) et que l'image de l'album est contenue dans ce même répertoire. Pour démarrer, il suffira donc de créer un fichier (. Tag) dans chaque répertoire correspondant à un album. Ce fichier pourra, au départ, être vide et s'alimenter progressivement.... Le programme fera donc le lien entre le fichier et les données de LMS via la structure de dossiers.

Ce serai également intéressant de rajouter est une base de compositeurs/musiciens, que l'on pourrait charger dans l'application via un fichier, ou peut être (qui sait ?) partager. Cette base pourrait permettre de faire des contrôles sur les données des tags, afficher des informations complémentaires...

En attendant de voir comment gérer tout cela, je vais poursuive mon développement en récupérant les tags de "base" de LMS, et en intégrant une simple fenêtre de commentaires éditable dans l'écran de l'album, et stockee dans le fichier texte correspondant.

[Bigga]

(11-30-2018, 09:28 AM)paulw a écrit : Ce serai également intéressant de rajouter est une base de compositeurs/musiciens, que l'on pourrait charger dans l'application via un fichier, ou peut être (qui sait ?) partager. Cette base pourrait permettre de faire des contrôles sur les données des tags, afficher des informations complémentaires...

Comment vois tu cette base de compositeurs/musiciens exactement? Je n'ai pas ben saisi quel en est le but...

[a supprimer merci]

(11-30-2018, 02:14 PM)Bigga a écrit :

(11-30-2018, 09:28 AM)paulw a écrit : Ce serai également intéressant de rajouter est une base de compositeurs/musiciens, que l'on pourrait charger dans l'application via un fichier, ou peut être (qui sait ?) partager. Cette base pourrait permettre de faire des contrôles sur les données des tags, afficher des informations complémentaires...

Comment vois tu cette base de compositeurs/musiciens exactement? Je n'ai pas ben saisi quel en est le but...

Cela visait essentiellement à normaliser les noms et vérifier les incohérences, peut être rattacher des liens ? Ce n'est pas prioritaire. 

Une petite question aux utilisateurs LMS: est-ce que vous fait un sxan complet de la bibliothèque systématiquement ou utilisez l'option de recherche des ajouts/modifs ? 

J'ai vu un petit bug sur la modification des commentaires (lle nouveau commentaire est rajouté à l'ancien) .

[Bigga]

Il n’y a pas que pour les commentaires. J’ai parfois modifié des tags après avoir repéré des erreurs d’ecriture Sur l’application remote, et à moins d’un rescan complet de la bibliothèque ils n'étaient Parfois pas pris en compte.
Depuis, je suis partisan de rescanner totalement la bibliothèque dans ce cas de figure.
Par contre, si il ne s’agit que d’un ajout de nouveaux albums, je fonctionne en ajoutant les nouveaux fichiers seulement.

[Ezel78]

(11-30-2018, 03:44 PM)paulw a écrit :

(11-30-2018, 02:14 PM)Bigga a écrit :

(11-30-2018, 09:28 AM)paulw a écrit : Ce serai également intéressant de rajouter est une base de compositeurs/musiciens, que l'on pourrait charger dans l'application via un fichier, ou peut être (qui sait ?) partager. Cette base pourrait permettre de faire des contrôles sur les données des tags, afficher des informations complémentaires...

Comment vois tu cette base de compositeurs/musiciens exactement? Je n'ai pas ben saisi quel en est le but...

Cela visait essentiellement à normaliser les noms et vérifier les incohérences, peut être rattacher des liens ? Ce n'est pas prioritaire. 

Une petite question aux utilisateurs LMS: est-ce que vous fait un sxan complet de la bibliothèque systématiquement ou utilisez l'option de recherche des ajouts/modifs ? 

J'ai vu un petit bug sur la modification des commentaires (lle nouveau commentaire est rajouté à l'ancien) .

Chez moi, je fais le scan complet à chaque fois que je rajoute de la musique. J'avais remarqué que le scan "ajouts/modifs" ne fonctionnait pas toujours au mieux (albums disparus, etc...)

[l'Arédien]

(11-30-2018, 03:44 PM)paulw a écrit : Une petite question aux utilisateurs LMS: est-ce que vous fait un sxan complet de la bibliothèque systématiquement ou utilisez l'option de recherche des ajouts/modifs ? 

Le scan se fait automatiquement à une heure donnée, programmée.

[a supprimer merci]

Merci à vous.

J'ai passé du temps pour voir comment récupérer les données de LMS (sans attaquer la base de données directement). Elle sont décrites ici (c'est un peu technique): https://github.com/elParaguayo/LMS-CLI-Documentation

Du coup, j'ai vu comment récupérer la pochette également, sans passer par les répertoires. Donc je vais intégrer tout cela rapidement.

Pour les données supplémentaires gérées dans l'application (et qui seraient donc stockées dans un fichier, pour plus de "transparence"), j'ai du mal à me décider ou les stocker, et avec quel identifiant: dans la base LMS il y a un identifiant par album, mais qui n'est pas utilisable, car il pourrait être modifié (rescan complet ? réinstallation ?). Si je les sauvegarde dans chaque répertoire, il n'y a pas un moyen "robuste" de faire le lien avec les albums dans LMS...

L'identifiant Discogs est peut être la meilleure solution, mais je ne vois pas comment le rajouter dans LMS. Dans LMS il y a un identifiant "MusicBrainz", mais MusicBrainz n'est pas exhaustif. Bref... J'en ai déjà parlé et tourne en rond sur ce point.. 

C'est d'ailleurs intéressant, car un "album" dans LMS est défini par le couple "album title / album artiste", indépendamment des répertoires. Donc si on a différentes version d'un même album, il faut l'indiquer dans le titre.

[Bigga]

(11-30-2018, 06:36 PM)paulw a écrit : Merci à vous.

J'ai passé du temps pour voir comment récupérer les données de LMS (sans attaquer la base de données directement). Elle sont décrites ici (c'est un peu technique): https://github.com/elParaguayo/LMS-CLI-Documentation

Du coup, j'ai vu comment récupérer la pochette également, sans passer par les répertoires. Donc je vais intégrer tout cela rapidement.

Pour les données supplémentaires gérées dans l'application (et qui seraient donc stockées dans un fichier, pour plus de "transparence"), j'ai du mal à me décider ou les stocker, et avec quel identifiant: dans la base LMS il y a un identifiant par album, mais qui n'est pas utilisable, car il pourrait être modifié (rescan complet ? réinstallation ?). Si je les sauvegarde dans chaque répertoire, il n'y a pas un moyen "robuste" de faire le lien avec les albums dans LMS...

L'identifiant Discogs est peut être la meilleure solution, mais je ne vois pas comment le rajouter dans LMS. Dans LMS il y a un identifiant "MusicBrainz", mais MusicBrainz n'est pas exhaustif. Bref... J'en ai déjà parlé et tourne en rond sur ce point.. 

C'est d'ailleurs intéressant, car un "album" dans LMS est défini par le couple "album title / album artiste", indépendamment des répertoires. Donc si on a différentes version d'un même album, il faut l'indiquer dans le titre.

Oui, c'est d'ailleurs quelque chose que j'ai expérimenté récemment en rajoutant à ma bibliothèque un rip d'un CD de mon père: sonates et partitas pour violon seul de JS BACH par Jascha Heifetz. Moi j'avais déjà la version de Patrick Bismuth. En musique classique, comme je fais figurer le nom du compositeur comme "artiste de l'album" pour y avoir accès plus simplement dans une liste qui n'est pas interminable à chaque lettre, eh ben une fois cette version ajoutée, ça a tout mixé les pistes des 2 albums.
Du coup, j'ai laissé le titre de Jascha Heifetz en anglais pour résoudre ce conflit.

Pour le reste, je pense que le plus "simple" serait de mettre un numéro pour chaque album dans les commentaires, qui renverrait à un fichier dans une base de données, qui elle même pourrait agréger les données Discos ou MusicBrainz. Evidemment, pour que ce soit adapté à de grosses discothèques et future proof, il faudrait un numéro à 6 chiffres au moins.
Je ne vois pas comment échapper au fait de devoir reconstituer une base de données plus exhaustives et plus cohérentes que celles existantes déjà sur le net.