Forum: PC Hard- und Software ISO-Image einer CD erstellen: Drei Programme liefern drei unterschiedlich lange Images.


von Guido C. (guidoanalog)


Lesenswert?

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

von EGS (Gast)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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?

von EGS (Gast)


Lesenswert?

@ 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

von Frank K. (fchk)


Lesenswert?

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

von brennmeister (Gast)


Lesenswert?

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.

von Guido C. (guidoanalog)


Lesenswert?

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

von Icke ®. (49636b65)


Lesenswert?

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.

von Guido C. (guidoanalog)


Lesenswert?

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
von Amateur (Gast)


Lesenswert?

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.

von Guido C. (guidoanalog)


Lesenswert?

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

von Amateur (Gast)


Lesenswert?

>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.

von oszi40 (Gast)


Lesenswert?

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

von Guido C. (guidoanalog)


Lesenswert?

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

von ...-. (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.