cgboard - classic games

Ich habe mir kürzlich ein geeignetes Plextor-Laufwerk zugelegt und bin dadurch nun endlich in der Lage eigene "Redumps" zu machen (also mit dem offiziellen Tool ). Da wir hier kürzlich haben, beabsichtige ich nun die Sicherung meiner kompletten Sammlung. Und selbstverständlich möchte ich diese Daten dann auch im cgboard zur Verfügung stellen .

Den meisten Nutzer ist nun sicherlich bekannt, dass Mixed-Mode-CDs (also Images mit CD-Audio) bei redump in einem etwas unhandlichen Rohdaten-Format gelistet werden (gesplittete BIN-Dateien). Selbstverständlich lässt sich dieses Format mit diversen Brennprogrammen umwandlen. Allerdings spuckt das redump-Tool bereits bei der Erstellung ein übliches Einzel-BIN-Image aus (dessen Prüfsumme entspricht der CRC-32-Angabe unter "Total"). Da ich keine "Doppelmoppelei" betreiben möchte, interessiert mich nun, welches Format ihr für den Upload bevorzugen würdet. Beides hat Vor- und Nachteile .

Hi,

vielleicht könntest du etwas mehr über die Vor- und Nachteile erzählen.
Was dieses Dumping Tool angeht bin ich da eher jungfräulich eingestimmt. MaW, ich habe keine Ahnung.

Ich habe jetzt mal mehrere Bins angekreuzt, aber ist mir im Grunde egal.

Gibt es denn eine entsprechende CUE Datei, in der die Audio Tracks aufgeführt sind?

Ja, es gibt eine CUE-Datei - sogar zwei: Eine für die Multi-BIN-Dateien (findet man auch auf der redump-Webseite zum Download) und eine für das einzelne BIN-Image (analog der üblichen CUE-Sheets).

Der Vorteil der Multi-BIN-Dateien betrifft hauptsächlich die Datenprüfung. Bei redump sind ja die meisten Prüfsummen für diese Variante angegeben und dementsprechend lässt sich das leichter nachvollziehen. Ich könnte mir außerdem vorstellen, dass man einzelne Dateien bei Bedarf austauscht (z.B. wenn nur ein Audiotrack beim eigenen Dump fehlerhaft ist). Allerdings funktioniert das natürlich nur, wenn alle Dumps in diesem Format vorliegen . Keine Ahnung, ob das in der Praxis tatsächlich relevant ist - wird wohl eher eine Ausnahme sein .
Der Nachteil der Multi-BIN-Dateien ist jedoch die eigentliche Nutzung, da fast kein Programm (z.B. Imageloader oder DOSBox) mit diesem Format von Haus aus umgehen kann. Man muss die Dateien also vorher erst in ein Standard-Format umwandeln (normalerweise eine einzelne Image-Datei). Und dementsprechend hat man letztendlich alles doppelt vorliegen.

Bei der Einzel-BIN-Datei ist es im Prinzip genau andersherum: Ich kann sie sofort nutzen und sie ist letztendlich auch das, was ich im Alltag verwenden werde. Dafür ist die Datenprüfung mit den redump-Angaben natürlich so nicht möglich (außer der CRC32-Summe bei "Total"). Man muss sich also mit dem Wissen zufrieden geben, dass es eine redump-konforme Kopie ist und sich dies ggf. vermerken.


Das Dumping-Tool ist übrigens eine coole Sache, weil es praktisch alles von alleine macht und damit ziemlich idiotensicher ist. Man braucht eben nur eines der Laufwerke, die mit den entsprechenden Befehlen umgehen können. Natürlich könnte man auch einfach CloneCD nehmen, aber für den Vergleich will man ja gerade die Datenstruktur entsprechend der bisherigen Dumps haben .

Hi,

dann habe ich mein Kreuz ja richtig gesetzt. Vor mehreren Bins habe ich keine Bange.

Das image soll ja eine exakte kopie des Originals abbilden und meine meinung wäre eine einzelne datei sinnvoller.

Damsls habe ich CDs auch gerippt und habe mich am tosec Standard gehalten. Finfach hach tosec ripping guide gehalten.

Das Einzel-Image ist auch mein Favorit und ich werde sicherlich nur dieses behalten. Es reicht mir zu wissen, dass es sich um einen konformen Dump handelt ... und im Zweifelsfall mache ich einfach einen neuen (solange die CDs noch funktionieren ). Für den Integritätsnachweis speichere ich mir mittlerweile sowieso immer noch die Prüfsummen separat ab. Dafür reicht eine Einzel-Datei und damit geht es sogar bequemer.

Natürlich könnte man auch einfach alles aufheben, aber das ist schon aus Speicherplatzgründen nicht sinnvoll. Allein mein Dump von der 'Siedler2 Gold'-CD belegt schlappe 2,23GB (). Und das eben nur, weil die Daten doppelt und dreifach vorliegen. Solche Daten-Müllhalden Extrem-Sicherungen überlasse ich dann doch lieber den Vollprofis und Super-Perfektionisten .
Hier mal ein Screenshot von dem Datenschwall :

Entweder eine einzelne Bin/Cue Datei, oder ISO+WAV mit Exact Audio Copy. Von diesen Multi Bins halte ich überhaupt nichts.

Oh, das Bild sagt natürlich mehr als tausend Worte. Könnte ich mein Kreuz noch umsetzen, würde ich es jetzt tun.
Am liebsten ist mir nämlich die Variante CCD+IMG+SUB(+CUE), die dort ja auch in deinem Ordner liegt. Also natürlich hauptsächlich für Playstation-Images, die die Subchanneldaten für den Kopierschutz nutzen. Aber ich glaube einige Securom-Varianten haben die Subchanneldaten auch verwendet.

Dann kann man nämlich grundsätzlich immer wählen, ob man IMG+CUE für DOSBox verwendet oder die CCD-Datei für ein virtuelles Laufwerk nutzt (oder einen Emulator, der das Format liest).

Weißt du eigentlich oder kannst du prüfen, ob der Offset-Unterschied zwischen Redump-konformen Audio-Tracks und in einem Standardlaufwerk erstellten Audio-Tracks auch einen hörbaren Unterschied beim Start der Musik macht? Also meinetwegen im Millisekundenbereich oder wie genau man da reinschauen kann?

Das man privat eine sicherheitskopie erstellen muss was cd/DVD spiele angeht halte ich für unmöglich. Wenn ich alle meone spiele sichern würde von 1993 bis zu den spielen die ich online regestrieren muss wäre das unmöglich weil ich soviel speicher gar nicht habe.

Grundsätzlich würde ich ein image bevorzugen weil man diese dann auch virtuell laden kann.

Allerdingscwürde ich die kraft auf disketten werfen denn diese geben langsam den geist auf und sind verloren.

Ich würde auch die Einzel-Image-Variante bevorzugen.

Gibt es ne Möglichkeit anhand der cgboard-Gemeinde abzustimmen, welche Dumps Du zuerst machst?

tomwatayan schrieb:Oh, das Bild sagt natürlich mehr als tausend Worte. Könnte ich mein Kreuz noch umsetzen, würde ich es jetzt tun.
Am liebsten ist mir nämlich die Variante CCD+IMG+SUB(+CUE), die dort ja auch in deinem Ordner liegt. Also natürlich hauptsächlich für Playstation-Images, die die Subchanneldaten für den Kopierschutz nutzen. Aber ich glaube einige Securom-Varianten haben die Subchanneldaten auch verwendet.
[...]

Das kann ich ja gedanklich so festhalten. Momentan sieht es ohnehin nach einer Mehrheit für die "normale" Einzel-BIN aus .

tomwatayan schrieb:[...]
Weißt du eigentlich oder kannst du prüfen, ob der Offset-Unterschied zwischen Redump-konformen Audio-Tracks und in einem Standardlaufwerk erstellten Audio-Tracks auch einen hörbaren Unterschied beim Start der Musik macht? Also meinetwegen im Millisekundenbereich oder wie genau man da reinschauen kann?

Ein hörbarer Unterschied sollte nur in ganz bestimmten Fällen auftreten. Zum Beispiel kann es zu Knacksern kommen, wenn Daten- und Audio-Spur direkt aufeinanderfolgen. Oder ein Titel fängt minimal zu spät/früh an, wenn es keine ausreichende Pause gibt (z.B. bei beabsichtigtem Loop). Bei den meisten Mixed-Mode-CDs wird man das jedoch nicht merken (dafür gibt es schließlich extra PreGaps bzw. einen leisen FadeIn/FadeOut je Titel).
Prüfen kann man das relativ leicht, indem man eine solche CD auf verschiedenen Laufwerken einliest und dann die Audio-Daten durch eine Wellenanalyse jagt (das kann z.B. der Nero Waveeditor). Im Idealfall hat man bei einem Laufwerk bereits den exakten Offset bestimmt und umgeht somit das Problem komplett (auf der Webseite von AccurateRip gibt es dafür eine Vergleichsdatenbank und EAC hat auch eine Testroutine).
Ich habe momentan noch nicht richtig durchschaut, auf welche Weise das redump-Tool arbeitet. Aber offensichtlich nutzt es eine Funktion, die nur von bestimmten Laufwerken unterstützt wird. Der Grundgedanke wird jedoch sicherlich ähnlich zu EAC sein.

Independent schrieb:[...]
Allerdings würde ich die kraft auf disketten werfen denn diese geben langsam den geist auf und sind verloren.

Mit Disketten kann ich leider nicht dienen - dafür bin ich einfach zu spät in den PC-Markt eingestiegen (meine einzige Original-Floppy ist ein Werbe-Spiel von der Bundeswehr ). Ich finde es jedoch gar nicht so schlecht, wenn sich die Arbeit dadurch verteilt. So kann man den Fokus gleichzeitig auf verschiedene Datenträger legen und mehr schaffen . BDs würde ich aber auch noch nicht anfassen wollen .

Commodus schrieb:[...]
Gibt es ne Möglichkeit anhand der cgboard-Gemeinde abzustimmen, welche Dumps Du zuerst machst?

Du kannst gerne deine Wünsche äußern, aber meine persönliche Priorität liegt eigentlich vorerst auf den ältesten CDs (= DOS-Spielen) mit CD-Audio-Anteil. Und die "Wunschliste" ist sowieso schon begrenzt, da meine Sammlung bei weitem nicht so umfangreich ist, wie die von anderen cgb-Mitglieder . Außerdem wird die Sache mit den Uploads nur nach und nach vor sich gehen, weil meine Datenleitung nicht so dick ist (16000er eben ).
Ich hatte mir jedoch auch schon überlegt, dass ich ein paar "Auftragsarbeiten" durchführen könnte, wenn mir jemand seine Original-Disks schickt. Diese Idee muss allerdings wohl noch ein wenig reifen .

Multi-CDs die noch neben den Daten-Track weitere Daten-Tracks oder Audio-Tracks beinhalten handle ich immer wie folgt:

DOS:
BIN+CUE / ISO+CUE

Playstation:
BIN+SUB+CUE / ISO+SUB+CUE

Subchannels sind bei PSX immer Vorteilhaft. Viele Emulatoren beziehen sich drauf diese mit zu nutzen.

Bei Multi-Track Content die einzeln vorliegen und über die CUE zusam gepappt werden im nachhinein mache ich es wie folgt:
Daten-Tracks als BIN / ISO
Audio-Tracks als FLAC / APE / WAV

WAV-PCM Formate würde ich dann wenn man sie einzeln mit gibt, immer in APE oder FLAC konvertieren. Vorteil ist das die Audio-Tracks somit Verlustfrei bleiben und man sie später wieder in PCM 16bit 44100 Little Endian umwandeln kann. Also typisches CD Audio Format.

Ich würde aber vor der letzten Variante abraten, da man hier mehr falsch machen kann und mehr Aufwand hinter steckt für den User, als wenn alle Tracks in eine BIN / ISO stecken und diese mit der CCD oder CUE problemlos identifiziert werden können.


DOSBox kann Multi-Track BIN Datei über die CUE-Sheet problemlos einlesen. Hatte damit nie Probleme gehabt. Bei Descent 1 und 2 hats so geklappt und auch bei Tomb Raider 1. Also das wäre kein Problem.

Die hauptsache ist man hat die ganzen Einsprungspunkte für jeden Track innerhalb der BIN / ISO.

PSX Emulatoren kommen auch Problemlos mit BIN / ISO klar, solange eine entsprechende CUE Sheet Datei vorhanden ist bzw. eine CCD Datei.


Solange alles richtig gemacht wurde bei der Erstellung, kann man jederzeit wieder Daten und Audio Tracks voneinander trennen. Das sollte dann aber dem Enduser vorbehalten werden finde ich.


Ich hatte schon viele Multi-Tracks Image aus dem Netz bezogen. Entweder fehlten die Audio Tracks ganz und man musste die sich irgendwo herbeschaffen und mühevoll wieder einbinden ODER die Idioten haben Daten und Audio Tracks so genial aufgeteilt, das die CUE Sheet bzw. CCD voll fürn Arsch war. Im Spiel waren die Tracks entweder falsch abgespielt oder es lief gar keine Musik.
Also lieber Finger weg davon, bevor Adressen verfälscht werden.


Bei mein Tomb Raider 1 Image für die DOSBox sieht die BIN so aus:

In der DOSBox läuft das Spiel mit samt Sound + Musik problemlos. Alle Offsets sind absolut korrekt. Die DOSBox schluckt die Multi-Track BIN über die CUE mit samt den Tracks problemlos.

Vorteil: Offsets können sich nicht verschieben und somit die Audiotracks nicht verfälschen in Form von Datenlänge oder Konvertierungsfehler.

Vorteil 2: Es sind nur 2 Datein, anstatt 11. Eine BIN + CUE, anstatt eine BIN, eine CUE und 9 WAVE Files.

Je mehr Datein, desto größer der Fehlerfaktor beim zusam setzen für den User später

Vorteil 3: Es ist aufgeräumter, wenn alles zusam ist, statt wenn man viel zu viele Files hat.

Jo, die Vorteile einer einzelnen Datei sind nicht von der Hand zu weisen. Und momentan sieht es bei der Mehrheit wohl auch so aus, als wäre das die favorisierte Variante. Aber ich warte mal noch ein Weilchen ab, bevor ich die Entscheidung fix mache (der Thread ist ja noch nicht lange auf ).

Und nur für den Fall, dass es hier ein Missverständis gab: Die obig erwähnte Sache mit dem Offset bezog sich auf das Einlesen vom Laufwerk und nicht auf die Angaben im Cue-Sheet.

SagaraS schrieb:[...]
DOSBox kann Multi-Track BIN Datei über die CUE-Sheet problemlos einlesen. Hatte damit nie Probleme gehabt. Bei Descent 1 und 2 hats so geklappt und auch bei Tomb Raider 1. Also das wäre kein Problem.
[...]

Ja, DOSBox kommt damit erfreulicherweise klar . Zumindest bei CD-Audio. Es gab aber auch mal einen Fall mit mehrfacher Datenspur und ich glaube, das hat DOSBox dann nicht so geschluckt. Ich weiß nur nicht mehr, bei welchem Spiel das war .


Edit:
So, ich denke, das war genug Zeit zum Abstimmen. Das Ergebnis ist relativ eindeutig und damit steht wohl fest, dass ich die Einzel-Images hochlade . Sollte mal eine Disc mit Kopierschutz dabei sein, packe ich natürlich noch die SUB dazu. Aber für den Normalfall reichen IMG & CUE. Sobald ich ein paar Images beisammen habe, beginne ich mit dem Upload (werde wohl alles bei ray auf dem FTP ablegen ).

Ich hatte jetzt übrigens auch tatsächlich einen Fall, bei dem der Offset entscheidend war: LBA2. Bei meinem normalen LG ist eine kleine Verschiebung drin und dadurch liest es die CD nicht korrekt (kleiner Knackser am Anfang vom Audio-Track). Das Plextor macht eine saubere Kopie. Allerdings musste ich mir jetzt tatsächlich noch ein zweites Laufwerk besorgen, weil das andere die CD gar nicht erst erkannt hat. Zum Glück konnte ich gleich ein Schnäppchen machen. Naja, nun bin ich jedenfalls für alle Fälle gerüstet (ein LW für DVDs und eines für CDs ).