Les feuilles cue, et des rips qui se comportent comme des albums
Si tu as rippé des CD avant que le découpage devienne la norme, une partie de ta bibliothèque est un FLAC par disque avec un fichier texte à côté. La plupart des lecteurs ignorent la feuille ou traitent ce qu'elle décrit comme de seconde zone. Voici ce que rox en fait.
Ce qu'est vraiment un rip cue
Un fichier audio contenant un disque entier, et une feuille .cue listant où commence chaque piste. C'est la manière fidèle de conserver un CD, parce que les blancs entre les pistes font partie du disque et que le découpage les jette. C'est aussi le format qui casse l'hypothèse sur laquelle repose toute bibliothèque musicale : qu'un fichier est une piste.
Les lecteurs règlent cela de trois façons. Ignorer la feuille et afficher une piste de soixante-dix minutes. Afficher les pistes de la feuille mais les tenir à l'écart de la vraie bibliothèque, de sorte que la recherche, le tri et les playlists se comportent différemment pour elles. Ou rendre la rupture réelle et l'absorber une bonne fois.
De vraies lignes, pas des fragments
rox indexe chaque segment de la feuille comme une ligne ordinaire de la bibliothèque, identifiée par son fichier plus son numéro de piste. Tout ce qui vient ensuite le lit comme une piste, parce que pour tout ce qui vient ensuite c'en est une. Les playlists le figent, les écoutes s'y rattachent, la recherche le trouve, les colonnes de tri le trient, et aucune d'elles ne sait que onze lignes pointent sur le même FLAC.
L'alternative que choisissent la plupart des implémentations est un chemin synthétique, album.flac#3, qui garde la base propre et déplace le problème sur chaque morceau de code qui ouvrira ce chemin plus tard. Un suffixe que ce code oublie de retirer devient un bug silencieux qui lit des octets de tags dans le vide. Une bibliothèque sans feuilles cue ne paie rien de tout ça : les segments vivent dans une table annexe, et rien sur les chemins critiques ne les lit.
Lire un segment comme un fichier
Le moteur traite un segment comme le monde entier pour cette piste : un positionnement précis sur son début, une coupe à l'échantillon près des deux côtés, et une limite de fin qui emprunte le même chemin qu'une vraie fin de fichier. Le sans-blanc, le fondu enchaîné, l'arrêt après la piste en cours et la boucle fonctionnent tous sans savoir que les segments existent.
La coupe de tête est le détail qui compte. Un positionnement précis atterrit sur une frontière de paquet plutôt que sur l'échantillon exact, donc sans jeter les trames entre l'atterrissage et le début du segment, chaque piste s'ouvre sur la queue de la précédente. C'est le son d'une implémentation cue que personne n'a terminée.
Les pistes consécutives d'un même rip partagent un groupe d'album, et c'est ce qui empêche le fondu enchaîné de fondre par-dessus les enchaînements sans blanc propres au disque. Un rip se lit comme le disque dont il a été tiré.
L'analyse, et le droit de changer d'avis
La feuille revendique son image. Tant qu'un cue liste un fichier, ce fichier n'obtient pas de ligne à lui, tu ne te retrouves donc pas avec onze pistes plus un doublon de soixante-dix minutes. C'est le plus récemment modifié des deux qui fait foi, modifier la feuille ou l'audio redécoupe donc le rip à la prochaine analyse. Supprime la feuille et l'image se replie en une seule ligne ordinaire.
Les métadonnées préfèrent la feuille et retombent sur les tags propres à l'image. Les feuilles écrites avant que la discipline UTF-8 existe obtiennent un repli cp1252, parce que les vieux rips sont exactement la population visée par cette fonction.
Des notes qui n'estampillent pas tout le disque
rox écrit normalement les notes dans les fichiers eux-mêmes, ce qui est le bon choix tant qu'un fichier est une piste. Sur un rip cue, ce ne l'est plus : l'image appartient aux onze pistes, une écriture par piste estampillerait donc chacune d'elles avec les mêmes étoiles.
Le module d'écriture refuse la partie fichier pour ces lignes et la base conserve la valeur. Pareil pour les modifications de tags. Tu obtiens des notes par piste sur un rip, et ton image en ressort identique octet pour octet.
Les détails que tu ne remarquerais que plus tard
- L'export m3u écrit les segments sous la forme
path#N, et l'import préfère une correspondance de chemin exacte, une playlist fait donc l'aller-retour par d'autres logiciels sans s'effondrer sur l'image. - Le scrobbling et la lecture en cours dédoublonnent sur la paire, les onze pistes d'un disque se scrobblent donc comme onze pistes plutôt qu'une seule très longue.
- Les écoutes se rattachent par segment après une nouvelle analyse, un disque garde donc son historique de lecture par piste même quand chaque segment porte des tags identiques.
- Seule la paire album des valeurs ReplayGain est reprise. Les valeurs par piste écrites contre une image de disque entier décrivent le disque, elles sont donc ignorées plutôt que crues.
Le vrai test n'est pas de savoir si un rip se lit. C'est de savoir si, un mois plus tard, quoi que ce soit dans la bibliothèque se comporte encore différemment parce que ça venait d'une image.
Pointe-le sur l'étagère que tu n'as jamais découpée
Le scanner ramasse les feuilles dès sa première passe, en même temps que tout le reste. Plus sur ce qui casse à l'échelle d'une bibliothèque.
Sous Arch ou NixOS ? Installe-le plutôt depuis l'AUR ou le flake Nix.