Hallo! Al Bogner wrote:
Am Mittwoch, 31. Dezember 2003 10:03 schrieb Thomas Hertweck:
[...] Beim Brennen konnte _ich_ mich für _meine_ Brennwünsche mit einem GUI noch nie richtig anfreunden, und zwar deshalb, weil ich seit Jahren immer ähnliche Dinge brenne, wobei das Script nach bestimmten Kritieren die zu brennenden Dateien erstellt und ich mir dadurch nicht den Kopf zerbrechen muß, ob ich eine Datei vergessen habe. Das gilt zB besonders für meine Datensicherung, wo ich Kompromisse machen muß, da ich nicht jedesmal alles brenne, aber mir zB keine Gedanken darüber machen will, dass ich ja die neue config-Datei einer weiteren Kernelvariante auch mitsichern möchte.
Fuer automatische Backups, Sicherungen, etc. macht es sicherlich Sinn mit den Skripten. Wenn ich aber einfach mal so eine CD/DVD brennen moechte, dann finde ich ehrlich gesagt eine GUI angenehmer.
[...] IMO ist das Brennen von DVD schlimmer als CD brennen in den Anfängen. Mit dem falschen Rohling kann sonst alles richtig sein und man wird vom Brennergebnis enttäuscht sein. Ich habe noch immer nicht den Rohling gefunden, der mit allen DVD-Playern hier läuft und verwende keinen Billig-Schrott. Die FW-Version des Brenners wirkt sich auch ganz entscheidend aus und ältere FW kann mit den verwendeten Rohlingen besser funktionieren als die neuere.
Das ist leider ein sehr grosses Problem, es gibt ja auch leider unterschiedlich konkurrierende Standards, das macht die Sache nicht gerade uebersichtlicher. Ich habe hier einen DVD+-R(W) Brenner, aber was ist nun besser? DVD+R oder DVD-R usw., das ist doch alles manchmal recht undurchsichtig.
[...]
Ich kann mit der Maus alle Sachen, die ich brennen moechte, einfach per Drag&Drop ins Fensterchen ziehen. Ooops, jetzt sind es mehr als 700 MB geworden, na, dann nehme ich das halt wieder raus. Eine GUI kann hier sehr wohl Sinn machen...!
Ja, das ist der Punkt, über den ich auch schon viel nachgedacht habe, wie man das mit einem Script hinbekommen könnte, wenn man alle Links eines Verzeichnisses brennt. Das ist ein klarer Vorteil eines GUIs. Ich helfe mir dadurch, dass ich parallel eine Shell aufmache, und mit "du" überprüfe, ob ich schon zuviel brennen möchte. Diese Brennsituation habe ich aber hier so gut wie nicht. Die Sicherung ist so definiert, dass sie normalerweise auf den Rohling passt.
Ja, siehe oben. Das passt zu dem, was ich schrieb. Fuer automatisierte Vorgaenge sind vermutlich Skripte besser, aber um sich eine CD/DVD zusammenzustellen, da mag die GUI wahrlich Vorteile haben. Das einfache hinzufuegen bzw. herausnehmen von Dateien oder Verzeichnissen empfinde ich da schon deutlich als Vorteil, obwohl ich - nebenbei bemerkt - auch zwei Skripte zum Brennen habe :-) Je nach Situation eben.
Man installiert _1x_ ein Programm (z.B. k3b) und nutzt es, wobei man direkt die Optionen vor dem Brennen waehlen kann, klickt sich seine zu brennenden Daten zusammen und los gehts...
Das ist für mich genau der _entscheidende_ Punkt für ein Script, ob man das haben will. Und natürlich jeder wie er will. Ich will mir über die Brennoptionen nicht _jedesmal_ Gedanken machen müssen und dann auf irgendetwas vergessen, speziell weil ich dieses Brennszenario schon länger nicht hatte. [...] So weit ich gesehen habe, läßt sich das zum Teil bei k3b aber über Projekte lösen.
Du kannst bei k3b auch Einstellungen speichern und beim naechsten Mal wieder verwenden, das geht. Ich denke, es haengt schlicht vom Einsatz ab, fuer was man die GUI/das Skript braucht - einmal macht eben mehr das Eine Sinn, einmal eher das Andere.
[...] Ich habe ja nur auf die Alternative hingewiesen.
Das ist auch gut so! Fuer mich klang allerdings ein (Zitat von Dir) "Wozu brauchst du k3b bzw. ein GUI? Bau dir ein simples Kommandozeilenscript und verwende das letzte cdrecord-pro." eher nicht wie ein Alternativvorschlag, sondern wie das Verdammen aller GUIs. Und deswegen habe ich eben meine Meinung dazu geaeussert, dass GUIs sehr wohl Sinn machen koennen, auch beim Brennen.
Ich sehe da auch keinen Zusammenhang zu einem _Brenn_Programm. K3b ist ja aber auch ein GUI zum CDs auslesen und ich weiß nicht, ob man so etwas mit k3b hinbekommen kann:
"$CDDA2W" --device $DEVICEPAR --auxdevice $AUXILDEVICE --speed $DEVSPEED --max set-overlap=2 -paranoia -paraopts=retries=64 duration=0 $TRACKS --verbose-level $VERBOSLEVEL --gui --deemphasize --cddb 1 cddbp-server="$CDDBSERVER" cddbp-port="$CDDBPORT" "$CDMATCHCODE".wav
Du kannst auch bei k3b jedem Programm beliebige Optionen mitgeben, solange sie eben Sinn machen. Ich habe jetzt nicht genau nachvollzogen, was Dein Aufruf macht, aber in gewissem (vollem? keine Ahnung) Umfang wird das sicher auch k3b koennen. Gruesse, Thomson