Frage von Ernst Schmidt:Mit meinem DVD-Recorder (;DR 4912S von LG) habe ich auf eine DVD-RW einen
Film gebrannt.
Nun wollte ich den Film auf eine DVD-R kopieren.
In meinem Rechner befindet sich der DVD-Brenner GSA-4040B von LG.
Ich habe zwar zusätzlich noch ein DVD-Laufwerk in meinem Rechner, aber nur
dieser Brenner kann DVD-RWs lesen.
Also muß ich den Film erst von der DVD-RW auf Festplatte speichern, um ihn
dann auf DVD-R brennen zu können. Doch genau das ist mein Problem.
Zunächst noch folgende Informationen:
Mit PowerDVD Version 4 kann ich den Film ohne Probleme
abspielen; wenn ich jedoch im Explorer auf den Laufwerksbuchstaben
des DVD-Brenners klicke, kommt die Meldung "Auf G: kann nicht zugegriffen
werden. Unzulässige Funktion."
Zum Zwischenspeichern des Films auf Festplatte wollte ich nun mit
WinOnCD DVD Edition 6 ein Image erzeugen.
Dazu wählte ich beim Start von WinOnCD "Copy Projekt öffnen".
Nun habe ich Image schreiben gewählt und auf den Knopf zum Schreiben geklickt.
Dann kommt jedoch nur kurz die Meldung Untersuche CD/Lese Inhaltsverzeichnis
ansonsten passiert nichts.
Außerdem besitze ich noch Nero 5.Dort habe ich CD kopieren und dann Brennen
gewählt, aber dann kommt die Meldung ungültige Trackinfo.
Kann es sein, daß WinOnCD die DVD-RW nicht lesen kann (;denn über den Explorer
konnte ich sie ja auch nicht lesen)? Aber wenn die DVD-RW vom Explorer und
von WinOnCD nicht gelesen werden kann, warum kann PowerDVD sie dann abspielen?
Wie kann ich ein Image der DVD-RW erzeugen?
Danke für alle Antworten.
Ernst Schmidt
Antwort von Jan Peter Stotz:
Ein ISO-Image von einer Film-DVD dürfte schwierig werden, denn die sind
normalerweise in UDF beschrieben.
Ernst Schmidt schrieb:
> Zum Zwischenspeichern des Films auf Festplatte wollte ich nun mit
> WinOnCD DVD Edition 6 ein Image erzeugen.
> Dazu wählte ich beim Start von WinOnCD "Copy Projekt öffnen".
> Nun habe ich Image schreiben gewählt und auf den Knopf zum Schreiben geklickt.
> Dann kommt jedoch nur kurz die Meldung Untersuche CD/Lese Inhaltsverzeichnis
> ansonsten passiert nichts.
Eventuell kennt WinOnCD die verwendete UDF-Version nicht. Es gibt
mittlerweile einige Varianten mit denen auch nicht alle Windows-Versionen
etwas anfangen können.
> Außerdem besitze ich noch Nero 5.Dort habe ich CD kopieren und dann Brennen
> gewählt, aber dann kommt die Meldung ungültige Trackinfo.
Mit "CD kopieren" bei eine DVD kann man auch nicht weit kommen...
Jan
Antwort von Andre Beck:
Jan Peter Stotz
writes:
>
> Ein ISO-Image von einer Film-DVD dürfte schwierig werden, denn die sind
> normalerweise in UDF beschrieben.
Deswegen sagt man besser Image. Auch vor UDF und DVD habe ich schon
Images von CD-ROMs gemacht, egal ob da ein ISO9660, ein ext2 oder
ein ufs drauf war. Bei CD-ROM ist das trivial - ein Image ist schlicht
der blockweise Abzug des einzigen Datentracks, dessen Inhalt ist dabei
vollkommen schnurz. Nur irgendwelche Windows-Clickware verwirrt mal
wieder Anwender, indem sie irgend ein ISO hinzuerfindet (;oder gar
völlig überflüssige eigene Imageformate¹).
Eine DVD-V ist nun nix weiter als eine spezielle Anwendung einer DVD-ROM,
also ist es hier exakt so trivial wie bei CD-ROM. Essenziell reicht zum
Erzeugen eines Image auf mitdenkenden Plattformen also der simpelste
Befehl aller Zeiten, nämlich cat(;1):
# cat /dev/dvd > my-dvd.img
Und brennen würde man das dann z.B. mit
# growisofs -Z /dev/dvd%my-dvd.img
Aber klar, man kann sich das Leben natürlich auch schwer machen mit
Monstrositäten á la WinOnCD oder Nero ;)
¹) Nichts gegen spezialisierte Imageformate für die CD-Anwendungsfälle,
die über CD-ROM hinausgehen. Aber da existierte CUE/BIN auch lange
vor dem ganzen Quark, den EWMS-Programme später noch erfinden mussten.
Und für DVD ist das irrelevant, da dort alle bisher existenten
Applikationen auf DVD-ROM aufbauen.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Udo Wolter:
On 2004/10/09 19:02 you (;beck@ibh.de) transmitted structured data:
> Eine DVD-V ist nun nix weiter als eine spezielle Anwendung einer DVD-ROM,
> also ist es hier exakt so trivial wie bei CD-ROM. Essenziell reicht zum
> Erzeugen eines Image auf mitdenkenden Plattformen also der simpelste
> Befehl aller Zeiten, nämlich cat(;1):
> # cat /dev/dvd > my-dvd.img
Hm, es kommt ja selten vor, aber eigentlich nehme ich dafür lieber dd.
cat kann auch mal so abbrechen, da hatte ich schon komische
Effekte.
> Und brennen würde man das dann z.B. mit
>
> # growisofs -Z /dev/dvd%my-dvd.img
Wenn es vorher eine CSS-geschützte DVD war (;böse, sowas darf man natürlich
überhaupt nicht, weil CSS ja ein "wirksamer Kopierschutz" ist, haha),
dann geht das aber nur mit R/ RWs. Denn bei -R/-RW ist die CSS-Spur nicht
beschreibbar. Insofern also: nicht machen !
> Aber klar, man kann sich das Leben natürlich auch schwer machen mit
> Monstrositäten á la WinOnCD oder Nero ;)
Das braucht jemand ? :) Hey, das ist unfair, Windows-User haben genug
Probleme, man muß nicht noch auf ihnen rumtreten. Sei doch froh, daß Du's
einfacher hast.
Mermgfurt,
Udo
--
Udo Wolter | /"
email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN
www: www.dicke-aersche.de | X AGAINST HTML MAIL
dark: heaven@lutz-ziffer.de | /
Antwort von Andre Beck:
Udo Wolter writes:
> On 2004/10/09 19:02 you (;beck@ibh.de) transmitted structured data:
>> Eine DVD-V ist nun nix weiter als eine spezielle Anwendung einer DVD-ROM,
>> also ist es hier exakt so trivial wie bei CD-ROM. Essenziell reicht zum
>> Erzeugen eines Image auf mitdenkenden Plattformen also der simpelste
>> Befehl aller Zeiten, nämlich cat(;1):
>> # cat /dev/dvd > my-dvd.img
>
> Hm, es kommt ja selten vor, aber eigentlich nehme ich dafür lieber dd.
Das ist unter anderen Unixoiden u.U. relevant, nicht aber unter Linux.
Der wesentliche Vorteil von dd ist, dass es geblockt zugreifen kann,
also auch zum Lesen und Schreiben von echten block devices taugt. Man
hat es daher früher gern mit Platten, Bändern und sowas verwendet. Bei
Linux sind aber block devices praktisch immer gleichzeitig frei zugreif-
bar, ahmen also diesen Aspekt von character devices nach, ohne dass der
Userspace sich darum kümmern muss. Das macht den Zugriff über STDIO
völlig gleichwertig.
> cat kann auch mal so abbrechen, da hatte ich schon komische
> Effekte.
Wo cat abbräche, bricht dd genau so ab. Es gibt zwar ein dd rescue, aber
das ist wieder eine andere Geschichte. Glaub mir, ich kopiere unter
Linux seit *Jahren* Disketten, Platten, Partitionen, CD/DVD und Bänder mit
STDIO, also cat, netcat oder direkter E/A-Umlenkung, und hatte *nie* ein
Problem damit. Man muss nur wissen, dass das nicht 1:1 auf klassische
Unixe zu übertragen ist, Rumgemache mit Bandgeräten unter Solaris etwa
sollte tunlichst mit dd erfolgen.
Der große Vorteil von dd ist natürlich, dass man mehr Parameter hat. So
erschauere ich immer, wenn ich irgendwo etwas wie
dd if=/dev/zero of%disk.img bs%1m count24
lese, was ein Disk-Image für Loopmounts/UML werden soll. Das kann man
sehr viel einfacher haben:
dd if=/dev/zero of%disk.img bs1 count1 seek73741823
Das geht Größenordnungen schneller und ganz nebenbei ist das Resultat
auch noch sparse. Sowas geht wirklich nicht mit cat.
>> Und brennen würde man das dann z.B. mit
>>
>> # growisofs -Z /dev/dvd%my-dvd.img
>
> Wenn es vorher eine CSS-geschützte DVD war (;böse, sowas darf man natürlich
> überhaupt nicht, weil CSS ja ein "wirksamer Kopierschutz" ist, haha),
> dann geht das aber nur mit R/ RWs. Denn bei -R/-RW ist die CSS-Spur nicht
> beschreibbar. Insofern also: nicht machen !
Die CSS-Information ist überhaupt nicht Bestandteil des ROM-Parts¹, daher
ist das vollkommen irrelevant. Wäre der Ausgangspunkt eine CSS-DVD-V,
dann würde das nach Aktivierung des CSS-Decrypt im Laufwerk immer noch
exakt so funktionieren, ohne diese Entschlüsselung wäre das Image
hinterher einfach nur unbrauchbar. Da der Urposter aber explizit von
DVD-RW als Quelle sprach, ist das auch egal.
>> Aber klar, man kann sich das Leben natürlich auch schwer machen mit
>> Monstrositäten á la WinOnCD oder Nero ;)
>
> Das braucht jemand ? :) Hey, das ist unfair, Windows-User haben genug
> Probleme, man muß nicht noch auf ihnen rumtreten. Sei doch froh, daß Du's
> einfacher hast.
Och, die Arroganz, mit der einige Win-User ihren goldenen Käfig zu
übersehen pflegen, fordert schon hin und wieder ein paar Spitzen
heraus. Etwa, wenn wieder jemand Dateinamen mit Dateiinhalten ver-
wechselt. Man trifft zwar gewöhnlich die Falschen, aber Usenet hat
eh was von Schrotschießen an sich ;)
¹) Meines Wissens ist das Zeug auf spezielle Weise im Lead-In codiert,
so dass es ausschließlich dem Laufwerk zugänglich ist. Dieses
wiederum tätigt diese Zugriffe nur, wenn sich die Applikation
ihm gegenüber mittels einer kryptografischen Anmeldeprozedur
authentisiert hat. Der Zugriff auf die verschlüsselten ROM-Daten
wird also über spezielle SCSI²-Kommandos autorisiert. Ob man mittels
gepatchter Firmware prinzipiell in der Lage wäre, die CSS-Daten
im Lead-In einer R(;W) zu setzen, so dass das undekodierte
Image anschließend funktioniert, ist eine sehr interessante
Frage, die sicher früher oder später von jemandem (;wahrscheinlich
nicht in DE) rein wissenschaftlich untersucht wird. Ich glaube
es erst, wenn ich es gesehen^Wdavon verlässlich gelesen habe.
²) Ja, SCSI. ATAPI ist im wesentlichen auch nur SCSI-over-IDE.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Udo Wolter:
On 2004/10/09 22:25 you (;beck@ibh.de) transmitted structured data:
>> cat kann auch mal so abbrechen, da hatte ich schon komische
>> Effekte.
> Wo cat abbräche, bricht dd genau so ab. Es gibt zwar ein dd rescue, aber
Das war bei mir schon oft genug anders. Zumindest was Plattenkopieren
betrifft, geht's mit cat schief. Aber dd kann man eh viel besser
zur Optimierung nutzen.
> Das geht Größenordnungen schneller und ganz nebenbei ist das Resultat
> auch noch sparse. Sowas geht wirklich nicht mit cat.
Kein Widerspruch. Letztlich ist cat aber auch nicht für sowas gemacht
worden. Aber wir werden Off-Topic hier...
>> Das braucht jemand ? :) Hey, das ist unfair, Windows-User haben genug
>> Probleme, man muß nicht noch auf ihnen rumtreten. Sei doch froh, daß Du's
>> einfacher hast.
> Och, die Arroganz, mit der einige Win-User ihren goldenen Käfig zu
> übersehen pflegen, fordert schon hin und wieder ein paar Spitzen
Naja, mittlerweile kann man sich ja nur müde lächelnd zurücklehnen, wenn
die nächste Viren-/Trojaner-/Sonstwas-Welle läuft. Eigentlich überwiegt
in letzter Zeit eher Mitlight.
> heraus. Etwa, wenn wieder jemand Dateinamen mit Dateiinhalten ver-
> wechselt. Man trifft zwar gewöhnlich die Falschen, aber Usenet hat
> eh was von Schrotschießen an sich ;)
Ich sage mir immer: hier ballern schon genug, zu dem Wahnsinn muß
ich nicht beitragen. Letztlich poste ich hier nicht, um andere anzuscheißen,
sondern weil ich das Thema Video interessant finde, gerne Hilfe in
Anspruch nehme und deshalb auch Hilfen gebe (;ich doofer Moralist, ich).
Wo es zu hirnrissig wird, muß man ja nicht antworten, Trolle bleiben so
immer unter sich.
> ¹) Meines Wissens ist das Zeug auf spezielle Weise im Lead-In codiert,
> so dass es ausschließlich dem Laufwerk zugänglich ist. Dieses
Also wenn ich mir DVD-Rs genau betrachte, dann findet sich knapp ein
halber Zentimeter vom ersten Spurrand (;ausgehend von der Mitte natürlich)
eine gut sichtbare Spur. Die läßt sich auch nicht beschreiben. Bei DVD Rs
fehlt diese, also muß es doch einen Zusammenhang zwischen CSS und dieser
Spur geben, schließlich hat das DVD-Forum nicht umsonst auf 2 Sorten
beschreibbarer Minus-DVDs bestanden, den A- und den G-Rohlingen. G-Rohlinge
haben alle diese ausgegraute Spur. Ich habe übrigens noch nie einen
A-Rohling in der Hand gehabt. Gibt's die überhaupt ?
> authentisiert hat. Der Zugriff auf die verschlüsselten ROM-Daten
> wird also über spezielle SCSI²-Kommandos autorisiert. Ob man mittels
> gepatchter Firmware prinzipiell in der Lage wäre, die CSS-Daten
> im Lead-In einer R(;W) zu setzen, so dass das undekodierte
> Image anschließend funktioniert, ist eine sehr interessante
> Frage, die sicher früher oder später von jemandem (;wahrscheinlich
> nicht in DE) rein wissenschaftlich untersucht wird. Ich glaube
> es erst, wenn ich es gesehen^Wdavon verlässlich gelesen habe.
Ich muß zugeben, daß ich es nicht weiß, weil ich es nie ausprobiert habe
(;das wäre eh Blödsinn, wer will schon diesen riesigen Overkill an Qualität
mitnehmen, wenn er mal was kopiert, das macht doch keiner), nichtsdestotrotz
muß es ja irgendwie um diese komische "sinnfreie" Spur gehen.
> ²) Ja, SCSI. ATAPI ist im wesentlichen auch nur SCSI-over-IDE.
Im neuen kernel (;2.6.9-rc3) ist ATAPI Standard und nervt mich dadurch,
daß die dvd rw-tools (;also Dein besagtes growisofs, was ich für wesentlich
geschmeidiger halte als dvdrecord) nicht damit umgehen können, jedenfalls
nicht mit meinem NEC-Drive. Also bleibe ich bei reinem SCSI-over-IDE. Alleine
der Umstand, daß sie das mittlerweile sauber trennen, deutet darauf hin,
daß ATAPI nicht nur sowas wie SCSI-over-IDE ist, sondern durchaus
eine eigene, ernst zu nehmende Schiene ist.
Mermgfurt,
Udo
--
Udo Wolter | /"
email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN
www: www.dicke-aersche.de | X AGAINST HTML MAIL
dark: heaven@lutz-ziffer.de | /
Antwort von Andre Beck:
Udo Wolter writes:
> On 2004/10/09 22:25 you (;beck@ibh.de) transmitted structured data:
>>> cat kann auch mal so abbrechen, da hatte ich schon komische
>>> Effekte.
>> Wo cat abbräche, bricht dd genau so ab. Es gibt zwar ein dd rescue, aber
>
> Das war bei mir schon oft genug anders. Zumindest was Plattenkopieren
> betrifft, geht's mit cat schief.
Kann ich wie gesagt nicht nachvollziehen. Ich image Platten öfter mal
mit netcat, das ist noch nie schief gegangen. Bei einem I/O-Error fliegt
Dir dd genau so weg wie cat/netcat/gzip/whatever. Dort beginnt die
Domäne von dd rescue, das unlesbare Blöcke als Nullen kopiert und dann
beim nächsten Block weitermacht. Da ich an der Sicherheit meiner Daten
sehr interessiert bin, wüsste ich gern mehr über Szenarien, in denen dd
funktioniert, während cat (;also STDIO) schiefgeht. Gern auch in einer
anderen Gruppe. Ich würde es nur gern Linux-spezifisch halten, da wie
gesagt auf anderen Unixoiden objektive Gründe dafür sprechen, dass es
schiefgehen kann, nicht aber (;meines Wissens) unter Linux (;1.2 bis 2.6).
> Aber dd kann man eh viel besser zur Optimierung nutzen.
Yep, speziell was Blockgrößen angeht. Ein dd mit laufendem Feedback wäre
noch besser ;)
>> Das geht Größenordnungen schneller und ganz nebenbei ist das Resultat
>> auch noch sparse. Sowas geht wirklich nicht mit cat.
>
> Kein Widerspruch. Letztlich ist cat aber auch nicht für sowas gemacht
> worden. Aber wir werden Off-Topic hier...
Kein Widerspruch ;)
> Ich sage mir immer: hier ballern schon genug, zu dem Wahnsinn muß
> ich nicht beitragen. Letztlich poste ich hier nicht, um andere anzuscheißen,
Na komm, eine Spitze ist kein Anschiss. Ich hatte mein Posting IMO mit
genug sinnvoller Information gefüllt, die auch dem Win-User bei der
Lösung seines Problems helfen würde, weil sie das grundlegende Ver-
ständnis, wie eine DVD-V aufgebaut ist und wie simpel sie zu imagen
und kopieren wäre, fördert. Er steht höchstens vor dem Problem, für
seine Plattform passende Software zu finden, die genau das und nicht
mehr macht. Und vielleicht noch frei ist. Nun, er hat diese Plattform
gewählt, also ist das sein Problem. Oder er bootet dafür Knoppix ;)
>> ¹) Meines Wissens ist das Zeug auf spezielle Weise im Lead-In codiert,
>> so dass es ausschließlich dem Laufwerk zugänglich ist. Dieses
>
> Also wenn ich mir DVD-Rs genau betrachte, dann findet sich knapp ein
> halber Zentimeter vom ersten Spurrand (;ausgehend von der Mitte natürlich)
> eine gut sichtbare Spur. Die läßt sich auch nicht beschreiben.
Die ist vorbeschrieben. Allerdings ist die wie gesagt im Lead-In-Bereich
und ließe sich auch nicht direkt beschreiben, wenn sie nicht bereits
zerbröselt wäre. Du kommst da mit dem Kommandosatz Deines G-Brenners
nicht mal in die Nähe (;anders als lesend im Sinne der Authentisierungs-
prozedur).
> Bei DVD Rs fehlt diese, also muß es doch einen Zusammenhang zwischen
> CSS und dieser Spur geben,
Natürlich, sagte ich doch: Das ist der Bereich im Lead-In, wo die für
CSS relevanten Informationen (;zulässige Playerkeys etc) stehen. Nur ist
der eben nicht Teil einer eventuellen ROM-Session, er ist komplett out
of band und kann nur mit speziellen Kommandos erreicht werden und nur
zu dem Zweck, das dekodierte Lesen von kodierten Scheiben durch das
Lufwerk zu aktivieren.
> schließlich hat das DVD-Forum nicht umsonst auf 2 Sorten
> beschreibbarer Minus-DVDs bestanden, den A- und den G-Rohlingen. G-Rohlinge
> haben alle diese ausgegraute Spur. Ich habe übrigens noch nie einen
> A-Rohling in der Hand gehabt. Gibt's die überhaupt ?
Ja, klar, für größere zweistellige Euro-Beträge pro Exemplar. Zusammen
mit dem entsprechenden A-wie-Authoring-Brenner (;heute schon sehr günstig
im vierstelligen Bereich erhältlich, jedenfalls AFAIK) hat man dann auch
die Chance, diese Daten zu setzen, was wieder über spezielle Steuer-
kommandos gehen wird, die der Brenner dann beim Schreiben des Lead-In
umsetzt. Preislich ist das alles wohl sogar noch unter einem ordentlichen
DLT-Drive und Cartridge, aber ehrlich gesagt wäre mir letzteres trotzdem
lieber, wenn ich professionell authorn müsste. Nur *testen* kann man
nur mit dem A-Medium und -Brenner.
>> authentisiert hat. Der Zugriff auf die verschlüsselten ROM-Daten
>> wird also über spezielle SCSI²-Kommandos autorisiert. Ob man mittels
>> gepatchter Firmware prinzipiell in der Lage wäre, die CSS-Daten
>> im Lead-In einer R(;W) zu setzen, so dass das undekodierte
>> Image anschließend funktioniert, ist eine sehr interessante
>> Frage, die sicher früher oder später von jemandem (;wahrscheinlich
>> nicht in DE) rein wissenschaftlich untersucht wird. Ich glaube
>> es erst, wenn ich es gesehen^Wdavon verlässlich gelesen habe.
>
> Ich muß zugeben, daß ich es nicht weiß, weil ich es nie ausprobiert habe
> (;das wäre eh Blödsinn, wer will schon diesen riesigen Overkill an Qualität
> mitnehmen, wenn er mal was kopiert, das macht doch keiner), nichtsdestotrotz
> muß es ja irgendwie um diese komische "sinnfreie" Spur gehen.
Nun, das DVD-Forum hat offenbar erkannt, dass es fatal wäre, wenn der
gewöhnliche Joe User diese CSS-Parameter auf DVD-R schreiben könnte.
Das würde nämlich jegliche der unrühmlichen Regelungen, wie wir sie
hier inzwischen auch haben, die also das *knacken* eines Kopierschutz
(;und sei es noch so trivial) unzulässig machen, zu Makulatur erklären.
Man kann dann nämlich DVD kopieren, ohne dabei irgendwas zu knacken,
das übernimmt weiterhin der (;erstaunlicherweise legale) DVD-Player.
Also erfand man zwei getrennte Medien: General Use und Authoring Use.
Um die Sache für Firmwarehacker etwas zu erschweren, nutzen die auch
unterschiedliche Laser-Wellenlängen.
Dann kam das subversive -Panel um Philips und meinte, dass es reicht,
wenn der Brenner (;also seine Firmware) das manipulieren des Lead-In
wirkungsvoll verhindert. Lassen wir uns einfach überraschen, wann der
erste Firmwarehacker das umgedreht hat.
>> ²) Ja, SCSI. ATAPI ist im wesentlichen auch nur SCSI-over-IDE.
>
> Im neuen kernel (;2.6.9-rc3) ist ATAPI Standard und nervt mich dadurch,
> daß die dvd rw-tools (;also Dein besagtes growisofs, was ich für wesentlich
> geschmeidiger halte als dvdrecord) nicht damit umgehen können, jedenfalls
> nicht mit meinem NEC-Drive.
Ich umgehe dieses Problem dadurch, dass mein DVD-Brenner in einer
externen Box sitzt, die per Firewire oder USB2 an den Rechner gehängt
wird. Das hat nur Vorteile, u.a. auch, dass es für Linux nach wie vor
SCSI ist, so wie sich das gehört. Und da ich nicht zu den Leuten gehöre,
die zwanghaft DVDs brennen, ist das Ding meistens aus und verheizt weder
Strom noch altert es sinnlos.
> Also bleibe ich bei reinem SCSI-over-IDE. Alleine
> der Umstand, daß sie das mittlerweile sauber trennen, deutet darauf hin,
> daß ATAPI nicht nur sowas wie SCSI-over-IDE ist, sondern durchaus
> eine eigene, ernst zu nehmende Schiene ist.
Ich schrieb "im wesentlichen", was Abweichungen im Detail zulässt.
Sicher divergiert da einiges, aber ATAPI ist aus SCSI hervorgegangen
(;damals, als es CD-Laufwerke anfangs nur mit SCSI gab und dann die
ersten für IDE gestrickt wurden - man hat einfach den bewährten
Steuerkommandosatz irgendwie auf ATA gepfropft) und momentan ist
es sogar teilweise wieder am konvergieren (;SATA/SAS). Das Gerangel
um die IDE-SCSI-Emu im Kernel hat weniger technische Gründe als
vielmehr soziologische, aber das wäre nun hier tatsächlich OT ;)
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
