Hallo zusammen,

ich wollte mich schon länger hier registrieren, da ich eifrig mitlese.

Nun nutze ich mal die Gelegenheit, mein Open-Source Projekt hier vorzustellen:


tone


Es ist ein Kommandozeilenprogramm zum Anzeigen und Bearbeiten von Audio-Metadaten und Tags, das unter allen gängigen Betriebssystemen als einzelne Binary laufen müsste - sprich: Runterladen und ausführen, ohne Abhängigkeiten (abgesehen vom M1 Mac, da scheint es noch Probleme zu geben). Ich habe es hauptsächlich geschrieben, um fehlende Features speziell für Hörbücher existierender Programme zu ergänzen, inzwischen hat es sich aber zu einem für mich echt brauchbaren Tool für alles Mögliche an Audio-Files gemausert.

Habe auch schon überlegt, es im Bereich Code-Review zu posten, da es noch ein recht junges Projekt ist. Ich freue mich also über jegliche Art von Feedback (Benutzung, Verbesserungsvorschläge, Code-Kommentare, etc.).

Worauf ich noch hinweisen möchte: Ich lasse das Projekt automatisch auf github über Github-Actions bauen und veröffentlichen. Falls also jemand ein Template für so etwas sucht, darf er sich gerne bedienen.

Features:

• Unterstützung diverser Datei- und Metadatenformate (id3, ape, mp4, etc.)
• Sehr viele Meta-Felder inkl. benutzerdefinierter Felder, Kapitel und Cover (Artist, Album, etc.)
• Taggen über Pfade (Metadaten werden über Templates aus Dateipfad geschrieben, z.B. --path-pattern="audiobooks/%g/%a/%s/%p - %n.m4b")
• JavaScript-Engine + API zum Erweitern um eigene selbstgeschriebene Features

Langfristig plane ich noch folgende Erweiterungen:

• Erweiterung von dump um JavaScript-Engine Unterstützung um benutzerdefinierte Ausgabeformate oder Exporte zu erzeugen
• rename - Audio-Dateien anhand von Tags umbenennen
• split - um eine Audio-Datei anhand von Kapitel aufzuteilen
• merge - mehrere Audio-Dateien zu einer zusammenfügen
• convert - Audio-Dateien konvertieren

Nutzen möchte ich dazu ffmpeg und fdkaac über eine Prozess-Integration (CliWrap).

Im Code genutzt werden:

• c# 6
• spectre.console als Kommandozeilen-Bibliothek
• Dependency Injection
• jint als JavaScript interpreter
• z440.atl.core für das Audio-Tagging

Würde mich sehr über Feedback jeglicher Art freuen (solange es konstruktiv ist :-).

Hallo sandreas,

auch wenns eine (single file) EXE als Ausgabe gibt und es per-se keine Klassenbibliothek ist, so würde ich interne Typen als internal markieren, da dies Implementierungsdetails sind. Der Vorteil davon ist, dass diese nach belieben geändert werden können ohne das "public api" zu verletzen und entsprechend SemVer eine neue Hauptversionsnummer erfordern würde.

Sind die Implementierungsdetails internal so könnten ein paar Optimierungen bzgl. Effizienz (CPU und Speicher / GC) durchgeführt werden.

Weiters würde ich das Projekt aufteilen, so dass für den Benutzer

• die EXE (wie bisher) zur Verfügung steht
• es eine DLL (NuGet) zur Verwendung als API (in eigenen Projekten, Web, etc.) gibt

wobei die EXE selbst ein Konsument der DLL ist -- sozusagen als einfacher Wrapper / Driver um die DLL angereichert mit den Commands die im Projekt verfügbar sind.

mfG Gü

Hey gfoidl,

na das nenn ich doch mal rasches und hervorragendes Feedback. Vielen Dank.

Zitat

auch wenns eine (single file) EXE als Ausgabe gibt und es per-se keine Klassenbibliothek ist, so würde ich interne Typen als internal markieren, da dies Implementierungsdetails sind. Der Vorteil davon ist, dass diese nach belieben geändert werden können ohne das "public api" zu verletzen und entsprechend SemVer eine neue Hauptversionsnummer erfordern würde. Sind die Implementierungsdetails internal so könnten ein paar Optimierungen bzgl. Effizienz (CPU und Speicher / GC) durchgeführt werden.

Wieder was gelernt. Wusste gar nicht genau, wie sich das Schlüsselwort internal auswirkt. Cool.

Zitat

Weiters würde ich das Projekt aufteilen, so dass für den Benutzer ...

Das hatte ich tatsächlich sogar schon auf der Liste, allerdings ist gut, nochmal zu hören, dass das kein overengineering wäre (zumindest nicht per se...).

Und allgemein? Magst du das Projekt? Neutral oder eher "so wird das nie was"? :-)

LG
sandreas

Hallo sandreas,

Zitat

Und allgemein? Magst du das Projekt? Neutral oder eher "so wird das nie was"? :-)

Ja ich mag das Projekt*. Schaut sehr sauber aus, auf GH-ReadMe (prüf dort mal das Encoding, sind ein paar Spezial-Zeichen dabei) sind alle nötigen Infos vorhanden so dass sich damit arbeiten lässt bzw. sofort ein Überblick gegeben ist.
Code hab ich nur überflogen, der passt soweit**. Bei den Tests noch ein paar mehr Fälle testen (v.a. Randfälle / edge-cases wie keine Tags vorhanden beim Parser, etc.).

* auch wenn ich mangels Bedarf es selbst wohl eher nicht verwenden werde, aber da du es hier so nett vorgestellt hast, hab ich es mir angeschaut ;-)
** die Anmerkungen oben sind davon unberührt, das kann ja noch geändert werden und Optimierungsmöglichkeiten finden sich fast überall...

mfG Gü

Zitat

Ja ich mag das Projekt*. Schaut sehr sauber aus, auf GH-ReadMe

Cool... das motiviert. Das mit den Charset-Sachen ist mir aufgefallen, vermutlich ein Copy&Paste fehler. Sollte korrigiert sein :-)

Zitat

Bei den Tests noch ein paar mehr Fälle testen (v.a. Randfälle / edge-cases wie keine Tags vorhanden beim Parser, etc.).

Für die Tests kommt ein rewrite, so das ich mindestens 80% abdecke, sobald die "Experimente" mit den Libraries abgeschlossen sind. Aktuell habe ich noch ein paar Probleme mit Jint und CliWrap... aber ich glaube das hab ich bald im Griff.

Die von spectre.console antworten auf meine GH Issues seit Wochen nicht, das ist etwas frustrierend. Daher hab ich das in meine "Known Issues" bei den Release Notes gepackt

Inzwischen wurde die 0.0.9 released, falls noch mal jemand reingucken will. Hat sich schon einiges getan.