get-tracks.sh : extraire des pistes d'un fichier audio

Posté par karchnu le 24 janvier 2022 à 09:55. Édité par Ysabeau 🧶, Yves Bourguignon et vmagnin. Modéré par Ysabeau 🧶. Licence CC By‑SA.

Étiquettes :

jan.

2022

get-tracks.sh est un script qui extrait des morceaux de musique depuis un fichier audio. À partir d’un fichier audio (CD, livre audio, un mix quelconque…) et de la liste de lecture, retrouvez tous vos morceaux dans des fichiers séparés !

Objectif

Disons que vous ayez :

un fichier audio contenant plusieurs morceaux de musique (comme un CD, un mix téléchargé sur le net ou même un livre audio dont vous aimeriez extraire les chapitres) ;
la liste des plages audio et leur horodatage (quand chaque morceau démarre).

À partir de ces deux informations, vous pouvez extraire facilement vos plages ! ffmpeg fait très bien le travail, mais il lui manque une interface simple pour utilisateur, c’est exactement ce que fait get-tracks.sh.

Usage

Vous avez votre fichier audio, disons doom-eternal.opus, et la liste des morceaux de musique dans un fichier texte (doom-eternal.txt). Ce fichier ressemble à ceci :

0:00 DOOM Eternal
4:48 Hell on Earth
9:29 Deag Nilox - First Priest Death
10:14 Barging In
12:32 Demonic Corruption

À partir de ça, les morceaux sont extraits :

$ get-tracks.sh doom-eternal.opus doom-eternal.txt
$ ls
01 - DOOM Eternal.opus
02 - Hell on Earth.opus
03 - Deag Nilox - First Priest Death.opus
04 - Barging In.opus
05 - Demonic Corruption.opus

Configuration

Le comportement du script peut changer via quelques variables d’environnement.

Par exemple, si vous ne voulez pas le numéro du morceau dans le nom de fichier :

$ NONUMBER=1 get-tracks.sh doom-eternal.opus doom-eternal.txt
# Fichiers produits :
#   DOOM Eternal.opus
#   Hell on Earth.opus
#   ...

Si vous souhaitez les numéros, mais que vous voulez changer le séparateur (qui est par défaut -) :

$ SEPARATOR=". " get-tracks.sh doom-eternal.opus doom-eternal.txt
# Fichiers produits :
#   01. DOOM Eternal.opus
#   02. Hell on Earth.opus
#   ...

D’autres options sont possibles. Par exemple, il est possible de changer le format des fichiers générés, si vous préférez avoir des mp3 plutôt que opus (format libre avec une bonne compression). Allez voir la page du projet pour plus d’informations.

À l’intérieur

Ce simple script est écrit en sh : pas de basheries ou zsheries. Il a été testé sur Linux (Ubuntu et Alpine) et OpenBSD.

get-tracks.sh prend en compte des erreurs courantes de typographie dans l’horodatage des pistes, telles que l’on peut en trouver dans des commentaires en ligne. Par exemple, un commentaire en ligne peut nommer des plages en incluant des caractères qui ne sont pas acceptables pour des noms de fichier comme le caractère /, ou des caractères non affichables.

Contraintes de développement

Je me suis efforcé à produire un outil :

avec des technos très répandues (sh, sed, awk, xxd, ffmpeg) ;
avec le moins de complexité possible (pas de langage dynamique « simple » codé en plus d’un million de lignes de code comme Python) ;
le plus simple possible à maintenir (chose réussie, en n’utilisant que des langages quasi gravés dans le marbre).

Le programme iconv n’est pas appelé, la suppression ou la modification des caractères UTF-8 non acceptables est faite à la main via xxd, sed et awk. Cela permet de ne pas dépendre de cet outil qui, au fond, ne nous est pas indispensable.

Pourquoi ?

Pourquoi avoir fait cet outil avec ces contraintes ? Pour voir où on pouvait aller avec des outils de base du système. J’ai utilisé des programmes qui sont sur nos ordinateurs depuis des décennies et qui répondent pourtant, encore et toujours, à des besoins actuels.

Je pense que le code peut servir d’exemple pour des développeurs débutants : il est très simple (en sh, awk, sed, et xxd), il y a un peu de gestion d’erreurs et je bidouille à la main du code UTF-8 (suppression des caractères qui nous gênent).

J’utilise régulièrement ce script, et je pense qu’il était temps que je le diffuse. Selon moi il peut servir à un paquet de gens.

Si vous voyez des améliorations possibles, n’hésitez pas à m’en faire part ou à contribuer ! Le code peut être compris même par des novices.

Aller plus loin

Page des sorties (65 clics)
Dépôt de code (120 clics)

# Recodage

Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 janvier 2022 à 10:15. Évalué à 10.

J'ai l'impression que ça recode l'audio, c'est à dire que s'il est compressé (MP3, Vorbis, Opus, AAC…), ça le décompresse, ça découpe, puis ça recompresse dans le format choisi. Je me trompe ?

Pour info, il existe des outils pour couper des fichiers audio sans les recoder, comme mp3splt pour les formats MP3, Vorbis et FLAC. Ffmpeg peut faire de même en utilisant le pseudo-codec copy, mais je ne sais pas si ça fonctionne avec un découpage.
- [^] # Re: Recodage
  
  Posté par karchnu le 24 janvier 2022 à 10:57. Évalué à 4.
  
  Oui, il est possible qu'il ré-encode pour le découpage, et oui on peut utiliser copy. Je ne m'étais pas trop posé la question jusqu'à présent. Peut-être que ffmpeg se met automatiquement en copy quand les fichiers d'entrée et de sortie sont dans le même format. Je n'ai jamais entendu de différence de qualité.
  
  En tout cas, je préférerai ne pas dépendre d'un autre logiciel que ffmpeg.
  - [^] # Re: Recodage
    
    Posté par Zenitram (site web personnel) le 24 janvier 2022 à 20:59. Évalué à 9.
    
    Je ne m'étais pas trop posé la question jusqu'à présent
    
    Ça mérite 36 méthodes de torture avant l'échafaud (je plaisante… Que quelques unes).
    Non, vraiment, stop à la destruction de qualité lors de traitement qui n'en nécessitent pas, c'est à faire en dernier recourt et pas par défaut.
    
    exemple caricatural pour montrer les dégâts que vous ne voyez pas.
    
    Je n'ai jamais entendu de différence de qualité.
    
    Ça ne veut pas dire qu'il n'y en n'a pas et que tu ne souffres pas inconsciemment de la chose.
    - [^] # Re: Recodage
      
      Posté par karchnu le 24 janvier 2022 à 21:17. Évalué à 4.
      
      Ha mais je suis parfaitement d'accord avec toi : il faut s'assurer que le programme ne ré-encode pas, et au moins indiquer une alerte si c'est impossible. Après avoir viré xxd des dépendances je m'occupe de ça.
      - [^] # Re: Recodage
        
        Posté par karchnu le 26 janvier 2022 à 17:15. Évalué à 3.
        
        Pour préserver la qualité du fichier de base, j'ajoute un paramètre de qualité.
        
        Par défaut, ce paramètre vaut -c:a copy, ce qui indique à ffmpeg de ne pas ré-encoder.
        
        Cela a pour effet de nécessiter le même format de fichiers en entrée et en sortie. Rien de trop contraignant, mais il faut peut-être que je bidouille pour garder le même format par défaut, plutôt que mettre un format fixe par défaut. Pour faire simple, il faudrait prendre l'extension du fichier audio fourni en paramètre. Tout le monde est d'accord, ou il y a mieux sans nécessiter une nouvelle dépendance ?
        
        [^] # Re: Recodage
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 26 janvier 2022 à 17:32. Évalué à 3.
        
        C'est parfait ça, c'est ce à quoi je pensais. Ça fonctionne bien avec un découpage ?
        
        [^] # Re: Recodage
        
        Posté par karchnu le 26 janvier 2022 à 17:36. Évalué à 2.
        
        J'ai pas vu de problème, et ça se copie de manière quasi instantanée vu qu'il n'y a pas de calcul.
    - [^] # Re: Recodage
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 25 janvier 2022 à 09:30. Évalué à 6.
      
      Un autre exemple caricatural : https://xkcd.com/1683/
      - [^] # Re: Recodage
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 janvier 2022 à 18:22. Évalué à 2.
        
        De case en case on sent la bande s'user (les moins jeunes, qui l'ont faite tourner au stylo et/ou utiliser des nettoyantes comprendront l'allusion.)
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: Recodage
  
  Posté par Stéphane Ascoët (site web personnel) le 24 janvier 2022 à 14:40. Évalué à 3.
  
  Ouaaah merci Tanguy, grâce à toi je viens de découvrir https://packages.debian.org/buster/mp3splt-gtk qui semble être un clone, volontaire ou pas, de mp3directcut, qui est la seule raison pour laquelle je lance encore un window$ NT de temps en temps chez moi! L'idéal serait qu'Audacity sache le faire aussi.
  - [^] # Re: Recodage
    
    Posté par Stéphane Ascoët (site web personnel) le 07 février 2022 à 15:19. Évalué à 1.
    
    Quelqu'un connaît-il un outil pour faire exactement la même chose, mais sur des vidéos?
    
    J'ai déjà réussi à le faire avec un bon vieux split bien rustique, mais, pour des raisons que j'igonore, certaines vidéos ne le supportent pas.
    - [^] # Re: Recodage
      
      Posté par Crao le 09 février 2022 à 10:45. Évalué à 2.
      
      Il y a avidemux en GUI, et mencoder en CLI.
# xxd

Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 janvier 2022 à 10:56. Évalué à 10.

On pourrait prendre soin d'éviter xxd avec le même soin qu'on évite iconv…
Pourquoi ? C'est un utilitaire qui vient avec ViM …qui n'est pas présent partout (l'auteur utilisant OpenBSD devrait savoir que, si ça n'a pas changé, ce n'est pas installé par défaut et qu'on a plutôt NVi par défaut.)
Quelle alternative ? Il y a hexdump qui est présent sur tous les Unix-like où j'en ai eu besoin (mais n'ayant pas vérifié partout je ne garantie pas sa présence systématique) et od qui doit toujours être disponible (parce-que dans la liste des commandes POSIX de base.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: xxd
  
  Posté par karchnu le 24 janvier 2022 à 11:21. Évalué à 5.
  
  J'aimerai bien utiliser od, mais je n'ai pas su lui faire sortir une entrée en une colonne hexadécimal. Je trouve cet utilitaire très bizarre d'ailleurs, je ne comprends pas le choix de mettre plein d'options pour spécifier une sortie octale avec 1, 2 ou 4 caractères par ligne, des options pour des sorties hexa avec 2 ou 4 caractères par ligne, une option -N pour ne convertir qu'un certain nombre de caractères là où on a déjà d'autres outils pour faire ça (comme head)… c'est un peu le foutoir.
  
  Du coup, si quelqu'un arrive à faire, avec des outils de base, l'équivalent de xxd -p -c 1 pour convertir l'entrée en hexa sur une seule colonne et xxd -p -r qui fait l'inverse, je suis preneur !
  
  Je suppose qu'il y a un coup à jouer avec od suivi de awk et sed si on serait joueur, mais c'est quand même plus long et pas très lisible, donc bon… j'hésite.
  - [^] # Re: xxd
    
    Posté par trautruf le 24 janvier 2022 à 11:55. Évalué à 3.
    
    od -A n -t x1 -v --width=1
    - [^] # Re: xxd
      
      Posté par karchnu le 24 janvier 2022 à 12:00. Évalué à 3. Dernière modification le 24 janvier 2022 à 12:00.
      
      Ton od a des extensions qui ne sont pas portables. Je n'ai pas --width par exemple.
      - [^] # Re: xxd
        
        Posté par trautruf le 24 janvier 2022 à 12:11. Évalué à 1.
        
        Ah … pourtant j'ai un bête gnu od et utilise l'option depuis longtemps.
        Bon, s'il faut aussi que ça tourne sur SunOS, en effet, ça va être dur :-)
        
        [^] # Re: xxd
        
        Posté par karchnu le 24 janvier 2022 à 12:20. Évalué à 3.
        
        Tout le monde n'est pas sous Linux, et même sous Linux tu n'es pas forcé d'utiliser les outils GNU. Là je suis sur OpenBSD et apporter un peu d'amour aux autres OS ne fait pas de mal.
        
        [^] # Re: xxd
        
        Posté par trautruf le 24 janvier 2022 à 12:29. Évalué à 2.
        
        OK, OK … dans ce cas, bon courage … j'espère que awk (par exemple) ne sera pas trop surprenant, vu qu'il y a également awk et gawk …
        
        [^] # Re: xxd
        
        Posté par karchnu le 24 janvier 2022 à 12:35. Évalué à 3.
        
        Comme dit dans la dépêche, j'ai testé mon script sur Alpine, Ubuntu et OpenBSD. À chaque fois ce sont des implémentations différentes de awk, mais elles ont le même comportement pour ce que j'en fais.
  - [^] # Re: xxd
    
    Posté par Tonton Th (Mastodon) le 24 janvier 2022 à 12:00. Évalué à 4.
    
    plein d'options pour spécifier une sortie octale avec 1, 2 ou 4 caractères par ligne, des options pour des sorties hexa avec 2 ou 4 caractères par ligne, une option -N pour ne convertir qu'un certain nombre de caractères là où on a déjà d'autres outils pour faire ça (comme head)… c'est un peu le foutoir.
    
    C'est parce que tu n'as jamais eu de pdp11 :)
  - [^] # Re: xxd
    
    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 janvier 2022 à 19:23. Évalué à 9. Dernière modification le 24 janvier 2022 à 19:27.
    une option -N pour ne convertir qu'un certain nombre de caractères là où on a déjà d'autres outils pour faire ça (comme head)…
    
    Pas compris… Je suppose que tu veux faire ceci avec head ?
```
$ cat nbr.txt
100
301
502
703
904
105
$ od -N4 -c nbr.txt
0000000    1   0   0  \n                                                
0000004
$ head -c4 nbr.txt | od -c
0000000    1   0   0  \n                                                
0000004
```
    Historiquement, head n'avait pas l'option -c d'une part, et il n'y avait pas d'éditeur de binaire Or il fait sens de vouloir examiner une portion déterminée sans devoir remplir tout l'affichage (rappelons-nous des petits écrans sans mémoire tampon pour garder plusieurs pages écran en mémoire tout ça)
    
    Pour la petite histoire, od existe depuis la v1 d'UNIX AT&T, tandis que head est apparu plus tard dans PWB UNIX…
```
$ od -j8 -N4 -c nbr.txt 
0000010    5   0   2  \n                                                
0000014
$ xxd -s8 -l4 nbr.txt
00000008: 3530 320a                                502.
$ od -j8 -N4 -x nbr.txt 
0000010      3035    0a32                                                
0000014
```
    Et c'est tellement inutile que même xxd permet de le faire ;D
    
    je ne comprends pas le choix de mettre plein d'options pour spécifier une sortie octale avec 1, 2 ou 4 caractères par ligne, des options pour des sorties hexa avec 2 ou 4 caractères par ligne
    
    En fait il y a deux notions, qui sont souvent liées quand on fait de la programmation : le (type de) format et la longueur. Cela correspond à signaler le type de données …non signé qui sont interprétés… sans quoi lui il ne sait pas trop à quoi correspond le binaire sous-jacent.
    
    Si tu ne manipules que des octets, les choix seront plutôt entre :
    -tuC ou -tu1 pour la base 10, -tdC ou -td1 pour la même en nombre signé, -toC ou -to1 ou -b pour la base 8, -txC ou -tx1 pour la base 16.
    
    l'équivalent de xxd -p -c 1 pour convertir l'entrée en hexa sur une seule colonne
    
    Bon, le manuel dit que -p c'est le « postscript continuous hexdump style » ou « plain hexdump styple » hum. Et -c pour indiquet le nombre d'octets affichets par ligne, au lieu de 16 par défaut.
```
$ echo test | xxd
00000000: 7465 7374 0a                             test.
$ echo test | xxd -p
746573740a
$ echo test | od -tx1
0000000    74  65  73  74  0a                                            
0000005
$ echo test | od -An -tx1
           74  65  73  74  0a
```
    Pour supprimer le compteur (je suppose que c'est ce que fait le style continue à la postscript), il faut utiliser -An
    Pour afficher des octets aussi en hexa aussi, j'utilise -tx1 Par défaut il travaille sur deux octets : -x ou -h ou -tx2 en hexa, -o ou -B ou -to2 en octal par défaut. Et quand on prend par paire l'ordre est un peu différent…
```
$ echo test | od -An -tx2
             6574    7473    000a                                        
$ echo test | od -An -tx1 | tr -d ' '
746573740a
```
    Par contre on ne sait pas agir sur le groupement, sauf avec l'implémentation GNU qui prévoit une option -w entre autres. Je pense que ce n'est pas grave vu que tu AWK après dessus ; sinon un pipe supplémentaire comme dans l'exemple pour virer les blancs.
    
    et xxd -p -r qui fait l'inverse
    
    OD et HexDump ne font pas l'inverse… Mais comme tu fais déjà du traitement avec AWK, peut-être utiliser sa faction chr (et ord dans l'autre sens ?) Je sais, c'est pas du jeu :-)
    
    “It is seldom that liberty of any kind is lost all at once.” ― David Hume
    - [^] # Re: xxd
      
      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 janvier 2022 à 18:42. Évalué à 5.
      et xxd -p -r qui fait l'inverse
      
      OD et HexDump ne font pas l'inverse… Mais comme tu fais déjà du traitement avec AWK, peut-être utiliser sa faction chr (et ord dans l'autre sens ?) Je sais, c'est pas du jeu :-)
      
      Petites notes sympas, vu que ce ne sont pas des fonctions natives (en tout cas pas requis par POSIX donc propre à l'implémentation si présente) : https://www.gnu.org/software/gawk/manual/html_node/Ordinal-Functions.html et https://helpmanual.io/man3/ordchr-am/
      
      C'est la première fois que j'entends parler du besoin de faire l'opération inverse dans un script ; du coup je suis allé regarder le source. Je ne suis pas sûr d'avoir compris ce que tu tentes de faire : pour du rechercher-remplacer il n'est pas besoin de passer par ce détour …à moins que ce ne soit des caractères trop particuliers ? (auquel cas méfiance…) S'il s'agit par contre de changer l'encodage, il n'y a pas de mal à faire appel à iconv dont c'est le boulot (et qui donc prend en compte un certain nombre d'autres paramètres.)
      En fait, quand il y a plusieurs solutions possibles j'aime plutôt permettre au script de s'adapter en conséquence (il y a de grande chance que l'un des deux outils soit installé, et si c'est pas le cas on fait avec) :
      
      if command -v iconv >/dev/null ; then # traitement avec iconv... elif command -v xxd >/dev/null ; then # traitement avec xxd... else # p-o-c qu'on peut faire sans l'un ni l'autre # ou arret avec message d'erreur clair # ou traitement degrade avec avertissement fi
      
      “It is seldom that liberty of any kind is lost all at once.” ― David Hume
    - [^] # Re: xxd
      
      Posté par karchnu le 25 janvier 2022 à 19:02. Évalué à 6. Dernière modification le 25 janvier 2022 à 19:03.
      Très bien, affûtons notre unix-fu.
      
      Traduction de xxd -p -c 1
      
      En premier, il nous faut une traduction d'une entrée quelconque en une colonne hexa. Tu l'as pratiquement donnée avec od, mais il manque de mettre les valeurs en colonne.
      
      # Convert input into hexadecimal and a single byte per line. to_hex_one_column() { od -An -tx1 | awk '{for(i=1;i<=NF;i++){ print $i }}' }
      
      Traduction de xxd -p -r
      
      Maintenant, (presque) l'inverse avec tr, bc (et dc), od et awk. « Presque » car l'entrée n'est pas sur une seule colonne, puisque je regroupe des caractères pour traiter l'UTF-8. Je mets tous les caractères d'une ligne sur une seule ligne. L'entrée peut ressembler à ceci :
      
      61 62 0a 63 64 0a
      
      Et là, on aimerait bien passer tout ça à awk pour qu'il traduise ça en caractères affichables via sa fonction printf. Mais il lui faut un nombre en base 10 et je sais pas traduire l'hexa facilement avec awk (hors version GNU), donc on va passer par quelques étapes supplémentaires.
      
      Première chose à faire, remettre tout ça en une seule colonne : tr " " "\n".
      
      Ensuite, on veut passer l'entrée à bc (et par conséquent à dc) pour qu'il convertisse l'hexadécimal en décimal. Attention, bc est sensible à la casse, donc il faut mettre l'hexadécimal en majuscules :
      
      uppercase() tr "[a-z]" "[A-Z]"
      
      Maintenant la conversion avec bc :
      
      # One col hexa to one col decimal. from_hex_to_decimal() { { echo "obase=10;ibase=16;" ; cat ; } | bc }
      
      Et enfin, on fait la traduction décimal -> caractères UTF-8 avec awk et sa fonction printf.
      
      # One col decimal to plain text. from_dec() awk '{ printf ("%c", $1 + 0) }'
      
      Et donc la fonction complète qui passe de l'hexadécimal à la sortie finale :
      
      # Reverse hexadecimal (with space separators) to original value. from_hex() { tr " " "\n" | uppercase | from_hex_to_decimal | from_dec }
      
      Je ne sais pas trop quoi penser du résultat. Je l'ai testé et ça semble fonctionner, mais est-ce suffisamment « simple » ? Est-ce qu'on aurait pas plus simple encore ?
      - [^] # Re: xxd
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 janvier 2022 à 19:54. Évalué à 5. Dernière modification le 25 janvier 2022 à 19:57.
        
        Dans cet enchainement :
        
        tr " " "\n" | uppercase
        
        …tu peux combiner les deux en une opération
        
        tr "[a-z] " "[A-Z]\n"
        
        …et le test est concluant :
        
        $ cat hex.txt 61 62 0a 63 64 0a $ cat hex.txt | tr "[a-z] " "[A-Z]\n" 61 62 0A 63 64 0A
        
        Et là, on aimerait bien passer tout ça à awk pour qu'il traduise ça en caractères affichables via sa fonction printf.
        Mais il lui faut un nombre en base 10 et je sais pas traduire l'hexa facilement avec awk (hors version GNU),
        
        Bien vu pour printf. Le "truc" est juste de lui passer une chaîne déjà en hexa …en forçant la chaîne de caractères à être lu comme un nombre hexa…
        
        printf "%d\n", (("0x" $1) + 0)
        
        Vérification…
        
        $ echo "obase=10;ibase=16; 61" | bc 97 $ echo "61" | awk '{ printf "%d\n", (("0x" $1) + 0) }' 97 $ cat hex.txt | tr "[a-z] " "[A-Z]\n" | awk '{printf "%d\n", (("0x" $1) + 0)}' 97 98 10 99 100 10
        
        Tu étais donc sur la bonne voie ; j'y aurais pas pensé à ce détour tout seul.
        
        Est-ce qu'on aurait pas plus simple encore ?
        
        [edit] Du coup, on peut combiner from_hex_to_decimal | from_dec pour la route :D
        
        $ cat hex.txt | tr "[a-z] " "[A-Z]\n" | awk '{printf "%c", (("0x" $1) + 0)}' ab cd
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: xxd
        
        Posté par karchnu le 25 janvier 2022 à 20:09. Évalué à 4.
        
        […] tu peux combiner les deux en une opération […]
        
        Alors, oui, c'est parfaitement valide. En revanche, c'est un poil moins lisible.
        
        Je verrai plutôt tr " " "\n" dans une fonction avec un nom explicite, pour pouvoir enchaîner des fonctions avec un nom lisible par un humain, quelque-chose comme to_single_column | uppercase.
        
        Bien vu pour printf.
        
        Je n'ai aucun mérite. C'est l'implémentation de chr sur mon système. :D
        
        awk '{printf "%c", (("0x" $1) + 0)}'
        
        Malheureusement, cette astuce ne fonctionne pas sur OpenBSD. Je suppose que la gestion de l'hexadécimal est une extension GNU…
        
        [^] # Re: xxd
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 janvier 2022 à 21:56. Évalué à 4. Dernière modification le 25 janvier 2022 à 22:00.
        
        J'ai fait le test sur un Mac et cet outil là ne semble pas être une implémentation GNU
        
        $ type awk awk is hashed (/usr/bin/awk) $ ls -l /usr/bin/awk -rwxr-xr-x 1 root wheel 334944 Dec 8 00:39 /usr/bin/awk $ type gawk -bash: type: gawk: not found $ awk --version awk version 20200816
        
        Le manpage ne dit pas quelle implémentation c'est non plus, mais de mémoire c'est nawk comme sur d'autres BSD. Je vérifierai sur un autre poste où j'en ai d'autres (mawk et nawk entre autres) ce qu'il en est du comportement par rapport aux hexa. Et surtout voir ce qui est attendu au niveau de la norme…
        
        Peut-être qu'il faut lui forcer la main avec strtonum() ?
        
        Sinon, la façon un peu bourrin de faire la conversion ressemblerait à (non testé) :
        
        for (x=1;x<=length($1);x++){ digit=index("123456789abcdef",substr($1,x,1)); number=number*16+digit} print number
        
        Pendant que j'écrivais je viens de me rappeler qu'on va parfois chercher loin ce qui est à portée de main… L'expansion arithmétique d'un shell POSIX connait l'hexa en entrée mais retourne tout en décimal (test suivant fait avec Bash, Zsh, Dash pour m'en assurer) :
        
        $ echo $((0x61)) 97 $ x='0xE'; printf "%d %d %d" $x "$x" $((x + 1)) 14 14 15
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: xxd
        
        Posté par karchnu le 25 janvier 2022 à 22:15. Évalué à 3.
        
        strtonum()
        
        Extension GNU.
        
        script awk
        
        Ne fonctionne pas.
        
        echo $((0x61))
        
        Je viens de tester avec /bin/sh sur OpenBSD. Ça fonctionne. Et je ne vais quand même pas l'utiliser : bc et dc font ça très bien, ils sont même plutôt fait pour et sont efficaces. En plus, ça se gère naturellement dans un script shell, c'est un simple filtre.
        
        [^] # Re: xxd
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 janvier 2022 à 22:30. Évalué à 3.
        
        Je verrai plutôt tr " " "\n" dans une fonction avec un nom explicite, pour pouvoir enchaîner des fonctions avec un nom lisible par un humain, quelque-chose comme to_single_column | uppercase.
        
        Il faut résister à la tentation de faire des fonctions pour dix à quinze caractères, sauf si la fonction est vraiment réutilisée plusieurs fois… En groupant, ce n'est pas moins lisible, je trouve, et si en prime c'est commenté (juste par "to single column And to upper case" ou un truc du genre) c'est meilleur.
        C'est d'ailleurs parce-que tr est plus simple et plus lisible sur ce coup que je n'ai pas poussé…
        
        # tr " " "\n" awk -v RS=" " '{print}' # tr "[[:lower:]]" "[[:upper:]]" # AWK is better with accentuated locales awk '{print toupper($0)}' # tr "[a-z] " "[A-Z]\n" awk -vRS=' ' '{print toupper($0)}' # tr "[a-z] " "[A-Z]\n" | awk '{printf "%d\n", ("0x" $1)}' # hexa in AWK is in fact case-insensitive awk -vRS=" " '{printf "%d\n", (("0x" $1) + 0)}'
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: xxd
        
        Posté par karchnu le 25 janvier 2022 à 22:50. Évalué à 3.
        
        Pourquoi résister à la tentation de faire des fonctions d'une ligne ? Je trouve ça tellement plus lisible plutôt que d'essayer de comprendre ce que fait chaque appel. C'est également moins cryptique pour ceux qui ne font pas d'unix tous les jours, ils peuvent même apprendre en lisant simplement les noms des fonctions.
        
        Aussi, deux appels à tr au lieu d'un c'est pas grave si ça améliore la lisibilité : une fonction ne fait qu'une chose. J'optimise uniquement quand c'est nécessaire et que ça ne nuit pas à la lisibilité. Je défie quiconque de me justifier devoir supprimer un appel à tr parce que c'est trop coûteux niveau perfs pour lire un document de 20 lignes. :D
        
        awk '{print toupper($0)}'
        
        Peu importe si ça fonctionne mieux avec les accents, on travaille sur de l'hexa. ;)
        Du coup, tr étant l'outil le plus simple, il est prioritaire.
        
        awk -vRS=" " '{printf "%d\n", (("0x" $1) + 0)}'
        
        Ça ne fonctionne pas sur OpenBSD. Nous n'avons pas la même implémentation de awk.
# Votre avis m'intéresse

Posté par karchnu le 24 janvier 2022 à 16:21. Évalué à 8. Dernière modification le 24 janvier 2022 à 16:21.

Salut à ceux qui votent négativement sur cette dépêche. N'hésitez pas à dire pourquoi. Est-ce que la dépêche ne rentre pas dans le cadre du site ? Est-ce que vous avez un problème technique avec ce que je propose ? Est-ce que la dépêche est mal écrite ? Exprimez-vous.
- [^] # Un sage a dit
  
  Posté par tisaac (Mastodon) le 24 janvier 2022 à 17:34. Évalué à 6. Dernière modification le 24 janvier 2022 à 17:34.
  
  Un sage a dit:
  
  Pour vivre heureux, n'essaie pas de comprendre les votes pertinent et surtout inutile sur LinuxFR.
  
  Après, on n'est pas obligé d'être sage ;-)
  
  Surtout, ne pas tout prendre au sérieux !
  - [^] # Re: Un sage a dit
    
    Posté par karchnu le 24 janvier 2022 à 17:43. Évalué à 5. Dernière modification le 24 janvier 2022 à 17:44.
    
    Je suis trop soucieux de bien faire, et j'ai peur de simplement avoir raté quelque-chose d'important. Par exemple un logiciel qui ferait déjà exactement ce que je fais avec get-tracks.sh, rendant mon travail inutile.
    
    C'est possible que les votes négatifs ne soient pas rationnels, ça ne serait pas la première fois que ça m'arrive sur linuxfr. J'ai encore des souvenirs du premier commentaire de l'article sur mon service netlib.re… mais sans demander, je peux pas savoir. Et je suis curieux. :-)
    - [^] # Re: Un sage a dit
      
      Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 24 janvier 2022 à 19:28. Évalué à 7.
      
      Un certain nombre de votes, négatifs ou positifs ne sont pas rationnels, je vois ça sur les liens (c'est ce qu'il y a de plus facile à voir). Rationnels dans le sens : la pertinence ou l'inutilité ne sont pas forcément liées à la thématique de LinuxFr.
      
      Il est possible, et j'avouerais que je suis dans ce cas-là (mais j'ai voté pour la publication de la dépêche), que certains et certaines se demandent finalement l'intérêt de la manip, ce qui est susceptible d'engendrer des votes inutiles.
      
      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# YouTube ?

Posté par O'neam Anne le 24 janvier 2022 à 19:31. Évalué à 3.

Le format du fichier ressemble fortement aux descriptions YouTube pour les vidéos contenant un album de musique entier.
Est-ce que c'est ça le cas d'utilisation typique de get-tracks.sh ? Télécharger une de ces vidéos, extraire la bande sonore, et re-découper en fichiers l'album ?

LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
- [^] # Re: YouTube ?
  
  Posté par karchnu le 24 janvier 2022 à 20:01. Évalué à 3. Dernière modification le 24 janvier 2022 à 20:03.
  
  J'ai des CD en un fichier audio, et get-tracks.sh m'aide à les découper. Le format du fichier texte a été choisi car très répandu, et oui c'est ce qu'on retrouve, entre autres, dans la gestion des marqueurs de temps chez certaines plateformes comme Youtube.
  
  L'obtention à la fois du fichier audio et des marqueurs de temps ne sont pas mon affaire. Je n'encourage pas cet usage qui est illégal (sauf si l'album, ou le contenu d'une manière générale, est publié en libre). Cependant, oui, ça fonctionnerait.
  - [^] # Re: YouTube ?
    
    Posté par O'neam Anne le 25 janvier 2022 à 00:06. Évalué à 2.
    
    Par curiosité, comment est-ce que tu t'es retrouvé à avoir des CD rippés sous la forme d'un unique fichier audio ? C'est inhabituel !
    
    LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
    - [^] # Re: YouTube ?
      
      Posté par karchnu le 25 janvier 2022 à 00:12. Évalué à 4. Dernière modification le 25 janvier 2022 à 00:13.
      
      Vieux rip, je ne sais plus quel outil j'avais utilisé. Mes débuts avec Linux, il y a 15 ans. Et quelques trucs trouvés sur le net entre temps, que j'ai depuis trop longtemps pour me souvenir d'où ça vient.
      - [^] # Re: YouTube ?
        
        Posté par dtrystram le 28 janvier 2022 à 23:11. Évalué à 4.
        
        De mon côté, il y a presque 25 ans, je rippais mes vinyls via la carte son de l'ampli de ma chaine, en gros fichier wav, et du coup en un seul morceau (enfin 2, car 2 faces !), et il existait une application (gramofile) en mode texte/console, laquelle application repérait (pas très bien d'ailleurs) les instants silencieux pour découper en morceaux, et il fallait moultes réglages pour que cela marche (entre pas assez de morceaux, pas assez découpés donc, ou trop de morceaux trop découpés… ). Ici ce script est probablement plus efficace !
        
        [^] # Re: YouTube ?
        
        Posté par dtrystram le 29 janvier 2022 à 11:56. Évalué à 3.
        
        Et gramofile compile toujours sur une debian 10 ordinaire
        
        [^] # Re: Découper les plages dans une longue séquence audio numérisée
        
        Posté par Stéphane Ascoët (site web personnel) le 07 février 2022 à 15:22. Évalué à 2.
        
        J'ai résolu ce problème vers 2002 avec Audacity grâce à un cours-pas-à-pas publié par Framasoft(qui m'a fait découvrir cet outil du même coup, ce qui a pas mal changé ma vie)
# Suite aux différents commentaires.

Posté par karchnu le 26 janvier 2022 à 13:31. Évalué à 8.
Voici la liste des changements apportés au script depuis la publication :
- suppression de la dépendance à xxd, remplacé par des appels à tr, awk, bc
- README : prise en compte du changement précédent
- divers changements de noms de fonctions
- commentaires (un peu) plus explicites dans le code
- un </dev/null a été déplacé d'un appel à ffmpeg à bien plus haut dans la pile d'exécution, dans le bloc while read X; do ... done où le problème apparaît (pour rappel : cette construction de code implique qu'un sous-shell peut lire ce qui doit être en entrée du while read à sa place)
Certains de ces changements étaient prévus, d'autres font suite à des commentaires pertinents.

N'ayant plus de dépendance à xxd, une nouvelle sortie voit le jour.

Reste à faire
1. s'assurer de ne pas avoir de perte de qualité audio lors de l'extraction des plages
2. Si 1. n'est pas possible, l'indiquer via une alerte.
- [^] # Re: Suite aux différents commentaires.
  
  Posté par karchnu le 26 janvier 2022 à 21:31. Évalué à 10.
  Aux nouvelles :
  - il n'y a plus de ré-encodage par défaut
  - il y a une nouvelle variable d'environnement FFOPTS qui permet de passer des options à ffmpeg (notamment quand il y a effectivement besoin de ré-encoder)
  - le README contient quelques informations concernant la nouvelle option, ainsi que la description de différentes situations
  Maintenant qu'il n'y a plus de ré-encodage par défaut et que le script n'utilise plus que des outils POSIX, je considère l'application stable. Je la sors donc en v1.0.
  
  Merci à ceux qui ont participé ! N'hésitez pas si vous avez d'autres suggestions.
# Définition de « piste »

Posté par idlusen le 26 février 2022 à 16:05. Évalué à 1. Dernière modification le 26 février 2022 à 16:05.

Script intéressant, mais je suis un peu déçu, à la lecture du titre j’ai cru à de la séparation de source automatique ;-)