Eh bien justement, comment tu classe un musicien aussi éclectique que Herbie Hancock ? Jazz ? Funk ? Hip-Hop ? Fusion ? etc ...
Concrètement, les rippeurs qui se basent sur un cddb le classeront dans un genre à chaque fois différent. Pour moi, ce champ id3, même rempli à la main, n'a aucun intérêt. Je me dit jamais, tiens je vais m'écouter un "jazz", étant donné que quasiment tout ce que j'écoute peut être considéré quelque part comme du jazz, mais quel jazz ? Les autres méta-données techniques sont tout aussi inutile au moment d'écouter de la musique (une requête style bitrate > 192kbps && type = vbr ...)
Les seules méta-données pertinentes sont les artiste/album/titre, et là le bon vieux système de fichier fait encore l'affaire. (par ex: ~/music/Herbie Hancock/1973 - Headhunters/Watermelon Man.mp3)
L'énorme avantage de ce système, est qu'il marche avec tout les lecteurs. Je vais pas perdre du temps à classer mes fichiers dans la base de données du lecteur xxx si demain je décide d'utiliser le lecteur yyy, ou si je change d'OS, ou si je change mes fichiers de place, que je les graves sur un CD, etc... C'est même « classement-friendly » avec les lecteurs en lignes de commande. On peut même utiliser plusieurs lecteurs sans avoir à maintenir plusieurs base de données séparées. Ça ne dépend pas de KDE, ni de QT, ni même de Linux ! ;-)
« tiens, j'me ferais bien du son que je connais mal. »
C'est une information qui est déjà stocké dans les méta-données du FS (inode). Pas besoin de la stocker une deuxième fois dans une base de données.
Je n'ai pas accédé depuis 3 mois à ces fichiers:
$ find ~/music/ -iname "*.mp3" -atime +90
Après au choix: lancer xargs mpg321, lancer xargs xmms --enqueue, faire un {patch,plugin} pour xmms, faire une playlist {m3u,pls}, etc ...
La méta-donnée 'atime' du FS marchera quelque soit le lecteur.
[^] # Re: Oui mais...
Posté par gnujsa . En réponse au journal xmms > /dev/null. Évalué à 3.
Concrètement, les rippeurs qui se basent sur un cddb le classeront dans un genre à chaque fois différent. Pour moi, ce champ id3, même rempli à la main, n'a aucun intérêt. Je me dit jamais, tiens je vais m'écouter un "jazz", étant donné que quasiment tout ce que j'écoute peut être considéré quelque part comme du jazz, mais quel jazz ? Les autres méta-données techniques sont tout aussi inutile au moment d'écouter de la musique (une requête style bitrate > 192kbps && type = vbr ...)
Les seules méta-données pertinentes sont les artiste/album/titre, et là le bon vieux système de fichier fait encore l'affaire. (par ex: ~/music/Herbie Hancock/1973 - Headhunters/Watermelon Man.mp3)
L'énorme avantage de ce système, est qu'il marche avec tout les lecteurs. Je vais pas perdre du temps à classer mes fichiers dans la base de données du lecteur xxx si demain je décide d'utiliser le lecteur yyy, ou si je change d'OS, ou si je change mes fichiers de place, que je les graves sur un CD, etc... C'est même « classement-friendly » avec les lecteurs en lignes de commande. On peut même utiliser plusieurs lecteurs sans avoir à maintenir plusieurs base de données séparées. Ça ne dépend pas de KDE, ni de QT, ni même de Linux ! ;-)
« tiens, j'me ferais bien du son que je connais mal. »
C'est une information qui est déjà stocké dans les méta-données du FS (inode). Pas besoin de la stocker une deuxième fois dans une base de données.
Je n'ai pas accédé depuis 3 mois à ces fichiers:
$ find ~/music/ -iname "*.mp3" -atime +90
Après au choix: lancer xargs mpg321, lancer xargs xmms --enqueue, faire un {patch,plugin} pour xmms, faire une playlist {m3u,pls}, etc ...
La méta-donnée 'atime' du FS marchera quelque soit le lecteur.