En terme d'authentification, la grille permet une authentification forte car combinant deux facteurs: something you know : le pattern et something you own : la grille.
Avec le limitations que j'évoquais :
Il faut qu'elle soit non déterministe.
Il ne faut pas en abuser car ce que tu possèdes, la grille, à force de la lire, va devenir ce que tu sais. Et tu retombe sur une authentification faible, c-à-d avec un seul facteur.
Il ne passe pas à l'échelle : impossible de gérer des centaines de grilles et de mémoriser des centaines de patterns.
Peut être que le but n'est pas clair non plus.
Si le but est de pouvoir bloquer l'accès aux données en brulant la grille, il manque l'aspect non déterministe comme le dit BFG.
Si le but est de dériver des mots de passe à partir d'un mot de passe maitre et d'un identifiant de site web, il y a des extensions pour ça.
Si le but est de générer une grille imprimable pour tout usage, pourquoi pas. Dans ce cas, on retombe sur le non déterministe il ne fait pas mettre de paramètre à la génération.
Car si la grille est trouvé ou peut être reconstruite, il ne faudra pas très longtemps pour retrouver ou faire avouer le pattern.
Tu parles de 2800 milliard de possibilités mais dans la pratique, un utilisateur va privilégier un pattern continu, pas trop tordu (disons max 2 virages). Je ne me suis pas lancé dans le calcul mais ça doit à la portée d'un simple pc. Ou d'une clé à molette.
Aussi, à force de taper un mot de passe, tu finis par t'en rappeler sans avoir besoin de la grille. Donc, clé à molette, tout ça.
Enfin, cela ne passe pas bien à l'échelle. J'ai plus de deux cents mots de passe gérés par mon navigateur. Je me vois pas gérer deux cents grilles.
Je pense que ce système de grille est bien, en mode non déterministe, pour un mot de passe vital que tu ne rentre pas tous les jours. Genre un mot de passe de PKI ou de chiffrement de disque serveur.
Alors moi j'utilise l'extension pwgen.
Un site me demande un mot de passe pour créer un compte, je clique, je colle. Mon navigateur demande si il doit s'en rappeler. Je dis oui. Je tape mon master password. En plus ça se synchronise au cas où j'en ai besoin sur un autre pc.
Qu'est ce que je loupe à ne pas utiliser une grille ?
En suivant le tutoriel, au demeurant très bien fait, je ne comprends pas la lourdeur du processus : pattern, préfixe, etc.
Tout à fait, cela dépend de l'usage.
Reste que je constate que inotify est peu scalable.
Et un fullscan peu fiable et très impactant pour les performance.
Il y a donc une place pour un autre mécanisme imho.
Je pense que tu veux dire mettre un watcher par dossier pour tous les dossiers d'une arborescence, c'est ça ?
Cela ne changera pas vraiment le problème car le dossier représentent bien souvent une part non négligeable. en supposant que tu as 50k dossier pour 150k fichiers tu ne réduis ta problématique que par 4. En plus, sans être spécialiste inotify, si tu as beaucoup de fichiers dans un répertoire, tu aura plusieurs inodes pour le décrire et donc plusieurs watcher à placer (je ne suis pas sûr de ça).
Mon idée est plutôt de créer un mécanisme qui, quand tu ouvre le fichier "/a/b/c/d", se dit, est ce qu'il y a un watcher sur d ? non ; sur c, non ; sur b ? non ; sur a, oui ! Donc le fichier est surveillé.
Ça pénalise le open, mais sur un FS dédié aux données et qui subira une surveillance, le jeu en vaut la chandelle.
Je voulais mettre en place de la sauvegarde incrémentale sur une arborescence. J'ai eu le même problème avec les limitations de inotify : le lancement sur une grosse arborescence est infiniment lent et dépasse bien souvent la limite du nombre de watcher.
Bien souvent tu veux surveiller tout un répertoire (/data). Mais pour cela le noyau doit placer un watch sur chaque fichier et répertoire de l'arborescence, récursivement. Il n'a pas la notion d'appartenance d'un fichier ou répertoire à une arborescence. Ça ne passe pas bien à l'échelle.
Il faudrait un mécanisme dans le noyau qui permette de surveiller une arborescence.
Cela pénalise un peu le "open", il faut inspecter chaque noeud parent, mais après ce serait très rapide. Et la mise en place serait instantanée : seulement un watcher sur la racine.
En attendant, je réfléchis à un mécanisme similaire utilisant FUSE.
Dans mon cas elle s'appelle stdbuf.
Merci pour ton post, je connaissais la majorité de ces commandes mais pas toues et une m'a attiré l'oeil : stdbuf.
Dans ce post, j'écris mes déboire pour faire quelque chose qui me semblait très simple : transformer un script qui produit une ligne en sortie pour une ligne en entrée mais qui nécessite un init assez long en un service persistant tournant sur ma machine. Je pensais utiliser un pipe, voire une socket unix voire ip.
Au final, la bonne réponse dans mon cas est bien un pipe. Mais quelle que soit la solution, je butais sur un problème : le script ne produit rien. En fait, il ne produit pas systématiquement une sortie pour une entrée : il bufferise. Ma solution a été d'ajouter un "sys.stdout.flush()" dans mon script appelé. Cependant, ce n'est pas très générique car si j'ai besoin de traiter des lignes en masse, je ne voudrai pas pénaliser les performances en flushant à chaque ligne.
J'ai donc, à la suite de la lecture de ce post, reversé le contrôle en modifiant le script appelant par "stdbuf -oL ./script1.py".
Cela fonctionne tout aussi bien tout en étant plus propre à mon goût.
Est ce la volonté de tout le monde de :
- ne pas enfermer les informations des citoyens dans des technologies propriétaires
- ne pas consacrer plusieurs millions d'euros à payer des licences à des entreprises étagères mais en investir une fraction dans des solutions ouvertes et pérennes,
- ne pas toujours céder au lobbys,
- et tant d'autres motivations allant dans le sens du bien commun.
Posté par steph1978 .
En réponse à la dépêche OpenBSD 5.8.
Évalué à 1.
Dernière modification le 03 décembre 2015 à 16:21.
Je n'ai pas dit que j'avais cherché.
La dépêche dit "file a une nouvelle implémentation" et donne un lien vers le man de file. Cela n'apporte aucune information. Je sais ce que fait la commande file. Par contre je suis intéressé par savoir ce qui posait problème et ce qui a été corrigé.
Note que je remercie l'auteur de la dépêche au demeurant très intéressante.
Merci pour le lien.
Je partage assez:
But it's still a bit unnerving to me that a bug in a utility like file(1), which needs to do nothing but read a file and output text to stdout, could possibly do things like overwrite other files, write to the network, etc., even in the presence of parsing bugs and a maliciously crafted file.
A propos de file, c'est une nouvelle implémentation ? Pas une nouvelle commande ?
La phrase dans la dépêche est ambiguë.
Avez vous un pointeur décrivant cette nouvelle implémentation ?
J'approuve l'initiative, un peu moins le prix…
Peut être le design produit servira à produire d'autre boards un peu moins cher.
Est-ce qu'il exite un produit un tant soit peu ouvert (genre à base de OpenWRT, linux ou de BSD) qui faire office de modem (ADSL et FTTH), router, firewall, haproxy (ou équivalent) ? Cela remplacerai avantageusement, pour moi, la box opérateur….
Désolé, j'ai moinssé car commentaire à côté de la plaque AMHA.
Ce n'est pas l'effet chimique du CO2 qui est craint mais son effet de serre, qui engendre un réchauffement climatique, qui engenre des perturbations écologiques de type disparition d'espèces.
Cela n'a rien d'irrationnel. C'est juste complétement insuffisant comme indicateur écologique. Cela ne représente pas : la pollution chimique des sols et de l'eau, la réduction des écosystèmes sauvages, le plastique dans les océans, etc.
On code avec des langages et des algorithmes aux effets "imprévisibles" maintenant?
Le langage et les algo sont prévisibles en théorie ; mais pas leur implémentation sur le matériel. Après certains langages sont plus robustes que d'autres.
Concernant les sauvegardes, une bonne pratique est l'utilisation de Parchive qui ajoute des données permettant la correction d'erreur.
On peut jouer sur la quantité de redondance en fonction de la fiabilité du support : plus haute sur un CD/DVD gravé, plus faible sur un disque en bonne santé ou une clé USB neuve.
La difficulté est que cela s’accommode très mal d'une sauvegarde type rsync où l'on ne crée pas d'archive mais où on manipule une grande quantité de fichiers.
Je ne sais pas si il existe de FS (ZFS ?) ou des surcouches bloc (LVM, Device Mapper) qui permettent d'ajouter de la correction d'erreur…
Tenté. N'a pas marché pour moi : autant de tac tac avant qu'après le congélo.
Les données n'étaient pas précieuse. Le disque a pris la direction de la déchèterie.
Ce n'est pas complétement faux.
Photorec ne se base pas sur le filesystem mais scanne directement les blocs à la recherche de magicblocs décrivant un type de fichiers connu.
Donc il n'abimera pas la copie faite. Seul difficulté, les fichiers perdent leur metadata: nom, date, chemin ; bien embêtant quand ce ne sont pas que des gros fichiers multimédia.
Par contre il est vrai qu'il est préférable de travailler sur une copie de la copie et de tenter de réparer le filesystem.
Photorec n'est à utiliser qu'en dernier recours pour un cas particulier : fichiers multimédia.
J'ai perdu une carte microsd en pensant que ma housse de téléphone était étanche. Elle l'était une peu :/ mais pas avec la douche qu'on a prise.
Résultat : microsd impossible à lire. Le téléphone ne prenait plus de microsd du tout, même neuve, et ne chargeait plus.
Bref, il avait pris un court jus.
De retour au calme et surtout au sec. Le téléphone charge et lit les microsd mais pas celle qui a pris l'eau.
J'ai pu récupérer la quasi totalité des données avec ddrescue pour faire une image sur un autre disque et TestDisk pour tout extraire de l'image prise. L'infiltration d'eau avait principalement corrompu le FS, je n'ai pas eu d'erreur d'I/O.
Mais comme le dit l'auteur du post, dans le doute, faire une copie et travailler sur une copie de la copie. La copie devient en quelque sorte un original puisque l'original est en train de mourir.
(15 * 5_MB) / (5_min * 60_s/min) = 0.25MB/s
C'est plutôt très très lent.
Ce qui tend à faire penser qu'il y a eu ré-encodage.
C'est non seulement consommateur de ressources mais aussi assez mauvais pour la qualité finale.
FFMpeg et d'autres outils CLI aurait pû être utilisé pour faire de la copie seulement et aurait traité les 75MB en quelques secondes.
[^] # Re: gné
Posté par steph1978 . En réponse au journal Générateur de mot de passe. Évalué à 2.
C'est vrai qu'en incluant des formes connues on augmente pas mal les possibilités.
[^] # Re: Moteur inside
Posté par steph1978 . En réponse au journal Merry 6.c! Mon expérience avec Perl 6. Évalué à 2. Dernière modification le 29 décembre 2015 à 11:32.
T'es sûr ?
Tout ça me dit le contraire…
# two factors
Posté par steph1978 . En réponse au journal Générateur de mot de passe. Évalué à 1.
Je reformule un peu mon dernier commentaire.
En terme d'authentification, la grille permet une authentification forte car combinant deux facteurs: something you know : le pattern et something you own : la grille.
Avec le limitations que j'évoquais :
Il faut qu'elle soit non déterministe.
Il ne faut pas en abuser car ce que tu possèdes, la grille, à force de la lire, va devenir ce que tu sais. Et tu retombe sur une authentification faible, c-à-d avec un seul facteur.
Il ne passe pas à l'échelle : impossible de gérer des centaines de grilles et de mémoriser des centaines de patterns.
[^] # Re: gné
Posté par steph1978 . En réponse au journal Générateur de mot de passe. Évalué à 1.
Peut être que le but n'est pas clair non plus.
Si le but est de pouvoir bloquer l'accès aux données en brulant la grille, il manque l'aspect non déterministe comme le dit BFG.
Si le but est de dériver des mots de passe à partir d'un mot de passe maitre et d'un identifiant de site web, il y a des extensions pour ça.
Si le but est de générer une grille imprimable pour tout usage, pourquoi pas. Dans ce cas, on retombe sur le non déterministe il ne fait pas mettre de paramètre à la génération.
Car si la grille est trouvé ou peut être reconstruite, il ne faudra pas très longtemps pour retrouver ou faire avouer le pattern.
Tu parles de 2800 milliard de possibilités mais dans la pratique, un utilisateur va privilégier un pattern continu, pas trop tordu (disons max 2 virages). Je ne me suis pas lancé dans le calcul mais ça doit à la portée d'un simple pc. Ou d'une clé à molette.
Aussi, à force de taper un mot de passe, tu finis par t'en rappeler sans avoir besoin de la grille. Donc, clé à molette, tout ça.
Enfin, cela ne passe pas bien à l'échelle. J'ai plus de deux cents mots de passe gérés par mon navigateur. Je me vois pas gérer deux cents grilles.
Je pense que ce système de grille est bien, en mode non déterministe, pour un mot de passe vital que tu ne rentre pas tous les jours. Genre un mot de passe de PKI ou de chiffrement de disque serveur.
# gné
Posté par steph1978 . En réponse au journal Générateur de mot de passe. Évalué à 2.
Alors moi j'utilise l'extension pwgen.
Un site me demande un mot de passe pour créer un compte, je clique, je colle. Mon navigateur demande si il doit s'en rappeler. Je dis oui. Je tape mon master password. En plus ça se synchronise au cas où j'en ai besoin sur un autre pc.
Qu'est ce que je loupe à ne pas utiliser une grille ?
En suivant le tutoriel, au demeurant très bien fait, je ne comprends pas la lourdeur du processus : pattern, préfixe, etc.
[^] # Re: Tout faire en base
Posté par steph1978 . En réponse au journal Analyse de texte. Évalué à 3.
SQLite est un SGBD. Je vois pas sur quoi tu te base pour dire qu'il est moins performant qu'un autre….
[^] # Re: Quelques questions
Posté par steph1978 . En réponse au journal Publication de la première version de fwtchrq.. Évalué à 2.
Tout à fait, cela dépend de l'usage.
Reste que je constate que inotify est peu scalable.
Et un fullscan peu fiable et très impactant pour les performance.
Il y a donc une place pour un autre mécanisme imho.
[^] # Re: Quelques questions
Posté par steph1978 . En réponse au journal Publication de la première version de fwtchrq.. Évalué à 2.
Je pense que tu veux dire mettre un watcher par dossier pour tous les dossiers d'une arborescence, c'est ça ?
Cela ne changera pas vraiment le problème car le dossier représentent bien souvent une part non négligeable. en supposant que tu as 50k dossier pour 150k fichiers tu ne réduis ta problématique que par 4. En plus, sans être spécialiste inotify, si tu as beaucoup de fichiers dans un répertoire, tu aura plusieurs inodes pour le décrire et donc plusieurs watcher à placer (je ne suis pas sûr de ça).
Mon idée est plutôt de créer un mécanisme qui, quand tu ouvre le fichier "/a/b/c/d", se dit, est ce qu'il y a un watcher sur d ? non ; sur c, non ; sur b ? non ; sur a, oui ! Donc le fichier est surveillé.
Ça pénalise le open, mais sur un FS dédié aux données et qui subira une surveillance, le jeu en vaut la chandelle.
[^] # Re: Quelques questions
Posté par steph1978 . En réponse au journal Publication de la première version de fwtchrq.. Évalué à 2. Dernière modification le 17 décembre 2015 à 20:30.
Je voulais mettre en place de la sauvegarde incrémentale sur une arborescence. J'ai eu le même problème avec les limitations de inotify : le lancement sur une grosse arborescence est infiniment lent et dépasse bien souvent la limite du nombre de watcher.
Bien souvent tu veux surveiller tout un répertoire (/data). Mais pour cela le noyau doit placer un watch sur chaque fichier et répertoire de l'arborescence, récursivement. Il n'a pas la notion d'appartenance d'un fichier ou répertoire à une arborescence. Ça ne passe pas bien à l'échelle.
Il faudrait un mécanisme dans le noyau qui permette de surveiller une arborescence.
Cela pénalise un peu le "open", il faut inspecter chaque noeud parent, mais après ce serait très rapide. Et la mise en place serait instantanée : seulement un watcher sur la racine.
En attendant, je réfléchis à un mécanisme similaire utilisant FUSE.
# il y a une commande pour ça
Posté par steph1978 . En réponse au journal Le core utile. Évalué à 4.
Dans mon cas elle s'appelle stdbuf.
Merci pour ton post, je connaissais la majorité de ces commandes mais pas toues et une m'a attiré l'oeil : stdbuf.
Dans ce post, j'écris mes déboire pour faire quelque chose qui me semblait très simple : transformer un script qui produit une ligne en sortie pour une ligne en entrée mais qui nécessite un init assez long en un service persistant tournant sur ma machine. Je pensais utiliser un pipe, voire une socket unix voire ip.
Au final, la bonne réponse dans mon cas est bien un pipe. Mais quelle que soit la solution, je butais sur un problème : le script ne produit rien. En fait, il ne produit pas systématiquement une sortie pour une entrée : il bufferise. Ma solution a été d'ajouter un "sys.stdout.flush()" dans mon script appelé. Cependant, ce n'est pas très générique car si j'ai besoin de traiter des lignes en masse, je ne voudrai pas pénaliser les performances en flushant à chaque ligne.
J'ai donc, à la suite de la lecture de ce post, reversé le contrôle en modifiant le script appelant par "stdbuf -oL ./script1.py".
Cela fonctionne tout aussi bien tout en étant plus propre à mon goût.
[^] # Re: système d'exploitation
Posté par steph1978 . En réponse au journal De la nausée. Évalué à 6.
Non, parce que la question est mal posée.
Est ce la volonté de tout le monde de :
- ne pas enfermer les informations des citoyens dans des technologies propriétaires
- ne pas consacrer plusieurs millions d'euros à payer des licences à des entreprises étagères mais en investir une fraction dans des solutions ouvertes et pérennes,
- ne pas toujours céder au lobbys,
- et tant d'autres motivations allant dans le sens du bien commun.
Peut être que oui.
[^] # Re: file ?
Posté par steph1978 . En réponse à la dépêche OpenBSD 5.8. Évalué à 1. Dernière modification le 03 décembre 2015 à 16:21.
Je n'ai pas dit que j'avais cherché.
La dépêche dit "file a une nouvelle implémentation" et donne un lien vers le man de file. Cela n'apporte aucune information. Je sais ce que fait la commande file. Par contre je suis intéressé par savoir ce qui posait problème et ce qui a été corrigé.
Note que je remercie l'auteur de la dépêche au demeurant très intéressante.
Merci pour le lien.
Je partage assez:
Ça fait frissonner
# file ?
Posté par steph1978 . En réponse à la dépêche OpenBSD 5.8. Évalué à 2.
A propos de file, c'est une nouvelle implémentation ? Pas une nouvelle commande ?
La phrase dans la dépêche est ambiguë.
Avez vous un pointeur décrivant cette nouvelle implémentation ?
[^] # Re: un avis d'expert sur Jolla ?
Posté par steph1978 . En réponse au journal Jolla va mal. Évalué à 2.
Tu peux utiliser un Android tout court, sans Google. Comme une cyanogène par exemple.
# neutralité
Posté par steph1978 . En réponse au journal Lancement officiel de MyUnéo et de son blog. Évalué à 2.
Ce genre d'initiative devrait être portée par une association de consommateurs type QueChoisir, financée par les consommateurs.
# libre
Posté par steph1978 . En réponse à la dépêche Le routeur Turris Omnia a doublé son objectif de financement participatif. Évalué à 2.
J'approuve l'initiative, un peu moins le prix…
Peut être le design produit servira à produire d'autre boards un peu moins cher.
Est-ce qu'il exite un produit un tant soit peu ouvert (genre à base de OpenWRT, linux ou de BSD) qui faire office de modem (ADSL et FTTH), router, firewall, haproxy (ou équivalent) ? Cela remplacerai avantageusement, pour moi, la box opérateur….
[^] # Re: Sans CO2, pas de vie
Posté par steph1978 . En réponse au journal [HS] Faites chauffer la planète, notre moteur a froid.. Évalué à 3. Dernière modification le 25 novembre 2015 à 14:31.
Désolé, j'ai moinssé car commentaire à côté de la plaque AMHA.
Ce n'est pas l'effet chimique du CO2 qui est craint mais son effet de serre, qui engendre un réchauffement climatique, qui engenre des perturbations écologiques de type disparition d'espèces.
Cela n'a rien d'irrationnel. C'est juste complétement insuffisant comme indicateur écologique. Cela ne représente pas : la pollution chimique des sols et de l'eau, la réduction des écosystèmes sauvages, le plastique dans les océans, etc.
[^] # Re: Imprévisible? Vraiment?
Posté par steph1978 . En réponse au journal L'ordinateur qui a effacé cinq voix. Évalué à 2.
Le langage et les algo sont prévisibles en théorie ; mais pas leur implémentation sur le matériel. Après certains langages sont plus robustes que d'autres.
[^] # Re: Réaliser plusieurs masters
Posté par steph1978 . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 2.
Du RAID de DVD ?
[^] # Re: Réaliser plusieurs masters
Posté par steph1978 . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 4.
Concernant les sauvegardes, une bonne pratique est l'utilisation de Parchive qui ajoute des données permettant la correction d'erreur.
On peut jouer sur la quantité de redondance en fonction de la fiabilité du support : plus haute sur un CD/DVD gravé, plus faible sur un disque en bonne santé ou une clé USB neuve.
La difficulté est que cela s’accommode très mal d'une sauvegarde type rsync où l'on ne crée pas d'archive mais où on manipule une grande quantité de fichiers.
Je ne sais pas si il existe de FS (ZFS ?) ou des surcouches bloc (LVM, Device Mapper) qui permettent d'ajouter de la correction d'erreur…
[^] # Re: searchplugins => game over
Posté par steph1978 . En réponse au journal Passage à duckduckgo pour mes recherches au lieu de google. Évalué à 2. Dernière modification le 01 novembre 2015 à 20:36.
J'y suis parvenu en téléchargeant le fichier https://framabee.org/opensearch.xml
En modifiant
par
Ensuite j'ai créé une page html avec un code link dans le head:
Servi par un serveur web local. Dans la barre de recherche FF me propose d'ajouter le moteur de recherche (petit plus vert sur la loupe).
Et cela fonctionne bien en GET.
[^] # Re: Congélo ?
Posté par steph1978 . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 2.
Tenté. N'a pas marché pour moi : autant de tac tac avant qu'après le congélo.
Les données n'étaient pas précieuse. Le disque a pris la direction de la déchèterie.
[^] # Re: Idiotie de forum
Posté par steph1978 . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 3. Dernière modification le 26 octobre 2015 à 17:06.
Ce n'est pas complétement faux.
Photorec ne se base pas sur le filesystem mais scanne directement les blocs à la recherche de magicblocs décrivant un type de fichiers connu.
Donc il n'abimera pas la copie faite. Seul difficulté, les fichiers perdent leur metadata: nom, date, chemin ; bien embêtant quand ce ne sont pas que des gros fichiers multimédia.
Par contre il est vrai qu'il est préférable de travailler sur une copie de la copie et de tenter de réparer le filesystem.
Photorec n'est à utiliser qu'en dernier recours pour un cas particulier : fichiers multimédia.
[^] # Re: Sauvegarder toujours
Posté par steph1978 . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 6.
Il faut… quand tu as la possibilité de le faire.
J'ai perdu une carte microsd en pensant que ma housse de téléphone était étanche. Elle l'était une peu :/ mais pas avec la douche qu'on a prise.
Résultat : microsd impossible à lire. Le téléphone ne prenait plus de microsd du tout, même neuve, et ne chargeait plus.
Bref, il avait pris un court jus.
De retour au calme et surtout au sec. Le téléphone charge et lit les microsd mais pas celle qui a pris l'eau.
J'ai pu récupérer la quasi totalité des données avec ddrescue pour faire une image sur un autre disque et TestDisk pour tout extraire de l'image prise. L'infiltration d'eau avait principalement corrompu le FS, je n'ai pas eu d'erreur d'I/O.
Mais comme le dit l'auteur du post, dans le doute, faire une copie et travailler sur une copie de la copie. La copie devient en quelque sorte un original puisque l'original est en train de mourir.
[^] # Re: script
Posté par steph1978 . En réponse au message Comment fusionner une vingtaine de fichiers audio MP3 sans Audacity ?. Évalué à 2.
(15 * 5_MB) / (5_min * 60_s/min) = 0.25MB/s
C'est plutôt très très lent.
Ce qui tend à faire penser qu'il y a eu ré-encodage.
C'est non seulement consommateur de ressources mais aussi assez mauvais pour la qualité finale.
FFMpeg et d'autres outils CLI aurait pû être utilisé pour faire de la copie seulement et aurait traité les 75MB en quelques secondes.