Forum

Reprise du message précédent

Voilà, tu n'as plus qu'à accepter le pull request.

En gros, tout me convient (nom de l'application, fichiers).

Je comprends que cela puisse être difficile à mettre en œuvre, mais il serait plus pratique que les presets puissent être édités dans les fichiers de configuration (ou même dans l'interface graphique elle-même) plutôt que dans le code source.
Enfin, et une version windows (ce n'est pas vraiment important).

Je voudrais quand même renommer les fichiers si ça ne te dérange pas. demo c'était un nom provisoire.



Oui, j'y pensais. Je vais m'en occuper. Non, ce n'est pas difficile.



Là je n'ai pas de machine Windows sous la main. Ce sera seulement à la rentrée, dans dix jours.

Édité par Roland57 Le 16/02/2023 à 12h17

Je suis heureux avec ce que j'ai. Je n'ai pas de grandes exigences, d'ailleurs ma vue me fait défaut...
Mais bien sûr, tu développe l'application comme tu le souhaites dans ton depot. Je vais laisser le mien inchangé pour l'instant.

Je considère généralement les dépôts comme des trophées. C'est-à-dire que je n'aime pas les mettre à jour

D'accord. J'aime bien cet esprit.

Au fait, quand il y a un état du projet dont tu es satisfait, tu peux créer un tag.

Concernant les problèmes de vue, si tu veux on pourrait agrandir un peu les textes des différents composants.

À bientôt !

Édité par Roland57 Le 16/02/2023 à 17h15

Voici les deux solutions auxquelles je pense pour le moment.

1° Un fichier JSON :



2° Un simple fichier texte :



Dis-moi si l'une de ces solutions te plaît. (Si tu as une autre idée, je suis preneur.)

Autrement on pourrait aussi mettre les commandes dans un fichier inclus dans le projet :



Ce qui faciliterait peut-être l'édition, tout en conservant la possibilité de traduire la description dans différentes langues. En revanche on serait obligé de recompiler à chaque fois. Mais est-ce vraiment un problème ?

Au fait, pour compiler un projet Lazarus, on n'est pas obligé de lancer Lazarus. On peut le faire par une ligne de commande :

Édité par Roland57 Le 16/02/2023 à 20h22

Je me suis concentré sur l'ajout de mes presets (ce que je voulais faire depuis longtemps) à l'application et j'ai rencontré quelques obstacles.

Dans le code source, %s est le fichier d'entrée et de sortie. Cela implique que l'utilitaire de ligne de commande attend les fichiers dans cet ordre :


Mais certains utilitaires, comme l'archiveur de console rar (RAR for Linux x64 Command line), que j'essaie actuellement d'apprivoiser, attend les fichiers dans l'ordre inverse :


Pour être précis, la commande est comme ceci :


En conséquence, cela fonctionne. Mais je dois spécifier le fichier de sortie pour le fichier d'entrée, et le fichier d'entrée pour le fichier de sortie dans l'application UI. C'est-à-dire que c'est l'inverse. C'est assez amusant.
Existe-t-il un moyen de distinguer l'entrée et la sortie dans le code source ?

De plus, comme UI attend des fichiers partout, et non des dossiers, je transforme manuellement le dossier d'entrée en "fichier" en modifiant le chemin.
Je préfère le rar4 car il est plus rapide que le 7z et zip.

Roland57 Je ne pense pas encore aux fichiers de configuration. Je te le confie.
UPD: Bien que je préfère txt, pas json.

Édité par Visiteur Le 16/02/2023 à 23h26

Il faudrait utiliser à la place de %s quelque chose du genre _INPUT_ et _OUTPUT_.



Je vois. Je vais réfléchir de mon côté à la meilleure manière de gérer ce problème.

Merci pour l'exemple de commande. L'intérêt de ce projet, c'est aussi de réunir des exemples de lignes de commande.

Une nouvelle version est disponible sur mon dépôt GitHub.

Il est maintenant possible de sélectionner des dossiers, et l'ordre des arguments n'importe plus.



Une idée m'est venue. On pourrait ajouter dans le fichier de configuration des informations supplémentaires : par exemple si l'entrée est un fichier ou un dossier ; et dans ce cas l'application cocherait automatiquement le bouton "dossier".

On pourrait aussi ajouter, pour chaque commande, les extensions d'entrée et de sortie. Cela permettrait de configurer les dialogues de sélection des fichiers. L'application pourrait également proposer automatiquement des noms pour les fichiers de sortie.

Il faut bien y réfléchir. Ce serait plus de travail pour maintenir l'application, mais plus de confort pour l'utilisateur. À voir !

P.-S. Pour la ligne de commande il serait peut-être préférable d'utiliser un TMemo plutôt qu'un TEdit, afin qu'on puisse voir la ligne en entier.

Édité par Roland57 Le 17/02/2023 à 00h47

Oui, j'ai compilé la nouvelle version. C'est cool.
Mais peut-être que je ne pourrai plus utiliser l'ordinateur bientôt :(

Ce sont les commandes que j'utilise. Je ne pense pas qu'elles seront utiles à quiconque, mais pourquoi pas.

L'utilisation du GUI universel m'a permis de spécifier des options avant ffmpeg -i, contrairement à d'autres GUI comme WinFF et QWinFF. Et même pipe et wine.

Merci pour le partage des commandes.

Par contre c'est un peu dommage, après avoir créé des dépôts GitHub, de perdre du temps à faire des copier-coller sur le forum.

Donc je viens de faire un pull request pour que les deux dépôts soient de nouveau synchronisés.

Après, si tu veux, nous pourrons faire la modification consistant à mettre les commandes dans un fichier séparé.

J'ai ajouté un preset pour télécharger le forum en utilisant curl.

Download with curl





=



56-28=28

Le proxy socks est facultatif.
L'option --output-dir nécessite curl >=7.73.0.

Roland57, bien sûr, ce serait formidable si tu pouvais implémenter le fichier de configuration, le dossier de sortie par défaut et les extensions de fichiers recommandées.
Peut-être qu'alors plus de gens utiliseraient l'application. Je pense qu'il n'y a que deux utilisateurs maintenant, toi et moi. Parce que peu de gens veulent installer Lazarus, éditer le code source et le compiler, malheureusement.

Et la version pour Windows, il y aura plus d'utilisateurs.


TEdit me convient, car la taille du champ est stable. Mais peut-être que TMemo serait bien. Mais je suis très conservateur et je n'aime pas le changement.

Édité par Visiteur Le 23/02/2023 à 02h18

Que cette application soit en mémoire de mon chat. Je pense que nous ajouterons sa photo à la section "A propos" plus tard.
Il est dommage que le chat n'ait pas vu cette application, mais au moins de cette manière.

Édité par Visiteur Le 23/02/2023 à 02h36

Base64 Decode



UI requiert un espace comme fichier de sortie.
Basez :
http://www.quarkline.net/basez/
http://www.quarkline.net/basez/download/
https://packages.ubuntu.com/bionic/basez
basez.exe.zip

ou


Volume analyzer



Analyseur de volume de la piste audio (peak level).
Voir le paramètre de sortie : Pk lev dB (Overall).
Ajoutez +10dB à cette valeur.
Par exemple -11+10=-1dB.

La précorrection de -10dB a été ajoutée car l'analyseur de niveau (ffmpeg et sox) fonctionne en 16 bits fixed point, où le niveau maximum est de 0dB. Mais les fichiers réels peuvent contenir des niveaux supérieurs à 0dB (clipping risk). Pour connaître les niveaux supérieurs à 0dB, il faut fonctionner en 32 bit float et réserve de niveau.

-map 0:a:0 dernier 0 est le numéro de la piste audio (il peut y avoir plusieurs pistes audio dans un conteneur). 0 est le premier audio, 1 est le deuxième audio...
-ac 2 downmix en stéréo (par exemple 5.1 > 2.0), les pistes stéréo d'entrée ne sont pas modifiées.
-drc_scale 0 - pas de compression de plage dynamique des pistes AC3 (Dolby Digital)
-drc_scale 1 - compression au Home level.
Installez sox sur le système.

VLC utilise la DRC par défaut, SMPlayer (mpv) ne le fait pas.
-drc_scale 1 valeur par défaut dans ffmpeg.
Le DRC ne s'applique qu'au format AC3.

YouTube Download

Édité par Visiteur Le 26/02/2023 à 05h04

J'ai parlé de l'UI sur le forum Rosa, mais cela n'a pas semblé intéresser grand monde. J'ai réalisé que la promotion est quelque chose que je ne ferai plus.

Roland54, Alex Kotov t'envoie ses salutations.