22.10.2018, 17:56
0
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.
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:
Code:
FILE "Tomb Raider (DEU) [PC].bin" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 01 19:23:71
TRACK 03 AUDIO
INDEX 01 22:40:41
TRACK 04 AUDIO
INDEX 01 24:40:54
TRACK 05 AUDIO
INDEX 01 27:43:63
TRACK 06 AUDIO
INDEX 01 30:52:46
TRACK 07 AUDIO
INDEX 01 34:00:18
TRACK 08 AUDIO
INDEX 01 35:03:58
TRACK 09 AUDIO
INDEX 01 36:01:33
TRACK 10 AUDIO
INDEX 01 36:16:63
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.