Bestes Brennprogramm unter Linux ?

[Hans]

Hi !
Welches ist denn Eurer Meinung nach das ausgereifteste Brenn-Programm unter Linux ? Ich weiss schon, dass es hier auf PL auch einen Artikel zu dem Thema gibt, aber der ist wohl "etwas" veraltet (stammt von 2000)...

Greets, Hans

[heinbloed]

Also bestes.....das sind eigentlich nur frafische Frontens für die KonsolenProgis...cdrecord,cdrdao usw.
Für Daten CDs zu kopieren nehme ich KonCD...weil diese als einzigstes mein CDROM als Lesegerät akzeptiert
MusikCDs Kpoiere ich mit xcdroast
VCDS kopiere ich mit gcdmaster
Musikcds und DatenCDs erstelle ich mit Kreatecd.....
Ich meine das ich mir damit die >Sahnestückchen zusammengestellt habe
Gruss Hein*

[hey]

Nicht zu vergessen

keasycd
cdbakeoven
gnometoaster

[Johannes Weißl]

cdrecord -v dev=0,1,0 speed=8 image.iso

aber wenn du unbedingt ein grafisches programm wünscht, dann nimm xcdroast

[templer]

Ich persönlich bevorzuge cdbakeoven...aber eigentlich ist es wie immer geschmackssache

[sdu]

cdrecord - !!!!

mfd SDU

[BO]

ich bin auch zu 99% 'zu fuß' mit mkisofs, cdrecord & cdrdao schneller unterwegs, als mit irgendeiner gui

[AndreasW]

Unterstützt eins der Programme auch On the Fly Kopien?

[heinbloed]

....KonCD unterstützt on the Fly bei DatenCDs und erkennt als einzigstes auch ein ATAPI-Laufwerk....

[Johannes Weißl]

on the fly ?!
on the pipe ?!

wie wärs damit: das image erstellen, und während dem erstellen auf stdout schreiben,
und dann von cdrecord über eine Pipe lesen lassen und brennen ...
aber das führt wahrscheinlich zu nem Buffer Underrun, oder ?

mir schwant da sowas:
mkisofs -r ~/testfolder | cdrecord -v fs=6m speed=8 dev=0,1,0 -

Wer probierts aus und verschwendet möglicherweise einen Rohling ?!

[Bartolomeus]

@heinbloed
Entschuldigung für die Kritik, aber es heist immer noch "einziges" (genau wie einziger und einzige, ganz Standard(t)mäßig und außerdem ist es schlichtweg Falsch. Versuch doch mal etwas über das Modul "ide-scsi" rauszufinden!

...

Irgendwo habe ich mal gelesen, daß das Team? von 'cdrecord' noch Programmierer sucht. Dabei war ein leicht frustrierter "Unterton" nicht zu überlesen, denn ganz unverblümt stand da: "...natürlich macht es viel mehr Spaß eine GUI zu Programmieren, als mir zu helfen..." .... was ich damit eigentlich sagen wollt, es ist so ziemlich egal welche graphische Oberfläche du nimmst, denn unter fast allen steckt ja 'eh cdrecord. Und welchen Syntax man auf der Konsole (die meiner Meinung nach schnellste Methode um eine CD zu erstellen;) verwenden muß (auch zum OnTheFly/CD-Kopieren) steht im Manual.

...Und noch etwas: Einige GUI's haben z.B. Option von cdrecord wie z.B. -multi (für Multisession CD's) noch nicht implementiert. Sollte man bei seiner Wahl evtl. auch berücksichtigen.

RU

[Bartolomeus]

...man ist klar im Vorteil, wenn man lesen kann...
(wenn's denn noch klappt nach'nem langen Arbeitstag)

...es scheint sich hier ja klar um einen 'Joke-Thread' zu handeln. Also entschuldige ich mich hiermit für meine vollkommen Humorlose, obige Bemerkung...

[heinbloed]

@ Bartolomeus
Danke -ich kann Kritik vertragen <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

[AndreasW]

Johannes, die neuen Brenner können alle auch nach Unterbrechung des Datenstroms den Brennvorgang weiterführen, also ist es ziemliche Zeitverschwendung zuerst ein Image zu erstellen und dann dieses zu Brennen, wenn man doch gleich onthefly Brennen kann.

Übrigens ging onthefly auch schon recht gut mit älteren Brennern, die kein "Burn Proof" oder ähnliches unterstützen, nur musste man da halt drauf achten, dass a) der Rechner schnell genug ist und b) dass man das CD ROM nicht noch für was anderes verwendet.

Aber wie gesagt heutzutage ist es eigentlich egal, wieviele Dinge man noch mit dem Rechner während des Brennens tut, es gibt einfach keien Buffer Underuns mehr.

[Johannes Weißl]

ähm, naja ...
was heißt "direkt" brennen ?! die daten müssen ein besonderes format für die CD haben ...

meine Lösung
mkisofs -r ~/testfolder | cdrecord -v fs=6m speed=8 dev=0,1,0 -
ist doch on-the-fly, oder ?!
mkisofs schreibt das image auf die standartausgabe, und die wird mit der pipe an cdrecord geschickt, welches die Daten dann brennt ...

ich habs jetzt mal ausprobiert, und es kommt wirklich sogar bei starker belastung zu keinem buffer-underrun ...