Hallo, da das interne CD/DVD-Laufwerk in meinem Notebook einer SSD gewichen ist, erstelle ich mir neuerdings ISO-Images der von mir häufig benötigten CDs/DVDs. Die Images erstelle ich auf meinem alten Desktop unter Windows XP. Ich habe auf dem Desktop drei Porgamm mit denen ich ein Image erstellen kann. Hierbei ist mir aufgefallen, dass die von den Programmen erstellen Images unterschiedlich lang sind. Im Folgenden die Daten einer CD deren Image ich heute erstellt habe. Daten auf der CD Eigenschaften von Windows: 66.154.496 Bytes Größe der ISO-Images: WinImage V 8.0.8000: 66.154.496 Bytes PlexTools XL V3.16: 66.465.792 Bytes H2cdimage1.8: 66.461.696 Bytes Wie ich herausbekommen habe sind die ersten 66.153.044 Bytes aller Images gleich. Danach kommt je nach Image eine unterschiedlich Anzahl an "00"-Bytes. Meine Fragen auch Euch: 1. Wie kann es sein, dass laut den Eigenschaften von Windows die CD 66.154.496 Bytes lang ist, die ISO-Images jedoch nur 66.153.044 Bytes "richtige" Daten enthalten? 2. Hat es einen tieferen Sinn, dass die drei Programme eine unterschiedliche Anzahl an "00"-Bytes anhängen? Mit freundlichen Grüßen Guido
Hallo Guido, könnte eventuell daran liegen, dass die Programme unterschiedlich komprimieren, Zusätzliche Informationen des Images speichern (benutztes Programm, Version, etc.) und weitere Funktionen für das kopieren von CDs/DVDs unterstützen? Einige haben auch andere Leseverfahren, die der Brenner unterstützen muss (RAW, Sektorweise, CRC-Prüfsummen) und schreiben dann anders (Disk-at-once, Session-at-once). Nero hatte damals auch Verfallsdaten in die Images einbetten können. Da wurde dann das Image unbracuhbar oder auch Verschlüsselung (welche manche Brennprogramme haben. MfG, EGS
EGS schrieb: > könnte eventuell daran liegen, dass die Programme unterschiedlich > komprimieren, Zusätzliche Informationen des Images speichern (benutztes > Programm, Version, etc.) und weitere Funktionen für das kopieren von > CDs/DVDs unterstützen? und das speichern sie also in den Anzahl der 0 Bytes am ende? Hast du den Text überhaupt gelesen?
@ Peter, Klar, du aber meinen eventuell nicht, wenn die Funktionen nicht genutzt werden, sind die Speicherbereiche in den Images sicherlich auch vorhanden. Und nicht alle schreiben dann 0xFF rein... MfG, EGS
2 und 3 unterschieden sich um 4k. Ich tippe mal darauf, dass 2 mit einer Puffergröße von 4k gelesen hat, 3 mit einer Puffergröße von 8k. Der Unterschied zwischen 1 einerseits und 2 und 3 andererseits könnte darauf zurückzuführen sein, dass 1 das Lead-Out nicht mit abgespeichert hat, sondern sich zuerst vom Laufwerk die Anzahl der Sektoren hat geben lassen und nur diese gelesen hat. 2 und 3 haben das nicht getan und einfach so lange Blöcke gelesen, bis ein Fehlercode aufgetreten ist. Ich kenne die Programme nicht persönlich, das sind alles nur Vermutungen. fchk
Guido C. schrieb: > 2. Hat es einen tieferen Sinn, dass die drei Programme eine > unterschiedliche Anzahl an "00"-Bytes anhängen? Nein, das Leadout oder wie sich das nennt der muss eine Mindestgrösse haben, im Prinzip kann man denn aber >= Mindestgrösse machen, manche Programme füllen da einfach auf Rohlingrösse auf oder was sie dafür halten. Manche Tools die Reparaturdaten generieren schreiben dort nach der Mindestgrösse ihre Metadaten rein. Deshalb macht auch ein Hash zur Überprüfung über ein ISO auch keinen Sinn, das man weggebrannt hat und später wieder aus dem Rohling generiert, das wird fast nie identisch sein. Da gehts dann schon am Anfang los, wo manche tools Daten weglassen, wenn ich mich recht erinnere dürfen dort auch Metadaten stehen, da kann dann das Brennprogramm seine Duftmarkierung reinschreiben, was dann schon mal keine identische ISO generiert wenn man die später wieder vom rohling genieriert und vergleicht. Deshalb hasht man immer die eigentlichen Dateien.
Hallo, vielen Dank für Eure Unterstützung. Frank K. schrieb: > 2 und 3 unterschieden sich um 4k. Ich tippe mal darauf, dass 2 mit einer > Puffergröße von 4k gelesen hat, 3 mit einer Puffergröße von 8k. > > Der Unterschied zwischen 1 einerseits und 2 und 3 andererseits könnte > darauf zurückzuführen sein, dass 1 das Lead-Out nicht mit abgespeichert > hat, sondern sich zuerst vom Laufwerk die Anzahl der Sektoren hat geben > lassen und nur diese gelesen hat. 2 und 3 haben das nicht getan und > einfach so lange Blöcke gelesen, bis ein Fehlercode aufgetreten ist. diese Vermutungen sind gar nicht so schlecht. Ich muss zugeben, dass ich die Images mit unterschiedlichen Laufwerken erstellt habe. Image 2 mit einem Laufwerk von Plextor und Image 3 mit einem Laufwerk von BenQ. Mit welchem Laufwerk ich das Image 1 erstellt habe weiß ich leider nicht mehr. Um der Sache auf den Grund zu gehen habe ich eine weitere CD untersucht. Ich habe in beiden Laufwerken mit allen drei Programmen Images von der CD erstellt. Interessanterweise waren alle 6 Images gleich. Vielleicht spielt es eine Rolle, ob die CD eine oder mehrer Sessions beinhaltet. Bei einer Multisession CD, die nicht vollständig abgeschlossen wurde könnte sich das in meinem Eingangsbeitrag beschrieben Verhalten ergeben. Ich werde die CD aus meinem Eingangsbeitrag wohl noch einmal untersuchte müssen. Mit freundlichen Grüßen Guido
Guido C. schrieb: > Ich muss zugeben, dass ich > die Images mit unterschiedlichen Laufwerken erstellt habe. Typisch. Den Angaben eines hilfesuchenden Users kann man NIEMALS vertrauen. Er wird IMMER wesentliche Details verschweigen oder nach seinem Gutdünken abändern sowie das Fehlerbild mit eigenen Mutmaßungen verwässern. So die Erfahrungen aus der täglichen Praxis, die sich auch hier immer wieder bestätigen.
Hallo Icke, trag nicht so dick auf! Immerhin sind zwei unterschiedliche große Images mit dem gleichen Laufwerk erstellt worden. Icke ®. schrieb: > Er wird IMMER wesentliche Details verschweigen Es soll doch gelegentlich vorkommen, dass am Anfang nicht klar ist, welche Details wesentlich sind. Icke ®. schrieb: > oder nach > seinem Gutdünken abändern sowie das Fehlerbild mit eigenen Mutmaßungen > verwässern. Dies habe ich nicht gemacht. Mit freundlichen Grüßen Guido
:
Bearbeitet durch User
1. Sind die Images untereinander Kompatibel - vielleicht werden unterschiedliche Verwaltungsinformationen angehängt bzw. vorangestellt. Also Programm2 liest Image1 und umgekehrt usw. 2. comp /b Dat-Ei_1 Dat-Ei_2 oder (win)merge dauern beide zwei bisschen.
Hallo, wie bereits erwähnt unterschieden sich die Images lediglich in der Anzahl angehängten Null-Bytes. Guido C. schrieb: > Wie ich herausbekommen habe sind die ersten 66.153.044 Bytes aller > Images gleich. Danach kommt je nach Image eine unterschiedlich Anzahl an > "00"-Bytes. Mit freundlichen Grüßen Guido
>wie bereits erwähnt unterschieden sich die Images lediglich in der >Anzahl angehängten Null-Bytes. Dann schau Dir mal die Formatierung der Datenträger an. Wenn man ein Programm schreibt, dass größere Mengen an Daten schaufelt, kann man viel Zeit sparen, wenn man nicht bei jedem Byte nach dem Feierabend fragt. Auf der unteren Ebene, enthalten Datenträger Blöcke und keine Bytes. Ich könnte wetten, dass ich eine andere Blockgröße verwende, als Du! Früher konnte man an schnellsten die Daten lesen, indem man einen ganzen Sektor gelesen hat - auch wenn es möglich war (versteckt) ein Byte zu bekommen. Später wurde gerne eine ganze Spur gelesen. Heute steht man sich wohl an Besten, wenn man den eingebauten Plattenpuffer mit einbezieht, oder einen Wert im MByte-Bereich fixiert.
1.Wenn Du z.B. Packer wie 7zip od. Rar benutzt, kannst Du auch Modi zwischen schnell und gründlich wählen und hast dann kleine Differenzen in der Dateigröße. Da die Sektorgröße feststeht, Dateien aber unterschiedlich lang sein werden, bleibt wahrscheinlich bei Dir ein Rest übrig, der mit Nullen aufgefüllt wird? 2.Nicht jedes Image ist wirklich gesund wenn man es braucht. Zu Testzwecken habe ich vor einiger Zeit viele PCs mit Images von CD oder Netz betankt. Von jeweils 13 PCs war immer mal eine Niete dabei, die beim nächsten Versuch mit dem GLEICHEN Medium und gleichem PC wieder klaglos funktionierte. Ursache ist mir unbekannt. Einige Hinweise sind jedoch in der Wiki zu finden, die in Zusammenhang mit der Abfrage der Pfadtabelle stehen könnTen bei Verwendung von Windows. http://de.wikipedia.org/wiki/ISO_9660
Hallo, ich habe die in meinem Eingangsbeitrag verwendete CD nochmals mit "H2cdimage 1.8" und "WinImage V 8.0.8000" eingelesen. Dies habe ich sowohl mit meinem Plextor als auch mit meinem BenQ Laufwerk gemacht. Hierbei hat sich gezeigt, dass die Größe der erstellen ISO-Dateien nur von dem verwendeten Programm und nicht von dem verwendeten Laufwerk abhängig sind. Was ich jedoch festgestellt habe ist, dass es sich bei der CD um eine wiederbeschreibbare CD handelt. Die CD beinhaltet einen Track. Sie wurde nicht abgeschlossen, d.h. ich könnte noch weiter Daten hinzubrennen. Ich vermute, dass hier "der Hund begraben liegt". Mit freundlichen Grüßen Guido
hast Du mal dvdisaster probiert ?, das macht auch sehr gut und schnell Images (auch wenn die CD/DVD Lesefehler produziert)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.