Entwicklungsgeschichte von dekagen

"dekagen" wurde zuerst unter dem Namen "RipEnc" von Michael J. Parmeley geschrieben - die genauen Daten sind mir unbekannt. Ich stieß auf dieses Skript um das Jahr 1999/2000, es war wahrscheinlich in Version 0.7 in der damals von mir benutzten SuSE-Linux-Distribution enthalten oder ich fand es in einem Software-Archiv.

Das Skript erfüllte mehr oder weniger die Anforderungen, die ich an ein solches Programm stellte. Die Auswahl von CD-zu-MP3-Programmen mit einem vergleichbaren Leistungsumfang, insbesondere automatischer Titel-Suche und entsprechende Datei-Namensvergabe sowie ID3-Tagging, war seinerzeit noch sehr begrenzt. - Heute sind entsprechende Funktionalitäten schon im Konqueror (KDE-Filemanager) oder auch in xmcd direkt enthalten.

Jedoch hatte ich Probleme, die seinerzeit von "RipEnc" benutzen ID3-Tagging-Programme für mein System aufzutreiben bzw. zu übersetzen. Deshalb suchte ich nach einer alternativen Lösung und schrieb einen Patch, mit dem "RipEnc" das Programm id3ed für das Tagging benutzen konnte. Diesen Patch versuchte ich Michael J. Parmeley, der damals als Maintainer des Programms angegeben war, per Mail zukommen zu lassen. Jedoch musste ich feststellen, dass es unmöglich war ihn per Mail zu erreichen (Mails kamen als unzustellbar zurück), noch sonstwo im Netz eine Spur von ihm zu finden. Lediglich auf einigen Mirrors (Tucows/Linuxberg) war noch das Skript selbst zu finden, sozusagen als Waisenkind. Das war Ende 2000.

Daraufhin entschloss ich mich dazu, das Programm selbst weiterzuverbreiten, wozu mir die GPL die Möglichkeit gab. Außerdem hatte ich bereits zuvor in zwei ähnlich gelagerten Fällen (darunter html2text) Erfahrungen mit der "Adoption" von Programmen gemacht. Also habe ich den Patch auf den Haupt-Programmcode angewandt, die Dokumentationen überarbeitet und alles unter der neuen Versionsnummer 0.7.1 auf meiner Homepage veröffentlicht.

In den darauf folgenden Tagen schrieb ich das Programm komplett um. Die Entwicklung kann man noch immer recht gut aus dem ChangeLog ablesen bzw. durch direkten Vergleich der Programmpakete, die ab Version 0.7 alle im Download-Verzeichnis des Programms erhältlich sind, ersehen.

Auch aktuelle Versionen beruhen immer noch auf denselben Prinzipien wie die seinerzeit geschriebene Version 0.8. Das Einfügen neuer Features, wie z.B. das Einbinden von "lame", war dabei im Wesentlichen von meinen eigenen Bedürfnissen motiviert: lame war seinerzeit "state of the art", im Gegensatz zu dem damals von "RipEnc" statt dessen unterstützten "bladeenc", bzw. leichter für Linux zu bekommen als die Alternativen 8hz-mp3 und l3enc.

Wobei sich die danach eingebaute Unterstützung für oggenc auch aus der seinerzeit aufgekommenen Patent-Problematik im Zusammenhang mit MP3-generierenden Algorithmen erklärt. Da die Verwendung von lame in Deutschland (wahrscheinlich) lizenzpflichtig ist, ging ich davon aus, dass lame über kurz oder lang aus den Linux-Distributionen verschwinden würde, zumindest in Deutschland und anderen EU-Staaten. Darüber hinaus war ich davon überzeugt, dass Ogg-Vorbis eine deutlich bessere Klangqualität bei gleichzeitig kleinerem Platzbedarf ermöglicht. - Zum Teil bestätigten später erschienene Testberichte in Fachzeitschriften diesen ersten subjektiven Eindruck.

"dekagen" (wie "RipEnc" seit Version 0.9 heißt) war meines Wissens das weltweit erste automatisierte Skript seiner Art für das Rippen, Konvertieren und Benamen von Ogg-Vorbis-Dateien für Unices (oder doch zumindest eines der ersten). Die Entscheidung für eine Unterstützung von Ogg-Vorbis war im Jahr 2001 sicher auch "politisch" oder "strategisch" motiviert, ist also auch als Hilfe für die Verbreitung und Akzeptanz dieses freien Audio-Kompressionsstandards zu verstehen.

Die Namensänderung wiederum rührt daher, dass zu dieser Zeit, also Mitte 2001, der frühere Maintainer Michael J. Parmeley mit der alten Homepage von "RipEnc" plötzlich wieder auftauchte, wenn auch unter einer völlig anderen Adresse. Ich wandte mich von mir aus an ihn und informierte ihn über die von mir an "RipEnc" vorgenommenen Veränderungen. Leider erwies sich die Kommunikation mit ihm als wenig erfreulich. Er bestand darauf, weiterhin "sein" RipEnc (d.h. Version 0.7) zu veröffentlichen und zeigte sich inbesondere den Veränderungen des Userinterface gegenüber wenig aufgeschlossen. Was ihn aber nicht daran gehindert hat, stillschweigend (d.h. ohne darauf hinzuweisen) Code aus ripenc-0.8.1 in bedeutendem Umfang zu übernehmen und das ganze dann als "RipEnc, Version 1.0" zu veröffentlichen. - Der Vorgang ist aus dem Quelltext von "RipEnc-1.0" anhand meines persönlichen Stils zu coden einerseits und einiger gravierender Fehler andererseits recht gut nachzuvollziehen.

Die einzige Möglichkeit diese Situation zu bereinigen bestand darin, meine Programmversionen unter einem anderen Namen neu zu veröffentlichen (sog. fork). Ironischerweise verschwand die (neue) Webpräsenz von Michael J. Parmeley samt "RipEnc" bald darauf wieder spurlos. Auch wenn sie zwischenzeitlich noch einmal wieder aufgetaucht zu sein schien, wurde "RipEnc" jedenfalls seitdem nicht mehr weiterentwickelt.

Heute ist unter diesem Namen praktisch nur noch der früher entstandene BeOS-Fork von Bedeutung. - Wobei sich dessen Bedeutung wiederum durch den Untergang dieses Betriebssystems stark relativiert.

Daneben existiert mit "The One Ripper" ein weiterer Fork in PERL, der ebenfalls wegen Michael J. Parmeleys wenig ausgeprägter Neigung zur Zusammenarbeit entstand, wie mir dessen Entwickler einmal mitteilte. Dieser fragte nämlich einmal bei mir um eine Mitarbeit in seinem Projekt an. Auch wenn ich die Vorteile von PERL für diese Aufgabe klar erkannte, konnte ich dieser Bitte aus Zeitgründen leider nicht entsprechen, es sei denn, ich hätte dafür wiederum "dekagen" aufgegeben. - Tatsächlich hatte ich ursprünglich beabsichtigt, keine Version 1.0 von ripenc/dekagen herauszubringen, es sei denn, sie wäre in PERL geschrieben. Von dieser Vorgabe nahm ich nun Abstand, da mit TOR ein solches PERL-Skript schon existierte.

Statt dessen bemühte ich mich, die Benutzung von "dekagen" in Version 1.0 einfacher und sicherer zu machen, z.B. dadurch dass Fehlbedienung so weit als möglich abgefangen wird. Darüber hinaus wurden alle Kommandos so umgeschrieben, dass "dekagen" jetzt auch ohne weiteres unter FreeBSD zum Einsatz kommen kann, d.h. es wurden für alle Kommandos und Kommandooptionen die Schnittmengen aus Linux und FreeBSD gewählt.

Die Portierbarkeit nach FreeBSD geschah auf Wunsch eines Benutzers. Ansonsten ist leider das Benutzer-Feedback (Lob, Anregungen, Kritik oder auch Patches) über all die Jahre hinweg eher gering geblieben. Über die Anzahl der Benutzer oder die Verbreitung des Programms liegen mir keine Erkenntnisse vor. Sicher werden seine Funktionen mittlerweile, wie bereits erwähnt, auch durch andere Programme bereitgestellt. Dennoch halte ich "dekagen" für Konsolen-/Terminalbenutzer oder die Nutzer anderer UNIX-Betriebssysteme als Linux (wie z.B. FreeBSD) nach wie vor für nützlich.

Für die kommenden Versionen ist eine Vereinfachung und Verschlankung geplant, die bereits im README angekündigt wird. Während ich mir über den Nutzen einer Unterstützung eines verlustfreien Kompressionsstandards nach wie vor nicht sicher bin, wird auf jeden Fall die Möglichkeit zur Auswahl von Qualitätsstufen anstatt (nominaler) Bitraten und eine Alternative für die CDDB-Abfrage durch xmcd eingebaut werden. Ersteres ist wohl seit langem der Wunsch verschiedener Benutzer, zweiteres ist für die Nutzer von FreeBSD wichtig, wo xmcd zu installieren wohl größere Umstände bereitet.

Jedoch bin ich bei der Implementierung neuer Funktionen von Drittprogrammen in "dekagen" immer auch durch die Kompatibilität zu früheren Versionen gebunden, weil ich nicht davon ausgehen kann, dass auf dem System des Benutzers immer auch die neueste Version der Drittprogramme installiert ist. Entsprechende Abfragen würden den Code sehr stark aufblähen, was wiederum die Zunahme potentieller Fehlerquellen bedeuten würde. Umgekehrt würde es eine Menge Support-Anfragen von Benutzern provozieren, würde ich auf die Rückwärts-Kompatibilität verzichten.

Dies hat auf den Funktionsumfang von "dekagen" direkte Auswirkungen, wie z.B. in dem Punkt, dass man z.Zt. nur (nominale) Bitraten statt Qualitätsstufen auswählen kann, und dass diese Qualitätsstufen auf eine bestimmte Reihe beschränkt sind, die die Schnittmenge der Funktionalitäten aller unterstützter Audio-Kompressionsprogramme darstellt. Ein weiteres Sorgenkind ist das für das Userinterface benutzte "dialog", das allein für Linux in insgesamt 3 verschiedenen Varianten existiert, wozu noch die Variante für FreeBSD kommt. Im Großen und Ganzen sind dies jedoch Einschränkungen, die bei einem Front-End in der Natur der Sache liegen.