|
Aktuelle Zeit: Montag 25. November 2024, 00:19
|
Unbeantwortete Themen | Aktive Themen
|
|
|
|
Autor |
Nachricht |
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 12:22 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
ATIP - das sind die Rohlingsdaten (Hersteller + Mediencodes und Brennerbezeichnung) Bei manchen Spielen mit Safedisc werden sie mit ausgelesen, weil man verstanden hat, daß manche Brenner die ,,schwachen Sektoren" brennen können und haben diese Erkennung noch mit hinzugefügt. Wenn diese ,,ATIP" erkannt wird, greift leider der Kopierschutz und das Spiel startet nicht. Das kann man durch die Funktion ,,ATIP verstecken" beim CloneCD-Tray aber verstecken und schon läuft die Kopie. Ein Emulator ist wahrscheinlich weniger aufwendig. Safedisc funktioniert über eine digitale Signatur, die aus ,,schwachen Sektoren" besteht. Nicht alle brennen diese Sektoren auch in dieser Stärke.
Der Sheep-Test soll mit einfachen Mitteln zeigen, ob der Brenner verschiedene Version von Safedisc brennen kann oder nicht. Bis Safedisc 2.5 schaffen fast alle. Bis Safedisc 2.8 ist ein sogenannter Sheep2-Test, den wohl fast alle bestehen werden. Dann gibt´s noch den komplizierteren Sheep3-Test, der wohl von der Itensität dem Safedisc 3.2 zuzuordnen ist und den besteht wie ich weiß so keiner. Da brennt man es auf eine CD und versucht es auszulesen, wenn Fehlermeldung kommt, dann ist er nicht geglückt. Wie geschrieben das macht so kein Brenner freiwillig, da muß man Zusatzfunktionen des Chipsatzes und der Software verwenden, um dieses Wunder zu schaffen.
Aber Safedisc für CD ist schon fast ein alter Hut und gibt´s fast nur noch auf DVD zu kaufen bzw. neuere Spiele.
Securom New auf CD schafft nur der Plextor Premium ohne Emulation.
Alles andere ist nicht möglich. Nicht jedes Laufwerk kommt mit jedem Audiokopierschutz zurecht und da stehen die LiteON´s gut da und wahrscheinlich auch Plextor mit einer kleinen Einstellung. Der ,,Redfox" (Programm) soll es aber für jedes Laufwerk ermöglichen, daß man eigentlich jeden beliebigen Audiokopierschutz trotzdem lesen kann.
Andere wissen da sicher besser Bescheid.
|
|
|
|
|
Hotz
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 12:29 |
Gefällt's hier richtig gut |
Registriert: Dienstag 1. November 2005, 16:11 Beiträge: 270
|
Imperia hat geschrieben: Da brennt man es auf eine CD und versucht es auszulesen, wenn Fehlermeldung kommt, dann ist er nicht geglückt. Wie geschrieben das macht so kein Brenner freiwillig, da muß man Zusatzfunktionen des Chipsatzes und der Software verwenden, um dieses Wunder zu schaffen.
Und dieses Wunder, wie du es nennst, kann nero nun mal nicht vollbringen. Deshalb sind deine Aussagen zu "verstärkten Sektoren" beim sheeptest nicht zutreffend. Es handelt sich nicht um eine Zusatzfunktion des Chipsatzes, sondern die Software (CloneCD, Alcohol und Co) liefert dem Chipsatz einfach andere Daten, mit denen er womöglich "lesbarere" Ergebnisse produziert.
|
|
|
|
|
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 12:41 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
Da hast Du wahrscheinlich Recht. Bei CloneCD werden die Daten bearbeitet. Aber das ist längst nicht für jedes Gerät mit jedem Chipsatz!machbar, diese Daten so zu schreiben. Ich habe aber nichts mit ,,verstärkten Sektoren" geschrieben in diesem Fall.
|
|
|
|
|
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 12:44 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
Kann CloneCD die EFM-Fähigkeit meines Brenners verbessern bzw. die Fähigkeit, regelmäßige Bitmuster zu schreiben?
Den EFM-Codierungs- und Decodierungsprozess kann man, technisch gesehen, nicht optimieren, weil er schon perfekt ist. Das Problem heißt vielmehr DSV.
Wie funktioniert eine EFM-Encodierung?
Nach dem Scrambeln und Hinzufügen aller Fehlerkorrekturdaten und Subchanneldaten wird der Datenstrom dem EFM-Encoder zugeführt. Dieser erzeugt aus jedem Byte 14 sog. Channelbits. Diese werden aus einer Tabelle entnommen.
Weiterhin werden zwischen 2 solchen 14-Bit-Ketten jeweils 3 weitere Channelbits, sog. Mergebits, eingefügt. Die Mergebits sollen sicherstellen, daß die Bedingung, daß zwischen 2 Einsen immer 2 bis 10 Nullen stehen, eingehalten wird.
Diese EFM-Encodierung geschieht nach einem sehr einfachen Algorithmus, bei dem generell nichts schief gehen kann. Jeder Brenner beherrscht das richtige EFM-Encodieren regelmäßiger Bitmuster. Das wahre Problem tritt später auf: Das, was der EFM-Encoder ausgibt, wird NRZI-encodiert, d.h. die Channelbits werden in eine Folge von Pits und Lands umwandelt.
Schwache Sektoren haben die unangenehme Eigenschaft, daß die Anzahl der Pits erheblich von der der Lands abweicht. Die Differenz Anzahl Pits - Anzahl Lands heißt DSV. Schwache Sektoren haben also eine betragsmäßig große DSV. Und genau das ist schwer zu schreiben und auch schwer zu lesen. All das hat jedoch nichts mit korrekter EFM-Encodierung zu tun. CloneCD hat eine Lösung für dieses DSV-Problem gefunden, und das schon seit Version 4.0.1.3. (Mitte 2002). Die dazu benötigten MMC3-Befehle (Industriestandard für DAO-RAW Operationen) werden indes nicht von allen Brennern beherrscht.
Da sich leider die meisten Menschen immer den billigsten Brenner kaufen, anstatt auch ein wenig auf Qualität zu achten, gibt es seit Version 4.1.0.1. mit der Funktion 'schwache Sektoren emulieren' auch dafür eine Lösung. Leider gibt es dennoch Menschen, die diese Funktion wieder ausschalten und sich dann wundern, warum das Kopieren von Safedisc mit ihrem Brenner nicht funktioniert.
Ganz nett zu lesen - es hat nichts mit EFM zu tun.
|
|
|
|
|
Hotz
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 12:57 |
Gefällt's hier richtig gut |
Registriert: Dienstag 1. November 2005, 16:11 Beiträge: 270
|
Imperia hat geschrieben: Ich habe aber nichts mit ,,verstärkten Sektoren" geschrieben in diesem Fall. Wenn du etwas anderes mit dem "Befehl" gemeint hast, kannst du das ja noch etwas näher ausführen Imperia hat geschrieben: http://www.derLinkderwohlbesserraussollte.htmlGanz nett zu lesen - es hat nichts mit EFM zu tun. Die alten Beiträge bei brennmeister.com von alexnoe erklären es fast noch besser (nicht dass ich dessen Ausführungen jetzt wirklich im Detail nachvollziehen könnte )
|
|
|
|
|
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 13:08 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
Leider gibt´s Brennmeister nicht mehr, daß man nachsehen könnte. Über die MMC3-Befehle kann ich leider nichts sagen, auch nicht wie sie aussehen.
|
|
|
|
|
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 13:13 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
|
|
|
|
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 13:16 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
Ich nehme an, diese Person bist Du?
|
|
|
|
|
Imperia
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 13:36 |
Registriert: Sonntag 18. September 2005, 00:05 Beiträge: 2719 Wohnort: Leipzig
|
Wundert mich, daß Alex_Noe immer so selten hier ist. Würde auch gerne mal das richtige Prinzip davon erfahren.
|
|
|
|
|
Hotz
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 14:34 |
Gefällt's hier richtig gut |
Registriert: Dienstag 1. November 2005, 16:11 Beiträge: 270
|
Imperia hat geschrieben: Wundert mich, daß Alex_Noe immer so selten hier ist. Liegt vermutlich am wahren Leben. Imperia hat geschrieben: Würde auch gerne mal das richtige Prinzip davon erfahren. Habe auch noch einiges auf der Platte, im Moment finde ich aber nur das: alexnoe hat geschrieben: Diese Modulation wird vom Brenner vorgenommen, und zwar genau zwischen CIRC- und NRZI-Encodierung. Da kann auch kein Problem dazwischenfunken. Nur durch Übermittlung "anderer" Daten an den Brenner kann man das Ergebnis beeinflussen..... ....Jeder Brenner kann EFM. Aber das lernen die meisten wohl nie Das Problem sind die Merging bits *zwischen* dem Output des EFM-Encoders.... .... Ich habe die hälfte der letzten Semesterferien mit SafeDisc 2 verbracht, habe EFM-Encodierungen und Merging-Bit-Erzeugungen richtig mit Papier und Bleistift durchgeführt...und irgendwann gab plötzlich alles Sinn. Im Groben: Ein Sektor einer CD ist nur lesbar, wenn die Länge der Pits und die Länge der Lands in deren Summe etwa übereinstimmt (sonst erzeugt der Laser beim Lesen ein mieses Signal). Bei schwachen Sektoren werden Brenner dazu gebracht, gegen diese Auflage zu verstoßen und brennen Sektoren, wo diese Bedingung nicht erfüllt ist. Das Problem liegt nicht am EFM-Encoder, der 14 Bits pro Byte an Daten erzeugt, sondern am Merging Bit Generator, der noch jeweils 3 Bit zwischen 2 solche 14-Bit-Pakete dazwischensteckt. In den EFM-Codes bedeutet übrigens eine "1" einen Wechsel zwischen Pit und Land, eine "0" bedeutet "kein Wechsel". Je nachdem, wie intelligent der Merging Bit Generator ist (oder wie dumm), tritt dieses Problem mehr einigen (oder vielen) regelmäßigen Mustern auf...oder auch nicht. Das Zeug wird alles fehlerfrei gebrannt. Aber das Lesen hinterher klappt nicht wirklich gut. Je nachdem, wie tolerant das Leselaufwerk ist, kann es sowas dann lesen....oder nicht. Toshiba DVD-ROMs sind da besonders intolerant. Nachdem das alles Sinn gab, hab ich ein einfaches Experiment gemacht: In der ECMA-130 die EFM-Tabelle scharf angeschaut, und gesehen, daß ein 7AB9-Muster wohl knifflicher ist als das, was SafeDisc 2.51 verwendet => Datei mit diesem Muster erzeugt => im LiteON gebrannt => Lesefehler! Dann hab ich ne Brute-Force-Analyse aller regelmäßigen 16-Bit-Muster laufen lassen und gesehen, daß es noch schlimmer geht...also mein LiteOn 52x versagt bei mehr als 100 verschiedenen Mustern. Zum Glück bei keinem, welches für SD 2.51 bedeutsam ist Da sich keiner die Mühe gemacht hat, die wirkliche Wirkungsweise von SD2 mal richtig aufzuschreiben, kann ich leider nicht mit Links dienen. Aber die ECMA-130 gibts hier: ftp://ftp.ecma.ch/ecma-st/Ecma-130.pdfDa findest Du erstmal die Erklärung, was EFM-Encodierung ist, was Merging Bits sind, und so'n Zeug. Zur Frage, ob der Erfolg mit SD2 nur firmwareabhängig ist: Jein. Einige Brenner-chipsets scheinen die Generierung der Merging Bits hardcoded zu haben, so daß die Firmware dort nichts basteln oder verbessern könnte. Aber z.B. bei Plextor scheint es auch per Firmware beeinflußbar zu sein.
Für die mit Sicherung: http://www.brennmeister.com/forum/jump2 ... ost=429107
P.S. Wie schon im Thread angesprochen: Es erscheinen bei uns kaum noch Safedisc Titel auf CD; die paar kann man ja zur Not auch im virtuellen Laufwerk starten (muss man bei SD DVD's ja sowieso)
|
|
|
|
|
Hotz
|
Betreff des Beitrags: Verfasst: Mittwoch 10. Mai 2006, 14:57 |
Gefällt's hier richtig gut |
Registriert: Dienstag 1. November 2005, 16:11 Beiträge: 270
|
BenGurion hat geschrieben: ... und das schon seit einiger zeit Schon klar. Bin in html überhaupt nicht bewandert Dachte, der alte Link könnte interessierte Leute mit Sicherung (den von dir erwähnten rar's) trotzdem zur Quelle führen.
|
|
|
|
|
|
|
|
|
|
|
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.
|
|