[solved] Disc T@2 unter Linux?

[Coolzero]

Hallo, gibt es unter Linux eine möglichkeit cd's mittels Disc T@2 zu gravieren?

 

[TomcatMJ]

Hi!
Cdrecord unterstützt das von Haus aus, allerdings ist mir bis dato kein grafisches für genau diese Funktion bekannt so daß man das dann wohl per Hand auf der Kommandozeile anwerfen muss. Im Originalpaket von Jörg Schillings cdrecord ist übrigens ein Readme zur Disct@2 Funktion enthalten.

Bis denne,
Tom

 

[Coolzero]

Min Englisch ist nicht so wirklich gut, deshalb komm ich mit der man Page nicht so wirklich zurecht!
Ich muss doch auch das bild erstellen welches auf die cd graviert werden soll

 

[mca]

da musst du wohl erstmal nero unter win starten. das geht dann mit dem coverdesigner-plugin. sollte bei dem brenner dabeiliegen.
ich meine, ohne echte englisch- und linux-kenntnisse haste erstmal keine chance mit cdrecord.
http://yamaha-online.de/html-section/cdrec/crwf1/disctatoo2.htm
ich hab das gefühl, die sind wahnsinnig stolz, dass es überhaupt mit nero klappt, und die neue nerolinux-demo kann auch kein cover designen. also geduld

 

[TomcatMJ]

Hi!
Mit cdrecord kann man sich anzeigen lassen wieviel Platz noch für ein Disct@2 übrig ist nach dem abschließen der Disc.
Wenn man dann noch ein schwarz-weiß JPEG hat was man dann auf die CD brutzeln will braucht man nur noch das Bild entsprechend konvertieren und kann es dann mit cdrecord wiederum auf die Cd bannen.
Für diese Konvertierung hatte ich vor einiger Zeit mal ein Script zusammengebastelt was aus Infos aus der cdrecord-Readme zum Thema Disct@2s und infos zu ImageMagick entsprungen war(ich weiss jetzt aber nicht mehr genau was nun alles woher war davon*G*).
vielleicht findet sich ja irgendwann mal ein Progger der Lust dazu hat aus dem gebastelten Script ein k3b-Plugin zu stricken?
Hier nun das Konvertierungsscript(Lizenz? Für so nen Einzeiler? Nagut,wenns denn sein muss sag ich mal BSD-Lizenz als Orientierungspunkt mit bitte um Quellenerwähnung*G*):

#!/bin/sh
# Jpeg->Disct@2 Konverterscript
# zur Konvertierung eines Vorhandenen JPEG auf bekannte für ein Disct@2 auf einer CD-R noch freie Maße 
# Eingangsbild=Parameter 1 Endgröße= Parameter 2 mal Parameter 3
djpeg $1 | ppmtopgm | pnmflip -lr | pnmscale -xsi $2 -ysi $3 | sed '1,/255/d' >./$1.disctattoo

Hier noch ein paar Scripte aus dem Kopf (bzw. unter Zuhilfenahme von "man cdrecord") dazu:
Shellscript zum Feststellen der Größe des noch freien Platzes:

#!/bin/sh
# Sizedetection für Disct@2
device=ATAPI:0,0,0
# oder welches Device auch immer der Brenner ist
cdrecord dev=$device driveropts=tattooinfo -checkdrive 
# Ausgabe ist unter anderem der freie Platz auf der abgeschlossenen CD-R

Und das zum eigentlichen Brennen auf die CD:

#!/bin/sh
# Parameter ist der Filename des Disct@2-Images aus dem ersten Script
device=ATAPI:0,0,0
# oder wie auch immer das Device des Brenners im konkreten Fall lautet
cdrecord dev=$device driveropts=tattoofile=$1 -checkdrive 
# Danach sollte die Cd entsprechend gebrannt mit Disct@2 automatisch von cdrecord aus dem Brenner ausgeworfen werden

Sollte so nun eigentlich funktionieren, allerdings habe ich gerade keine finalisierte CD-R zum Testen zur Hand

Bis denne,
Tom

 

[jengelh]

-dev=/dev/hdc

ATAPI:x,y,z ist deprecated.

 

[TomcatMJ]

Also das seh ich etwas anders:

...
scsidev: '/dev/hdc'
devname: '/dev/hdc'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
...

im Vergleich mit

...
scsidev: 'ATAPI:0,0,0'
devname: 'ATAPI'
scsibus: 0 target: 0 lun: 0
Warning: Using ATA Packet interface.
...

sagt mir a.) das der Weg über ATAPI erstens der offiziell vorgesehene ist und SuSE da mal wieder rumgepatcht hat was ja noch lang nicht bei jeder Distri so ist, und b.) hab ich die Erfahrung gemacht das bei dem Weg über /dev/hdc nur so jeder 3.-4. Versuch ein Ergebnis liefert, jedoch wenn ich da ATAPI:0,0,0 angebe jedesmal ein korrektes Ergebnis geliefert wird, wenn auch mit folgender Warnung die für Disct@2 allerdings nicht wirklich relevant ist, da diese Funktion eh nicht mit maximalen Speed zu empfehlen wäre da das Ergebnis langsam gebrannt deutlicher zu sehen ist:

...
Warning: The related Linux kernel interface code seems to be unmaintained.
Warning: There is absolutely NO DMA, operations thus are slow.
Using libscg version 'schily-0.8'.
...

Genau deswegen (nicht gegebene Zuverlässigkeit bei /dev/hdc Nutzung und bessere Ergebnisse bei langsamen brennen) nutze ich dabei halt die ATAPI-Schreibweise für das Device, allerdings eben nur wenns um Disct@2 geht
Ich würds also nicht als §deprecated" für diesen Fall ansehen zumal es ja eigentlich der vom Progger Jörg Schilling für sein cdrecord unter so ziemlich jedem Unixderivat (wo man grob gesehen ja auch Linux zuzählen kann) vorgesehen ist. Wenn SuSE da was rumpatcht damit es schneller läuft mag ja ok sein solang die Zuverlässigkeit nicht drunter leidet, aber gerade bei Disct@2 scheint das der Fall zu sein. Naja, ist ja auch eine "Exotenfunktionalität" und solang der offizielle eben immer noch geht ist das ja auch kein wirkliches Problem, aber ich würde sowas dann nicht als "veraltet und somit von abzuraten" ansehen sondern erstmal sehen was im Einzelfall besser läuft(=genauso brauchbare Ergebnisse bei mehr Stabilität oder Performance bringt)...

Bis denne,
Tom