Wie Byte Order in Brasero cd images vom Typ toc fixen?

[nudgegoonies]

Ich habe einige Spiele CD Images, die ich nicht neu erstellen will, wo einfach nur die Byte Order der Audio Files im korrespondierenden .bin File korrigiert werden muss.
Hintergrund ist, das Brasero Audio Tracks rippt ohne die Byte Order zu fixen und DosBox nur CUE Dateien liest wo im korrespondierenden File die Byte Order richtig ist. Es gibt mehrere Konverter, die aus dem toc file ein cue file erstellen. Aber ich brauche einen Konverter, der auch das bin file anpasst. Anscheinend hat Brasero ohne die Option --driver generic-mmc:0x20000 gerippt: https://www.dosbox.com/wiki/Cuesheet#Linux

[scdbackup]

Hi,

ich glaube eines der aeltesten Unix-Programme kann das tun:

Code: Alles auswählen

dd if=falsches.bin of=neues.bin conv=swab

Ein Versuch mit einem kleinen Textfile statt "falsches.bin" liefert
schoene Verwirbelung.
Aus "abcdefgh" wird "badcfehg" und aus "0123456789" wird "1032547698".
(Mit exotischen UTF-8 characters waere sowas natuerlich fatal.)

Have a nice day

Thomas

[MSfree]

ich glaube eines der aeltesten Unix-Programme kann das tun:

Code: Alles auswählen

dd if=falsches.bin of=neues.bin conv=swab

Audiodaeien haben, wie andere Mediendateien (Bilder, Filme), einen Datgeikopf, in dem Informationen wie die Anzahl der Audiokanäle, Bits pro Sample, Länge der Stücks..., abgelegt sind. Konvertiert man so etwas stumpf mit conv=swab, wird auch der Dateikopf konvertiert, was die Datei anschließend unbrauchbar macht.

Die Konvertierung funkioniert also nur, wenn das rohe Audiosamples ohne Dateikopf und Metainformationen sind. Ansonsten müßte man wohl eher mit Werkzeugen wie sox die Datei konvertieren.

[scdbackup]

Hi,

Audiodaeien haben, wie andere Mediendateien (Bilder, Filme), einen Datgeikopf

Ja, das kann dann ein Problem sein.

Es ist aber so, dass zB. der Kopf von .wav nicht in die Tracks von Audio
CDs geschrieben wird, und deshalb vermutlich auch beim Rippen in einen .bin
File nicht neu hergestellt wird. Ganz generell ist .bin ein plattes Abbild
der Daten auf der CD und .cue oder .toc liefern die Struktur, anhand der
diese Daten in Tracks auf der neuen CD kopiert werden. Deshalb kann es sein,
dass alle 2-Byte Woerter im .bin File innerlich vertauscht sind und deshalb
ein pauschales dd conv=swab die gewuenschte Korrektur bringt.

Ich wuerde es einfach mal probieren.
Wenn's nicht klappt, muesste man entweder feststellen, welche Bereiche des
.bin Files nicht geswabt werden duerfen, oder aber ein spezialisiertes
Programm ranlassen.

Ansonsten müßte man wohl eher mit Werkzeugen wie sox die Datei konvertieren.

Wenn sox das kann, dann waere das sicher ein qualifizierterer Versuch als
mit dd.

Have a nice day

Thomas

[nudgegoonies]

Danke schon mal für die Tips! Das dd das kann wusste ich gar nicht. Natürlich müsste dd nur über die Teile der .bin Datei gehen, in denen die Audio Daten liegen. Die Programmdaten sind ja richtig und mountbar.

[scdbackup]

Hi,

Natürlich müsste dd nur über die Teile der .bin Datei gehen, in denen
die Audio Daten liegen. Die Programmdaten sind ja richtig und mountbar.

Die .toc Files sollten die jeweiligen Bereiche angeben.
Kannst Du mal einen zeigen ?

Mehrere dd-Laeufe koennten dann stueckweise mit Bytevertauschen das
problematische .bin in ein korrigiertes umkopieren. Am einfachsten waere
es wohl, das .bin erstmal ganz zu kopieren und dann die Kopie mit den
bytevertauschten Tracks zu ueberschreiben.

Die dd Optionen zum Adressieren sind "skip=" fuers Lesen und "seek=" fuers
Schreiben. Beide werden mit Anzahlen von Blocks gefuettert, die natuerlich
in Deinem Fall immer genau gleich sein sollten.
Die Anzahl der zu kopierenden Blocks gibt man mit "count=" an.
Die Blockgroesse stellst Du mit "bs=" ein. Der .toc File muesste die auch
angeben, aber bei Audio CD Tracks gibt es eigentlich nur eine: 2352.
(Ja, so eine krumme Zahl.)

Ich wuerde mir alle noetigen dd Kommandos in ein Skript schreiben, damit
ich sie vor dem Lauf prueflesen kann und hinterher ggf. Fehler meinerseits
vor weiteren Versuchen beheben kann.
Fuer die Uebersichtlichkeit empfehle ich eine Shellfunktion, die den
dd-Salat mit Filenamen und allen anderen unveraenderlichen Textstuecken
von den einstellbaren Zahlen trennt. Sowas wie:

Code: Alles auswählen

dd_lauf() {
  # Erstes Argument $1: Startblock , Zweites $2: Anzahl der Blocks
  dd bs=2352 if=falsches.bin of=neues.bin conv=notrunc,swab \
     skip="$1" seek="$1" count="$2"
}

cp falsches.bin neues.bin
dd_lauf 23456 7890
dd_lauf 98765 87654
...

Ich habe das nur grob mit einem Dummyfile und bs=1 getestet.

Have a nice day

Thomas