Image brennen oder nicht?

[Feltzkrone]

0

Es gibt Spiele mit CD-Checks, die die genaue Länge der Audio-Tracks überprüfen. Diese CD-Checks schlagen bei ISO/MP3/CUE fehl!

MP3s können aufgrund ihrer internen Struktur die Länge der Audiodaten nicht sektorgenau speichern und führen damit nicht nur zu Qualitätsverlust beim Sound sondern salopp gesagt auch bei der Längenangabe der Audiodaten.

Mein Fazit: ISO/MP3/CUE ist deswegen immer eine heikle Sache und ich vertrete außerdem den Standpunkt, dass 1. heutige Datenträger groß genug sind um die Daten auch unkomprimiert oder verlustfrei komprimiert (FLAC, OptimFROG etc.) zu speichern und 2. Archivierung, egal welcher Art und falls technisch möglich, verlustfrei stattfinden sollte. Ich persönlich verwende ISO/OFR/CUE. Also lieber Finger weg von MP3-Audiotracks!

[Atreyu]

0

Original von Feltzkrone
Es gibt Spiele mit CD-Checks, die die genaue Länge der Audio-Tracks überprüfen. Diese CD-Checks schlagen bei ISO/MP3/CUE fehl!

MP3s können aufgrund ihrer internen Struktur die Länge der Audiodaten nicht sektorgenau speichern und führen damit nicht nur zu Qualitätsverlust beim Sound sondern salopp gesagt auch bei der Längenangabe der Audiodaten.

Soweit ich weiss, ist die unexakte Längenangabe nur bei VBR mp3s gegeben. Eine CBR sollte da genau sein.

Des weiteren finde ich Audio und Videokomprimierung nur bei ScummVM Gmaes sinnvoll.

[Feltzkrone]

0

Falsch! Das Problem trifft gleichermaßen auf CBR und VBR zu, da die Anzahl der Samples eines MP3-Frames immer gleich ist (1152 Samples).

Ein CD-Sektor hingegen enthält 588 Samples, womit man eine genaue Längenangabe beim MP3 nur dann hinbekommt, wenn die Gesamtlänge durch das kleinste gemeinsame Vielfache dieser beiden Werte ( =56448 ) teilbar ist.

56448 Samples = 588 * 96. Die Chance, dass die exakte Länge eines Audiotracks mit einem MP3 getroffen wird, beträgt daher 1:95. In den 95 anderen Fällen kommt es darauf an, was die Dekodier-, Mount- oder Brenn-Software daraus macht - manche hängen einfach was dran, andere schneiden evtl. sogar vom Ende ein kleines Stück. Viel Glück!

Wobei man (zumindest in der Theorie) beste Chancen haben müsste, wenn man seine MP3s mit LAME kodiert und wieder dekodiert (dank des LAME-Tags, der genaue Angaben über die ursprüngliche Länge des Songs speichert sowie den encoderbasierten Zeitversatz, Stichwort "lippensynchron"). Dies könnte ich gerne mal für euch austesten!

[Atreyu]

0

Das heisst, ein CDrip ist immer kürzer oder Länger als das Audio? Und was genau ist ein Sample, also jetzt in der Hinsicht?

[Retro-Nerd]

0

Original von Atreyu
Das heisst, ein CDrip ist immer kürzer oder Länger als das Audio? Und was genau ist ein Sample, also jetzt in der Hinsicht?

Das gilt natürlich nur für komprimierte Tracks, ein ISO/WAV/CUE Rip liefert immer die originale Länge, zumindestens mit TurboRip, dank korrekter PREGAP/POSTGAP Werte.

Ein ordentlich gemachter LAME Rip sollte aber (fast immer) "lippensynchron" sein. Selbst wenn es in der Theorie stimmen sollte, das du in 94/95 Fällen per MP3 nicht die richtige Tracklänge bekommst.

Für PC-Engine/Turbo Duo CD Spiele z.B. gibt es den TOC Fixer & Datenbank, der MP3 WAV Konvertierungen überprüft und gegebenfalls die Länge der WAV Dateien korrigiert.

Alles in allem: Bleib lieber bei 1:1 Kopien, da kannst du nichts falsch machen.

[Feltzkrone]

0

Sample = Abtastwert = Punkt auf der Wellenform des Sounds.


EDIT:

Mal ein Beispiel - ein Audiotrack ist 3 Minuten, 12 Sekunden und 36/75stel Sekunden lang (3:12.480). Das sind 3*60*75 + 12*75 + 36 = 14.436 CD-Sektoren = 8.488.368 Samples.

Macht man ein MP3 draus, werden die Samples in Frames a 1152 Samples aufgeteil. Anzahl Frames wäre exakt 7.368,375 Frames. Da es aber nur ganze Frames gibt, wird hier auf 7369 Frames aufgerundet.

Dekodiert man das MP3 der obigen Länge kommen dabei 7369 * 1152 = 8.489.088 Samples raus. Um die Anzahl der CD-Sektoren herauszubekommen wird dieser Wert durch 588 geteilt = 14.437,224. Auch hier wird wieder aufgerundet, damit am Ende des Sounds nichts verloren geht, weshalb wir auf 14.438 Sektoren kommen, also genau 2 Sektoren mehr als beim Original.

CD-Checks können also nach ISO/MP3/CUE und anschließendem Brennen durchaus feststellen, dass Audiotrack x nicht die erwartete Länge von 3:12.480 hat und können darauf beruhend eine Kopie der CD vermuten.

[Atreyu]

0

Ist der durchschnittliche Abtastwert nicht bei 44 oder 48 khz?

[Feltzkrone]

0

Nee, das was Du meinst ist die Abtastfrequenz. Und Deine beiden Angaben bedeuten, dass entweder 44.100 mal pro Sekunde oder 48.000 mal pro Sekunde ein Wert "abgetastet" wird oder wurde. 1 Hz = 1 mal pro Sekunde. 1 kHz = 1.000 mal pro Sekunde.

Auf Audio-CDs kommt eine Abtastfrequenz von 44.100 Hz zum Einsatz. Ein Abtastwert besteht dabei aus zwei Bytes (Wertebereich von -32.768 bis 32.767). Und da es sich um Stereo handelt, das ganze dann auch noch doppelt, womit man auf 4 Bytes pro Abtastung kommt. 44.100 Abtastungen/s * 4 Byte/Abtastung = 176.400 Bytes pro Sekunde. Die Nutzdaten eines Audio-CD-Sektors beträgt 2.352 Bytes (die Zahl sollte einem von CUE-Sheets her bekannt vorkommen ).

Diese durch vier geteilt ergeben die vorher genannten 588 Abtastungen pro Sektor. Und diese mal 75 (Sektoren pro Sekunde) ergeben genau die 44.100 Abtastungen, die pro Sekunde gespeichert werden.

[Atreyu]

0

Hmm, das ist sehr interessant, wenn auch etwas kompliziert. Ich werds noch ein paar Mal durchlesen müssen, bevor ich es kapiere.

Also im groben, der Wert mit mit einer bestimmten Frequenz ermitteln und in Byte-länge gelesen.

Hmm, im Prinzip gut erklärt. Das heisst, ein normaler CD-Audioplayer kann ca 170 kb/sek verarbeiten...

Aber gerippt als mp3 gibts es ja noch das Joint-Stereo. Wurde da nicht bei einer Mono-Spur nur der Unterschied zur anderen berechnet, aus Platzgründen.

[Feltzkrone]

0

Der Wert erklärt gleichzeitig auch die Geschwindigkeit eines Single-Speed-CD-ROM-Laufwerks. Da ein Datentrack statt 2352 Bytes nur 2048 Bytes Nutzdaten pro Sektor enthält (der Rest geht für eine zusätzliche Fehlerkorrektur drauf), ergibt der Wert von 176.400*2.048/2.352 exakt 153.600, was wiederum (geteilt durch 1024) exakt 150 kB entspricht, und diese eben pro Sekunde.

Eine CD hat vom optischen Standpunkt her sogar eine viel größere Kapzität als man denkt (geht aber alles für "Metadaten" und weitere Fehlerkorrektur/-erkennung drauf). Ein CD-Sektor enthält in Wirklichkeit genau 3.234 Bytes. Da soll nochmal jemand sagen, dass CloneCD Images ein 1:1-Abbild wären. Ein 1:1-Abbild einer 700 MB - CD-ROM würde demnach nämlich etwa 1,08 GB verschlingen.
Hier nachzulesen (meiner Meinung nach sehr schön erklärt): http://schladweiler.de/cdtech/index.html

Aber bitte um letzteres nicht zu viele Gedanken machen, da auch Synchronisationsbit und anderes Zeug dort untergebracht sind, deren "Zerstörung" selbst zwecks Kopierschutz keinen Sinn mehr ergeben würde und daher die Speicherung (im Image) nicht lohnen würde.


Zum Thema Joint-Stereo habe ich einen Wikipedia-Artikel gefunden, der diesen Sachverhalt sehr schön beschreibt: http://de.wikipedia.org/wiki/Joint-Stereo

[acp]

0

Also ich hab schon bei VBR/CBR (??) ausgesetzt....
Die Diskussion geht langsam über meinen Verstand hinaus (peinlich, da hab ich wohl was ins Rollen gebracht).

Ich lass die Images glaub ich erstmal so wie sie sind, Retro hat mich überzeugt!

[Atreyu]

0

Original von acp1512
Also ich hab schon bei VBR/CBR (??) ausgesetzt....
Die Diskussion geht langsam über meinen Verstand hinaus (peinlich, da hab ich wohl was ins Rollen gebracht).

Ich lass die Images glaub ich erstmal so wie sie sind, Retro hat mich überzeugt!

Laaangsam lesen, dann gehts. Ist sehr interessant, wenn man mal einen Spezialisten fragen kann, und nicht so einen kryptischen Wiki-Eintrag studieren muss.

Also, sind in Wirklichkeit mehr Daten auf einer CD drauf als man denkt. Nur der Rest sind Zusatzinfos wie Fehlerkorrektur, vielleicht Kopierschutz und ähnliches.
Ist das der Red Book Standard oder gilt das nur für das Format von AUdio-CDs?

edit: Und achja, dann wären ein 700 MB Image von einer CD nur die Nutzerrelevanten Daten.

nochmal edit: Auf der JS-Wiki-seite steht, dass auch LAME einen verlustfreien Mid/Side Stereo Algo verwendet. Dennoch wird er als Verlustbehaftet bezeichnet. Stecken die Verluste nun in anderen Faktoren?

edit, no 3: Wird bei der Berechnung eines Monokanals einfach nur links und rechts addiert?

[Feltzkrone]

0

@acp1512: Inzwischen wird ja eher weniger diskutiert und stattdessen eine kleine Lehrstunde gegeben, oder? Wer's wissen will kann's lesen und wer's nicht will kann's bleiben lassen. :-P


MP3s, Verlust und Verlustfreiheit

Naja, die Bildung des Mittel- und Seitenkanals sowie die Wiederherstellung von Links und Rechts anhand jener beiden Kanäle sind verlustfrei, was bei Verwendung von Intensity Stereo ja nicht der Fall ist. Ich nehme mal an, dass im Artikel das Wort "verlustfrei" nur deshalb gefallen ist, um Mid-/Side-Stereo von Intensity Stereo abzugrenzen. MP3s selbst sind nie verlustfrei, auch bei höchster Bitrate, daher sind es die Encoder wie z.B. LAME auch nicht.


MP3s und die Daten, die darin enthalten sind

Der Grund ist, dass das MP3-Format nicht Punkte der Wellenform speichert sondern stark vereinfacht gesprochen die Wellenform in ihre "Summanden" zerlegt wird. Man kann sich das in etwa so vorstellen, das statt der Beispiel-Werte 0, 0, 1, 2, 7, 15 herausgefunden wird, dass die Funktion f(x) = x² - 2x sehr nahe kommt und im MP3 dann nur noch die Informationen "x²" und "-2x" gespeichert sind. In Wirklichkeit würde die Funktion dann zwar die Werte 0, -1, 0, 3, 8, 15 liefern, aber die Abweichung ist so gering, dass den Unterschied niemand "hören" würde. Stellt man sich jetzt vor, dass die Bitrate noch niedriger gewählt wurde und für zwei Informationen einfach kein Platz ist sondern nur für eine, würde wohl oder übel als Funktion f(x) = 0,5x² gefunden und benutzt, die die (gerundeten) Werte 0, 1, 2, 5, 8, 17 ergibt.

Die Summe der Differenzen zwischen den Ursprungswerten und denen der ersten Funktion beträgt insgesamt 4, bei der zweiten Funktion beträgt diese 8, womit die zweite (mit der niedrigeren Bitrate) ein schlechteres Ergebnis liefert.

Der Punkt ist einfach der, dass man sich, je komplexer die Funktion sein darf (= je höher die Bitrate), immer besser an das Original annähert aber die ganz genauen Ursprungswerte praktisch nie erreicht. MP3s sind niemals verlustfrei, da die Spezifikation keine Erlaubnis gibt, in kritischen Fällen oder ab einer bestimmten Bitrate die Ursprungswerte 1:1 zu speichern und die Umwandlung von Werten in Funktionen eben nur eine relativ genaue Annäherung an die Originaldaten bedeutet.

Ich habe das zwar noch nirgendwo gesehen, aber theoretisch hätte jemand einen Kopierschutz erfinden können, der bestimmte Bereiche in den Audiotracks ausliest und auf seine Originalwerte hin überprüft, womit CD-Images mit MP3s als Kopie erkannt würden.


Monokanal

Und um aus Links + Rechts einen Monokanal zu machen, macht man in der Regel genau das, was da beschrieben wurde. Links und Rechts addieren und dann durch 2 teilen, was alles andere als Hexenwerk ist.


Red Book

Das Red Book ist die Mutter aller CD-Formate und beschreibt Audio-CDs. Andere CDs als Audio-CDs werden mit andersfarbigen Books beschrieben, die aber meines Wissens alle auf dem Red Book basieren und daher einen sehr großen Teil der Red Book Spezifikation "erben". Siehe hier: http://de.wikipedia.org/wiki/Rainbow_Books#Red_Book


Daten innerhalb von CD-Images

Bei CD-Images sind grundsätzlich noch zwei Varianten zu unterscheiden: ISOs, die ausschließlich(!) die Nutzdaten (=2048 Bytes/Sektor bei Daten-Tracks) enthalten und solche wie z.B. BIN/CUE und CloneCD, die zusätzlich noch diverse Fehlerkorrektur- und Subchannel-Daten enthalten um auch den ein oder anderen Kopierschutz abbilden zu können. Sind Kopierschutz und Audiotracks nicht vorhanden, reicht ein ISO-Image vollkommen, da eh auf nichts anderes als die Nutzdaten zugegriffen wird. Da in einem solchen Fall die Fehlerkorrektur- und Metadaten etc. vom Emulationsprogramm, von der Brenner-Software oder vom Brenner selbst quasi live erzeugt werden sobald sie benötigt werden, ist es auch kein Problem, ein ISO zu brennen oder zu mounten und auch auf diese (Metadaten) zuzugreifen.

Unter Subchannel-Daten darf der Laie sich der Einfachheit halber eine Art von Metadaten vorstellen, die u.a. angeben, an welcher Position der CD man sich gerade befindet. Diese können zwecks Kopierschutz manipuliert worden sein, so dass CloneCD z.B. diese auch im Image mitspeichert.

[acp]

0

Danke für die Riesenaufklärung Feltzkrone, hab nur jeden Absatz mehrfach lesen müssen, um voll dahinterzusteigen!! Auch natürlich für alle anderen Meinung meinen Dank. Trotz allem ist mir jetzt natürlich einiges klarer.

Für Games ohne Kopierschutz/Audio nehm ich bis jetzt ohnehin reines ISO Format. Gibt's denn überhaupt Oldgames mit Kopierschutz???? Ich kenn keines. Und wenn Audio dabei ist werd ich wahrscheinlich CCD jetzt nehmen.

Was haltet ihr eigentlich von Nero? hätt ich nämlich auch....

[Retro-Nerd]

0

Original von acp1512

Für Games ohne Kopierschutz/Audio nehm ich bis jetzt ohnehin reines ISO Format. Gibt's denn überhaupt Oldgames mit Kopierschutz???? Ich kenn keines. Und wenn Audio dabei ist werd ich wahrscheinlich CCD jetzt nehmen.

Vor 1998 gab es mit Sicherheit keine wirksamen Kopierschütze wie Laserlok, SecuRom etc, sondern nur reine CD-Checks. Standard ISO's sind also für Single Track CD's ausreichend. Multitrack CD's dann halt im CCD, BIN oder MDF Format. Alcohol 120 % kann alle 3 verarbeiten und brennen.

Original von acp1512
Was haltet ihr eigentlich von Nero? hätt ich nämlich auch....

Völlig OK, um Standard ISO's oder auch Bin/Cue's zu brennen.

Hier ist eine Datenbank für PC Spiele mit Kopierschutz:

LINK

[acp]

0

Original von Retro-Nerd

Völlig OK, um Standard ISO's oder auch Bin/Cue's zu brennen.

Also mein Nero macht nur .NRG (würde auch Audio mitnehmen) oder .iso, aber definitiv kein BIn/CUE.

Cue erstell ich wenn ich brauch mit SegaCueMaker.

[Retro-Nerd]

0

Original von acp1512
Also mein Nero macht nur .NRG (würde auch Audio mitnehmen) oder .iso, aber definitiv kein BIn/CUE.

Schau mal unter "Rekorder - Image brennen" nach. Natürlich kann Nero auch ISO's und Bin/Cue Images brennen. Allerdings weiß ich nicht, ob du schon Nero 7 benutzt, nutze immer noch Nero 6.

[acp]

0

nero 7 hab ich und da kann ich wenn ich mich jetzt recht erinnere bei image brennen und beim speicherfenster auswählen nur .nrg und .iso.
werd aber trotzdem nachschauen abends wenn ich zuhaus bin.

[Retro-Nerd]

0

Rechtsklick auf die ISO oder das Cuefile und "Öffnen mit.." Nero exe sollte auch reichen.

[acp]

0

Original von Retro-Nerd
Rechtsklick auf die ISO oder das Cuefile und "Öffnen mit.." Nero exe sollte auch reichen.

Sorry, ich hab deine Frage vorhin wahrscheinlich falsch verstanden....

Öffnen kann ich natürlich, ich meinte eigentlich dass mein Nero7 nur NRG und ISO ERSTELLEN kann.

acp

Mein Fehler...