Blog graphique 2

中文 Français English

Depuis que chrome à eu la mauvaise idée d’ajouter dans chrome et Chromium des règles spécial neuneu par défaut, ne permettant plus ainsi de comprendre ce qui se passe, l’équipe de Mozilla Firefox s’est sentie obligée de faire de même avec Firefox. Voici au moins 3 changements relativement indispensables à appliquer dans

about:config

Pouvoir copier les caractères non-anglais depuis la barre d’URL :

network.standard-url.escape-utf8 = false

Ne plus cacher le protocol (HTTP/HTTPS/FTP/…) :

browser.urlbar.trimURLs = false

Ne plus griser la majorité de l’URL :

browser.urlbar.formatting.enabled = false

Bonus

browser.tabs.onTop = false

D’autre paramètres utiles ici

URL : about:config

chercher

network.standard-url.escape-utf8

changer

network.standard-url.escape-utf8=true =>
network.standard-url.escape-utf8=false

OK !

Cadeau bonus, pour mettre le cache en ram (pour /tmp monté en /tmpfs afin d’éviter l’usure prématurer d’un SSD et d’accelerer la lecture du cache)

browser.cache.disk.parent_directory = /tmp

I was on wikipedia uploading a picture taken in wagang (瓦缸, a big jar) restaurant, I then searched appropriated category on commons for french term “jarre”, and found it was about english term “jar” that is today translated by “bocal” in french. In french jarre is more about big container like chinese wagang or greek phitos, searching to sort and categorize some commons pictures, and found a picture about women trading jarres in Gorom-Gorom market. Gorom-Gorom is a Burkina Faso trade city for nomads of South Sahel (in Burkina Sahel Region. I immediatly think about geotag the picture, using OSM url => {{Location dec}}/{{Object location dec}} wikipedia commons tags.

You can simply do this by taking Openstreetmap url in two step :
1. Click on the place you want the geoposition.
2. Click on permalink, you will get an URL like :

* http://www.openstreetmap.org/?lat=14.445&lon=-0.2326&zoom=12&layers=M

3. Extract lat=$lat and lon=$lon values and paste it in :
* {{Location dec|$lat|$lon}}, here : {{Location dec|14.445|-0.2326}}
for camera position, and :
* {{Object location dec|$lat|$lon}}, here : {{Object location dec|14.445|-0.2326}}
for object position.

Well, this was not really precise, no aerial photography of the place, only satellite one. But I moved a little and seen, that now, big parts of Burkina Faso have aerial photography on Bing Imagery layer for Potalatch (the web OSM editor).

I then started to route some roads, street and water pieces. This is unusual to draw tracks in desert for me, that mostly drawn, the 2*2 to 2*5 lanes (+2 sides lanes and footway and bikeways) asphalted streets in China. In this countries all road are one lane for two ways.

Here are some information I noticed, that could help other OSMers to draw thoses areas (Sahel in some poor sub-saharian countries) :

In most of the Burkina Faso, the tag higwhay=track should be avoided, as most road but perhaps 10 national roads are not in asphalt. They should be classified by distance and function. Perhaps trunk for national (only one asphalted), primary for biggest intercity roads, secondary for smaller cities intercity roads, etc…

* In the Sahel region (North East of the Burkina Faso), most roads are only tracks slightly browner or marked by stones along the sides of the road. There is bush areas and pure sand areas.

* In the Sahel region, water of the rivers are rarely seen from sky, only a slightly more green area indicate there is water underground.

* Markoye, in the far North of the Burkina Sahel Region, as most Burkina small cities in this region, that’s not easy to trace. I question myself to know if that’s better to draw roads on lighter parts of the streets (because of sand moved by feets ?), or to only draw houses, walls and trees, possible ways then appear by themselves. Is there any local code about what is in the family house, and what is outside ? I will probably ask soon to Burkinabe friends.

* For the fun, at Markoye, there is 2 natural lakes, and an artificial water lake, looking like a square Speech balloon (phylactère) lake:

I after that moved in Ouagadougou, the capital, in Centre Region, and its green tropical area, the roads are often destroy by water here, there is big ponds in the middle of the raod, but this is generally more easy to trace :

Après le précédent billet sur le contrôle à distance des reflex numériques sous Linux avec GTKam voici une vidéo de la même fonctionnalité avec l’excellent Entangle. Ici sur ce site (Ogg video) ou sur .

MP4 / OGV:

Attention, en cours de rédaction
This post also exists in English
Comme dans un billet précédent, je parlais de la traduction des sous-titres, je vais parler aujourd’hui des noms des chansons et paroles internationales dans les morceaux de musiques.

Je n’ai pas encore trouvé d’outil complet, mais plutôt des briques spécialisées.

Les tags
* eyeD3 est un outil de gestion des tags, permettant différents encodages de caractères dont l’UTF-8.

Le problème (explication un peu longue)

Le problème avec de nombreux tags, c’est qu’en raison des anciens systèmes qui n’avaient pas de technique d’encodage internationale, telle que le propose l’UTF-8,UCS transformation format – 8 bits, terme générique qui par abus de langage, regroupe les encodages UTF-8 et dérivés, UTF-16 (16 bits) et UTF-32 (32 bits), étaient encodées dans les encodages locaux.

Un fichier était alors encodé, pour le mieux en iso local (iso-8859-1 ou iso-8859-15 pour l’Europe de l’Ouest par exemple), pour le pire en encodage Windows (Microsoft tentant de casser les standards pour s’approprier d’avantage de clients, et empêcher ainsi l’innovation qui lui coute cher en développement et réduit les marges). En Chine, c’est encore pire, entre le continent qui à 3 ou 4 encodage du chinois simplifié, Taïwan, Hong-Kong ou Macao qui ont leurs différents standards d’encodage du chinois traditionnel. On peut imaginer le casse tête en Inde qui à un nombre incroyable d’écritures, ou pour les Mongolophones qui ont différents systèmes d’écriture selon le pays dans lesquels ils se trouvent (Mongolie, Mongolie intérieur en Chine ou Tibet, Russie, etc…).

En bref la volonté de l’UTF-8 a donc été d’unifier tout ça. Le problème est que les différents développeurs des différentes régions du monde ne se sont pas encombrés à ajouter un champ qui préciserait l’encodage utilisé dans leur format de donnée, du coup, c’est un vrai casse tête pour unifier tout ça et du coup il existe encore aujourd’hui des applications bornées à leurs encodages locaux qui tentent tant bien que mal de les détecter.

J’écoute personnellement pas mal de musique chinoise et en général d’Asie, et me trouve confronté a un casse tête à chaque fois que je récupère un nouveau morceau sur les sites spécialisés pour en trouver l’interprète, l’album ou tout simplement le titre… Heureusement aujourd’hui, tous les systèmes (Linux et autres UNiX, *BSD*, Wndows, Mac) utilisent tous l’UTF-8 par défaut, et une majorité grandissante d’applications l’utilisent par défaut.

La solution
En général, je cite l’exemple chinois, mais cela peut fonctionner avec les autres langues, je teste les encodages les plus utilisés pour décrypter le titre (si le fichier à un nom dans une langue quelconque en écriture latine).

Une technique pas mal est la suivante :
id3v2 -l fichier.mp3 | grep -v mp3 | iconv -f gbk -t utf8

* id3v2, que l’on trouve sur la majorité des distros, sort les tags du fichier.
* Le grep retire (-v) le nom du fichier.mp3 (au cas où il soit encodé dans un encodage différent, ce qui bloquerait le transcodage du reste).
* iconv fait la conversion du (from) gbk vers le (to) utf8, si cela ne ressemble pas au titre, est illisible ou est beaucoup plus long que cela devrait, il y a déjà des chances pour que ce soit le mauvais encodage.

Un indice pour avoir la liste des encodage. Mozilla/firefox permet d’afficher les encodages les plus courants pour une langue, graçe au menu : Affichage => Encodage des caractères => Plus d’encodages => Région => pays (encodage 1), pays (encodage 2),…

* Pour le chinois simplifié, souvent gb2312, gbk, moins souvent, gb18030, hz, iso-2022-cn, …
* Pour le chinois traditionnel, souvent big5, gbk, moins souvent, euc-tw, big5-gkscs, …

Une fois qu’on a trouvé le bon encodage, on garde les infos dans un coin.

On peut extraire les images intégrées (couverture etc…) avec :
eyeD3 --write-images=/mon/répertoire/

On nettoie ensuite tout ça à l’aide de eyeD3 :
eyeD3 --remove-all fichier.mp3

Et on réinsert en utf8
eyeD3 --set-encoding=utf8 --title 'trucbidule' --artist 'Machin Grochanteur' --album 'Grolanderie' --track 51 --year 2012 --genre 13 51.trucbidule.mp3
* title : titre
* track : piste
* year : année
* genre : style de musique 13: pop, 75: Polka, 137: Heavy Metal etc… (eyeD3 -l affiche la liste complète)
* Le nom du fichier est donné en dernier.

Il permet également d’y intégrer une image (couverture, dos de jaquette, etc…)
eyeD3 --add-image=/mon/fichier.jpg:COVER:"ma belle image"

Ajoute l’image situé dans le chemin /mon/fichier.jpg, COVER est le type (couverture; eyeD3 –list-image-types pour la liste)

Le problème d’EyeD3 est qui’il ne permet pas de gérer les différents formats de lyrics, on en vient donc à LrcShow-X…

* LrcShow-X est un outil de lecture des paroles, synchronisées à la musique sur n’importe quel terminal X.

Il permet de télécharger des lyrics (.lrc, paroles synchronisées), via différents moteurs de recherche, de les sauvegarder sur disque, de les afficher, de les resynchroniser et de les sauvegarder dans le fichier sonore, via tag adéquate (plusieurs formats supportés).