Styles

jeudi 14 juillet 2011

Linux - Comment convertir des vidéos MP4 (YouTube, DailyMotion...) en MP3 en leur appliquant un gain normalisé à 89dB (ReplayGain)

Les sites d'hébergement de vidéos comme YouTube ou Dailymotion contiennent un grand nombre de vidéos correspondant à de la musique : soit des clips vidéo, soit uniquement la musique et des photos statiques en guise de vidéo. Il peut être intéressant de récupérer la musique de ces vidéos et d'en faire des fichiers audio pour les écouter sur votre lecteur audio préféré.

Tout d'abord il faut télécharger les vidéos de YouTube ou Dailymotion sur votre disque dur au format MP4. Pour cela vous pouvez utiliser les nombreuses extensions de votre navigateur préféré vous permettant de faire cela. Sous Firefox, j'utilise Video Download Helper. Sous Chromium, j'utilise Easy YouTube Video Downloader.

Attention à ne pas utiliser le nom de fichier d'enregistrement par défaut proposé par ces extensions car il y a souvent des caractères spéciaux qui ne sont pas forcément supportés par votre système de gestion de fichier.

Dans le cas de Easy YouTube Video Downloader, le nom de fichier par défaut contient en premier caractère, un caractère spécial invisible à l'oeil nu mais pourtant bien présent (je le vois avec Dired sous Emacs). Pour être sûr de ne pas avoir de problème, renommez ENTIÈREMENT le fichier. Dans XFCE Thunar par exemple, sélectionnez le fichier et faites la combinaison de touches suivante : F2 Ctrl-a Suppr. Puis saisissez votre nom de fichier.

Vous êtes sous Linux Ubuntu, vous voulez convertir un ensemble de fichier vidéo MP4 provenant de YouTube ou Dailymotion, en fichier audio MP3. Vous voulez aussi que le niveau sonore de vos MP3 soit normalisé à 89dB tel que défini par ReplayGain.
Cette normalisation est importante pour éviter de devoir monter ou baisser le niveau sonore de votre lecteur de MP3 à chaque changement de morceau.

Tout d'abord, installez les modules suivants via le Gestionnaire de Paquets Synaptic :

- ffmpeg
- sox
- libsox-fmt-all
- mp3gain

Ensuite, créez vous un fichier MP4toMP3 avec le contenu suivant :

#!/bin/sh
for i in *.mp4; do
echo "$i"
ffmpeg -i "$i" -vn -acodec copy "${i%mp4}m4a"
sox "${i%mp4}m4a" "${i%mp4}mp3"
rm "${i%mp4}m4a"
mp3gain -c -r "${i%mp4}mp3"
done


Donnez les droits d'exécution à ce fichier :
chmod a+x MP4toMP3

Et voilà ! Placez vous dans le répertoire qui contient vos MP4 et lancez ce fichier de script MP4toMP3. Le script va convertir tous les fichiers MP4 du répertoire en MP3 et appliquer un gain normalisé à 89dB (ReplayGain).

Attention, il s'agit bien de l'application du gain sur tout le fichier, pas du stockage d'un "tag" REPLAYGAIN dans le fichier MP3. Comme cela, le fichier a le même niveau sonore quelque soit le lecteur MP3, même si ce dernier ne supporte pas la norme ReplayGain.

Vous pouvez maintenant lire tous ces fichiers audio avec votre lecteur MP3 préféré.

vendredi 1 juillet 2011

Apache Ant/Ivy versus Maven : Quel outil de construction maîtriser sur le long terme ?

Un projet démarre toujours un peu dans l'euphorie, et bien souvent dans le stress dès la première minute où vous vous rendez compte que vous êtes en retard sur les échéances dès la réunion de lancement du projet avec votre client.

Dans ces conditions, il est déjà intéressant d'avoir dès le début du projet, un squelette d'application "vide" mais "fonctionnant", du code et tout son outillage (son attirail) s'exécutant sans aucune fonctionnalité particulière.

On veut tous passer du temps à ajouter des fonctionnalité à un logiciel, pas perdre son temps à mettre en place une architecture standardisée comme Oracle Java EE par exemple. L'avantage d'un tel standard est de proposer des briques et des protocoles standards pour la plupart des applications d'entreprise : une couche présentation (JSF, Struts), une couche métier (EJB3), une couche de persistance (JPA2), des modèles de conceptions tout prêt à être utilisés (Java blueprints), etc.

Ce qui fait que pour la plupart des applications d'entreprise, c'est à dire de gestion de l'information, il n'y a même plus à concevoir quoique ce soit : il ne reste plus qu'à programmer les règles métier et le fonctionnel. Il s'agit d'ailleurs de plus en plus de "configuration" ou de "génération" des composants standards et outils "sur étagère" plutôt que de "programmation" proprement dite.

C'est à la fois une bonne chose (la réutilisation se généralise) et une moins bonne chose pour l’ingénieur en informatique: la conception devient un art mineur et rare dans le monde de l'entreprise. Ce qui a pour conséquence d'offrir de plus en plus de travail à des techniciens et analystes métiers, plutôt qu'à des ingénieurs. Architecte Java ne veut maintenant plus rien dire si ce n'est pour désigner quelqu'un qui connait l'architecture standard Java et sait la mettre en place. Ce n'est plus quelqu'un qui conçoit, mais quelqu'un qui applique. Un architecte logiciel à proprement parlé n'est et ne doit pas être lié à des standards : il doit être capable de définir l'architecture adéquat à un besoin donné en respectant toutes les contraintes qualités qu'on est en droit d'attendre aujourd'hui d'une application logicielle.

Dans ce contexte, il est important de maîtriser à fond quelques outils qui seront présents quelque soit le type de logiciel. Il s’agit de tous les outils de développement : EDI, outils de construction, outils d’analyse de la qualité du code, outils de tests du code, outils de gestion des versions, d’intégration continue. Il est intéressant de passer du temps à maîtriser complètement ces outils, car ils ne seront pas remis en cause dans une dizaine d’année.

Pour ma part, dans le monde Java, je me suis concentré sur les outils suivants : Apache Ant et Ivy, JUnit, Checkstyle, PMD, Jenkins et les bibliothèques standards de la version Java SE.

De plus, j’essaie de maîtriser complètement mon EDI préféré : Emacs.

Par contre, même des technologies dites standards, ne le seront plus au bout de 5 ans, comme par exemple les technologies suivantes qui sont devenus obsolètes :

- toute la couche client de Java SE (AWT, Swing, Java Sound, Java2D, Applets, ImageIO, Accessibility) est maintenant remplacée par JavaFX 2.

- toutes les vieilles couches serveur sont obsolètes : EJB 1 et 2 remplacées par EJB3, les anciennes version d’hibernate remplacées par JPA, même Spring devient obsolète face à JSR-330 (supporté par Spring après coup via des astuces) et de nouveaux frameworks qui suivent cette nouvelle norme comme par exemple Google Guice.

Et bien sur, tout ça sera à revoir dans 5 à 10 ans. Ce qui fait tout drôle aux nouveaux venus dans le monde de l’entreprise informatique, c’est qu’ils vont être confronté à de nombreuses applications qui n’auront même pas franchi le gouffre entre Java 1.4 et Java 5. De nombreuses applications Java peuvent maintenant être appelées des « application legacy » au même titre que des applications codées en Cobol.

Il faut donc s'attendre à tout et maîtriser des outils suffisamment souples, extensibles et personnalisables pour s'adapter à tout type de situation. Ce qui ne va pas dans le sens des outils qui se basent surtout sur des "conventions" plutôt que sur de la configuration, comme par exemple Maven qui structure déjà un projet Java.

Dès que vous sortez de la convention et du comportement standard des plugin Maven, vous allez devoir hacker un plugin Maven pour vous adapter à votre contexte projet. Maven est intéressant pour démarrer un projet rapidement mais dès qu'un projet se complexifie, il y aura toujours des tâches très spécifiques et "tordues" à accomplir. C'est le propre d'un projet qui a son identité propre : si ce n'était pas le cas, ce ne serait pas un projet de développement, mais uniquement un projet de génération de code ou d'installation de composants sur étagère.

Mon vécu sur les outils Ant/Ivy et Maven m'a appris que Ant, par sa simplicité, sa personnalisation, son extensibilité et sa simplicité permet de survivre à des projets complexes et historiquement chargés. Maven, (considéré par certains comme l'EJB2 des outils de construction) permet de démarrer rapidement des projets complets sans avoir à se poser trop de questions sur comment est construit réellement le logiciel. Mais avec le temps qui passe, on est toujours confronté à ces questions précises sur ce qui se passe réellement en arrière plan, et comment changer ces détails.

Bref, Maven me semble aller dans le sens inverse du principe KISS. De plus Ant/Ivy est aussi "puissant" et générique qu'on le souhaite si on passe ne serait-ce que le temps d'un seul livre, à apprendre ce qu'il est capable de faire :

Ant In Action est un bon livre sur Apache Ant/Ivy et va jusqu'au bout de la logique de Ant pour montrer qu'on peut tout faire avec et ce en faisant un minimum d'adhérence aux spécificités d'un projet. J'ai adoré construire de bout en bout un fichier build très simple mais très puissant et surtout très lisible : je suis capable de faire tous les types de traitement que je souhaite et réutiliser mon fichier build.xml dans chacun de mes projets.