Am Mittwoch, 31. Dezember 2003 10:03 schrieb Thomas Hertweck:
Al Bogner wrote:
Am Dienstag, 30. Dezember 2003 23:10 schrieb Moritz Donhauser:
ich habe zu weihnachten einen dvd brenner (plextor px-708) bekommen. Da ich derzeitig suse 8.2 verwende will ich ihn mit diesem betriebsystem nutzen und nicht kurzerhand auf 9.0 umsteigen.
Wozu brauchst du k3b bzw. ein GUI? Bau dir ein simples Kommandozeilenscript und verwende das letzte cdrecord-pro.
Schnickschnack. Wenn er eine GUI moechte, lass ihn eine GUI benutzen, man kann/darf/sollte niemanden zur Kommandozeile zwingen.
Da gebe ich dir voll recht. Ich benutze meist auch ein GUI lieber als ein Script. Ich kenne die Wünsche und den Stand der Linux-Kenntnisse des OP nicht. Ich wollte einfach nur mal auf die Alternative Kommandozeile hinweisen und die Optionen nennen, die sich für _mich_ als sinnvoll erwiesen haben. IMO ist es am schwierigsten die Optionen zu finden, die man wirklich braucht, um gute Ergebnisse zu brennen. Ein Freund von mir, ehemals Sysadmin von > 1000 Rechnern brannte aus _Gewohnheit_ auch mit k3b und will nun mein Script verwenden, weil wir beide ähnliche Brennbedürfnisse haben. 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. Ich brenne zB auch meine mp3s fürs Auto per Script, so nach dem Motto, heute habe ich eine längere Autofahrt vor und habe dazu zB Lust "Weltmusik" zu hören. Also lieber Computer, sieh in der mysql-DB mal nach, was ich davon habe, such die Dateien zusammen, benenne sie so um, dass mein Autoplayer die ersten 12 Alben über die Stationstasten ansprechen kann, etc. Solche Brennszenarien lassen sich IMO am besten mit einem eigenen Programm umsetzen und da ich meine Shell-Kenntnisse vertiefen wollte, habe ich dafür die bash verwendet und nicht Perl, Python oder was immer. Bei so was merkt man dann schon die Grenzen der Bash, man hat aber dazu gelernt, dass es irgendwie doch geht, wenn auch manchmal nicht sehr elegant. Das wichtigste aber für mich ist, dass es funktioniert. Ich gebe aber auch zu, dass ich mich aufgrund meiner _funktionierenden_, wenn auch manchmal aufgrund der Anfangsfehler etwas holprig formulierten Scripts, nicht so sehr mit k3b, xcdroast, etc. beschäftigt habe. Wie gesagt, entscheidend ist für mich, dass es funktioniert, ob das Brennen aufgrund einer suboptimalen Formulierung 1 oder ein paar Sekunden länger dauert, ist für die Sache egal, aber natürlich lernt man immer gerne was dazu. Für mich habe ich beschlossen, funktionierende Srcripts, wenn auch nicht so optimal formuliert, in Ruhe zu lassen und es bei neuen Scripts besser zu machen.
Wenn ich sehe (und hier auf der Liste miterlebe), was Du fuer Skripte versuchst zu schreiben, die dann am Ende vielleicht doch nicht das machen, was sie sollen (wovon ich aber bei Dir jetzt mal nicht ausgehen moechte, nachdem Du so lange dran rumgedoktert hast), sorry, dann nehme ich lieber gleich k3b, was IMHO ein ganz gutes Programm zum Brennen ist.
Erstens, jeder soll so brennen will, wie es für ihn am besten ist. Das steht völlig außer Diskussion und ich will keinen von einer Kommandozeile bzw. Script überzeugen. Bei Problemen sollte man aber überlegen, wie man persönlich schneller zum Ziel kommt. Ein KDE-Update ist ja auch nicht ganz unproblematisch. Über k3b kann ich mir kein Urteil erlauben, da ich mir nur die Oberfläche angesehen habe.
Kommandozeile ist manchmal vorteilhaft, aber nicht immer, und fuer jemanden, der vielleicht von Windows umsteigt und neu bei Linux ist schon mal gar nicht.
Das hängt immer von den Vorkenntnissen ab. Ich bin vom Mac auf Linux umgestiegen und da war ich nur Klicken gewöhnt. Vi etc. war für mich anfangs Horror, um das ich einen großen Bogen machte. Ich _wollte_ aber Dinge mit Linux realisieren und meine ersten Trvial-Scripts ohne Variablen, einfach Komandozeile nach Kommandozeile schrieb ich ganz schnell, u.a. waren das meine Scripts zum Brennen, die auch Jahre nicht geändert wurden, bis vor ein paar Monaten Bedarf da war, weil mir das Ändern der Scripts für unterschiedliche Rechner schön langsam auf die Nerven ging und seitdem entwickelte sich das Script zu einer Größe von ein paar hundert Zeilen, weil meine 11-jährige Tochter verlangte, dass es immer "DAU-sicherer" wurde. Die brennt übrigens lieber auf der Konsole mit dem Script als mit k3b oder xcdroast.
Es bedarf Zeit, den Umgang mit der Kommandozeile zu lernen, und wenn man eben zu Beginn gleich mal eine CD gebrannt haben muss, dann ist das wohl nicht der richtige Weg, da dort die Frusterlebnisse meist eindeutig ueberwiegen.
Wenn man überhaupt keine Ahnung von der Kommandozeile hat, ja. Der OP sprach aber auch von einem DVD-Brenner und meinen Frust bzgl. DVD-Brennen beginne ich erst seit kurzem los zu werden. Erst mit dem 3. Brennprogramm (cdrecord-pro) klappte das Brennen, dafür aber sofort. Wie man zu "closed source" steht, muß natürlich jeder für sich entscheiden. 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. Die Gefahr ist groß, dass man dem Brenner oder dem Programm die Schuld gibt, obwohl der Rohling das Problem ist. Ohne Vergleichsmöglichkeiten mit anderer Hardware kann man manchmal nicht feststellen, woran es liegt.
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...! Diese Haltung, immer _alles_ an der Kommandozeile machen zu wollen, ist IMHO fehl am Platze. Dass es in gewissen Situationen Sinn macht, bestreitet sicher niemand.
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. Meine mp3-CDs fürs Auto füllt das Script automatisch auf Maximum. Bei 2 Audio-CDs, die sowieso nur mehr in Ausnahmefällen gebrannt werden, ich habe ja mp3, bestimmt das Script, was von einer 2. CD noch darauf passt und bei VideoDVDs ist die Dateigröße eher kein Problem beim Brennen, da das ja schon beim Authoring berücksichtigt wird. Andere Brennszenarien sind die große Ausnahme. Das mag natürlich bei jedem total unterschiedlich sein. Ich sehe für mich keine weiteren Brennnotwendigkeiten. Fertige-CDs /DVDs kopiere ich normalerweise nicht, sondern verwende die Dateien von der HD und wenn ich schon mal eine Sicherung meiner SuSE-Original-CDs machen will, dann verwende ich im wesentlichen nur #!/bin/bash cdrecord -v driveropts=burnfree -dao -overburn -isosize \ dev=0,0,0 fs=32m /dev/cdrom Wenn man diese 3 Zeilen, falls sie zur Hardware passen, in ein Script steckt, es zB "cdkopie" nennt, dann kann man durch simplen Aufruf bereits CD kopieren. Das sollte auch für einen Anfänger nicht allzu schwer sein.
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. Ich will nicht darüber nachdenken müssen, ob ich nun mit Brenner X dao oder raw brennen muß, weil ich CD-Text haben will. Ich will nicht darüber nachdenken müssen, dass ich für mp3 iso-level 1 haben will, aber für die Sicherung der mp3 iso-level 3 (meine mp3s wurden iso-level 3 konform bezeichnet), etc. So weit ich gesehen habe, läßt sich das zum Teil bei k3b aber über Projekte lösen.
Wenn man mit den Features und Optionen, die k3b (oder ein anderes Brennprogramm bietet) zufrieden ist, warum soll man es dann nicht nutzen?
Klar!
Skripte, die "mehr" machen als k3b kann man sich im Laufe der Zeit immer noch selbst zusammenbasteln...
Ich habe ja nur auf die Alternative hingewiesen.
Zum Zusammenstellen einer DVD reicht k3b allemal, und uebers (illegale) Klonen von Musik/Film-DVDs moechte ich mich jetzt hier nicht auslassen.
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 Das hat nun nichts mit "illegal" zu tun, sondern mit zerkratzten CDs und der Qualität des CD-ROMs. Vor kurzem las ich, dass "--verbose-level all" ganz entscheidend ist, wie gut die CD ausgelesen werden kann und nicht nur einen Einfluß auf die Ausgabe hat. Ach ja, ich las auch, bei zerkratzten CDs kann ein "cdrecord -setdropts -force driveropts=singlesession" helfen, bevor man cdda2wav startet. Zum Glück habe ich nur ganz wenige CDs, die so zerkratzt sind, dass sie fehlerhaft ausgelesen werden. Leider half alles nichts. Da hilft nur ein Testen mit unterschiedlichen Optionen und manchmal war es dann umsonst. Ich habe nun etwas ausgeholt, aber wenn der OP direkt von Windows kommt, sieht er nun, dass es unter Linux Möglichkeiten gibt, die er vielleicht nicht gleich realisieren kann/will, weiß aber, wenn er mit k3b ansteht, dass da noch viele Dinge beim Brennen möglich sind, an die er bis jetzt nicht gedacht hat. Al