|
Nähere Einzelheiten finden Sie z.B. in den Beiträgen
Ich möchte dabei nicht im Detail auf die Herstellung oder die Codierung bzw. die entsprechenden Normen eingehen - dazu finden Sie im Internet genügend Material. Mir geht es nur um den Aufbau und die Speicherkapazität. Die Daten einer CD sind physikalisch in Übergängen von sogenannten Pits (Vertiefungen) zu der umgebenden Fläche, dem sogenannten "Land", enthalten, die in den Kunststoff geprägt oder gebrannt werden. Im Gegensatz zur Festplatte liegen diese Pits auf einer fortlaufenden konzentrischen (also spiralförmigen) Spur von innen nach außen - vergleichbar mit der alten Vinyl-Schallplatte. Die Datendichte dieser Pitspur ist am Anfang der Spirale (also im Inneren) die gleiche wie am Ende der Spur also am äußeren Rand der CD. Die äußeren, längeren Spuren erlauben es deshalb, mehr Informationen unterzubringen. Ältere CD-ROM-Laufwerke regelten dabei ihre Drehzahl so, dass die Daten stets mit konstanter Geschwindigkeit unter dem Laser vorbeikamen. Die einzelnen Pits und Lands (also die Höhen und Tiefen) wurden ursprünglich nach dem CLV-Verfahren (CLV = Constant Linear Velocity, konstante Lineargeschwindigkeit) spiralförmig von innen nach außen gelesen. Die Auslesegeschwindigkeit liegt konstant bei 1,2 Meter pro Sekunde, und die Rotationsgeschwindigkeit ist daher unterschiedlich. Je nachdem, ob die inneren oder die äußeren Spuren gelesen werden, variiert sie von 200 bis 500 Umdrehungen pro Minute. Bei CD-ROMs mit Daten gibt es jedoch keinen Grund mehr, das Tempo nach außen hin zu drosseln, und so arbeiten heute alle modernen Laufwerke im Datenbetrieb mit einer konstanten Drehzahl (CAV-Modus, Constant Angular Velocity, konstante Winkelgeschwindigkeit). Daraus ergibt sich im Außenbereich der CD-ROM eine höhere Datenübertragungsrate; die höchste Geschwindigkeit erreichen die Laufwerke demnach nur am Rand einer vollen CD. Wenn ein Hersteller für ein Laufwerk 50X angibt, meint er damit diesen Maximalwert.
Die Länge der Pit-Spur einer 74-Minuten - CD beträgt für den Programmbereich 5.378 Metern. Die kleinste Informationseinheit auf einer CD ist das sogenannte Channel-Bit. Vielleicht rührt der Begriff Channel-Bit noch aus der Zeit der Lochkarten, wo die in Lochspuren linear angeordneten Bits als "Kanal" bezeichnet wurden. Ein solches Channel-Bit hat eine Länge von 277,662 nm/bit. Die Kapazität des Programmbereiches ist damit
Ich will Sie nun nicht mit der speziellen Codierung langweilen. Nur soviel zur Vervollständigung: Ein Datenbyte besteht üblich aus acht Datenbits. Auf einer CD wird es allerdings durch 14 Channel-Bits dargestellt. Bedingt durch die mikroskopisch feine Struktur wurde ein spezielles Kodierverfahren genutzt um die Datensicherheit zu gewährleisten. Nun sollte man noch wissen, das die Bits in Frames zusammengefasst werden. Dabei bilden 588 Bits einen Frame und insgesamt 98 Frames bilden einen Sektor der CD. Dadurch ergibt sich folgende Rechnung:
Da der äußere Bereich einer CD anfangs bei der Produktion schwierig herzustellen und oft fehlerbehaftet war, ging man auf Nummer sicher und definierte für eine 74-min-CD 333.000 Sektoren. Sie können das übrigens auch recht schnell im Kopf rechnen, wenn Sie die Zeit mit einem Faktor von 4.500 multiplizieren. Die 4500 ergeben sich aus der genutzten Geschwindigkeit, denn in einer Sekunde werden 75 Sektoren gelesen (1 x speed) und eine Minute hat 60 Sekunden. Also 75 [Sektoren/Sekunde] x 60 [Sekunden/Minute] = 4500 Sektoren pro Minute Dadurch ergibt sich:
Die Unterschiede liegen in der Aufteilung und Nutzung dieser 2352 Bytes des Sektors. Vor mir auf dem Tisch liegt eine CD mit einer "Kapazitätsangabe" von 80 Minuten. Der Hersteller schreibt als tatsächliche Kapazität 700 MB auf die Verpackung. Was es damit auf sich hat, versuchen wir im nächsten Schritt zu klären: Eine 80-Minuten - CD hat, wie wir oben gelernt haben, 360.000 Sektoren á 2352 bytes / Sektor. Das ergibt 846.720.000 Bytes. Geht man nun davon aus, dass 1024 Bytes gleich 1 KB und 1024 KB = 1 MB ist (vergleiche
Bei einer normalen CD-ROM (also einer Daten-CD) geht man nun aber nicht von 2352 Byte pro Sektor aus, sondern nur noch von 2048 Byte mit User-Daten. Rechnen wir das erneut durch, so zeigt sich, dass nunmehr nur noch 703,125 MB -abgerundet 700 MB- auf die CD passen. Wir wollen uns nun nicht mit Audio-CDs oder Daten-CD beschäftigen. Unser Schwergewicht liegt, wie die Überschrift schon sagt, bei der Super Video CD. Eine SVCD ist nun eine CD-ROM XA. Nähere Details finden Sie auch unter
Wie bei einer klassischen CD-ROM haben wir am Anfang des Sektors (Form 1) einen Block mit 12 Synchronisations-Bytes. Die folgenden 4 Bytes werden für die Adressierung verwendet. Hinter diesem Header folgen 8 Byte Subheader und daraufhin die eigentlichen Nutzdaten von 2048 Byte. Der Bereich ECC steht für "error correction" und ist für die Fehlererkennung zuständig. Am Ende finden wir den Bereich EDC (error detection) mit 4 Byte, der für die Qualitätskontrolle während des Produktionsprozesses zuständig ist.
Da ein fehlerhaftes Bit bei einem Programm über die Lauffähigkeit entscheidet, wurde gerade bei der "Form 1", also der klassischen Daten-CD, besonderer Wert auf die Fehlerkorrektur gelegt. Ein einzelner Bit-Fehler in einem Video macht sich aber nicht bemerkbar. Und so hat man zu Gunsten des Speicherplatzes den "User-Daten-Bereich" auf 2324 Byte (Form 2) erweitert, indem man auf den Block ECC vollkommen verzichtet hat. Bei einer reinen Audio-CD stehen übrigens nach dem "Red-Book-Standard" noch mehr Byte für Anwenderdaten zur Verfügung (Verzicht auf Fehler-Korrektur: vergl. Andy McFadden's CD-Recordable FAQ unter
Soweit die theoretischen Grundlagen. Keine Angst, als User müssen Sie sich nicht unbedingt mit der ganzen Rechnerei rumplagen. Um zu ermitteln, wie viel Video-Film in welcher Einstellung auf eine CD geht, gibt es Software. Ein interessantes und kostenloses Programm finden wir bei
Wiljo Heinen, von Hause aus Diplom-Physiker, bietet unter diesem Markennamen die unterschiedlichsten Werkzeuge an. Unter
Die Software ist zwar etwas gewöhnungsbedürftig (die Ver 1.0 lässt sich wirklich nur über "exit" verlassen) - aber für unsere Zwecke genau richtig.
Oben rechts tragen Sie die Länge Ihres Filmes ein. Hier in unserem Beispiel 50 Minuten. Wenn Sie das genau machen wollen, schauen Sie z.B. mit Ihrem Schnittprogramm nach, wie viel Frames Ihr Film hat. Nun wissen Sie noch, dass Sie 25 Frames pro Sekunde gerendert haben. Durch Division der beiden Zahlen ergibt sich die exakte Filmlänge. Hier also 50 Minuten. Im nächsten Schritt wählen Sie die Größe Ihrer Ziel-CD. In unserem Beispiel 80 Min. Das nächste Eingabefeld erlaubt Ihnen, die Größe des "Form1"-Bereiches zu definieren. Da kommt es nun darauf an, ob Sie neben Ihrem Film noch Bilder, Texte oder Programme mit auf die CD bringen wollen. In unserem Beispiel haben wir 1.647.456 Byte eingetragen. Wiljo Heinen subtrahiert nun nicht einfach diese Größe, er geht vielmehr den Weg über die Sektoren. Wir wissen, dass im Form1-Bereich ein Segment nur 2048 Byte an Daten beherbergt. Unsere 1.647.456 Byte entsprechen also 804 Sektoren. Zieht man von der Ausgangsgröße von 360.000 Sektoren nun die 804 Sektoren ab, so verbleiben 359.196 Sektoren á 2324 Byte für unsere Videodaten. Das sind damit 834.770.524 Byte. Zieht man davon, die von Herrn Heinen angenommenen, o.a. 7.902.302 Byte für "PACK and PES", die 6.972.000 Byte für "sequence aligning" und die 3.900 Byte für "SVCD scan offset" ab, so bekommt man exakt die dargestellten 819.892.322 Byte. Multipliziert man nun die zur Verfügung stehende Dateigröße mit 8 Bit/Byte, so kommt man auf 6.559.138.576 bit. Nun wissen wir, dass unser Video 50 Minuten laufen soll - also 3000 Sekunden. Teilen wir 6.559.138.576 bit durch 3000 Sekunden, so erhalten wir die Datenrate mit 2.186.380 bit/sec. Teilen wir dies noch durch 1024 bit/Kbit, so erhalten wir die angegebene Zahl von 2.135. Leider stimmt im o.a. Programm meiner Meinung nach die Bezeichnung nicht. Herr Heinen hat ein kleines "k" genutzt. Und nach langläufiger Meinung hätte er dann nur durch 1000 bit/kbit teilen dürfen (vergl.
Doch das ist kein Fehler den Herr Heinen "verschuldet" hat. Die IEC 62107, die Sie für 156,- CHF unter
Wie dem auch sei, ganz so genau muss es gar nicht sein: Andreas Riel, der zu dem Thema schon ein paar Ideen im Internet veröffentlicht hat, hat sich an die praktische Umsetzung gemacht und sich angesehen, was ein solches Programm in der Praxis bringt:
Man kann übrigens nicht nur an der Schreibweise von kbps oder Kbps feststellen, was gemeint ist. Am Beispiel von TMPGEnc, der auch das Kürzel kbps verwendet, kann man nachweisen, dass bei TMPGEnc mit 1000 bit/kbit gerechnet wird. Man muss dazu nur einen kpl. MPEG-Stream in einen Video- und einen Audio-Stream zerlegen (durch Demux) und dann kann man über die eingestellte Datenrate und die Zeit nachrechnen, dass mit 1000 bit/kbit und nicht mit 1024 bit/Kbit gerechnet wurde. Herr Heinen wird nach unseren Informationen bei seiner nächsten Version von "SVCDcalc" übrigens kbps und Kbps ausgeben.
Was machen wir nun mit der so berechneten Datenrate? Klar, wir codieren damit einen Film - und zwar mittels TMPGEnc. Mein Vorschlag geht nun dahin, die TMPGEnc-Einstellung "2pass variable bitrate" zu nutzen. Einige werden sich jetzt die Haare raufen, denn das ist so mit die längste Rechenzeit, die TMPGEnc beansprucht. Dies aber nicht umsonst. TMPGEnc analysiert zuerst den gesamten File in der kompletten Länge. Dabei berechnet TMPGEnc, vorgegeben über die mittlere Datenrate, den Stream. Hierbei wird peinlich genau drauf geachtet, das im Mittel der eingestellte Wert herauskommt. Sie haben dazu neben den bereits aus anderen EDV-TIPPs bekannten Einstellungen zwei Bereiche zu ändern: Zuerst geben wir die Datenrate für den Ton ein:
Danach geht es an die Datenrate für das Video:
Hier stellen wir als "mittlere Datenrate" (Average bitrate) unsere ausgerechneten 1911 kbit/sec ein. Ob Sie diese Datenrate zu ungunsten des Tones steigern, hängt von Ihrem Video und der angestrebten Qualität ab. Ich selbst kann es nur wärmstens empfehlen.
Um eine ansprechende Qualität zu erreichen, sollte der errechnete Datenstrom nicht unter 1500 kbit/sec liegen. Im Zweifel zerteilen Sie das Video lieber. Dies machen Sie z.B. mit VirtualDub oder mit TMPGEnc. Nun stellen Sie aber fest, dass dies mitten in einer Szene wäre. Also suchen Sie sich einen schönen Übergang aus und schneiden dort. Denken Sie dabei daran, einen MPEG-Stream auch nur bei einem I-Frame zu schneiden. Aus I B B P B B P I B B P B B P wird durch den Schnitt richtigerweise I B B P B B P und I B B P B B P .
Heraus kommt ein File, der ziemlich genau zum berechneten Platz passt, so dass dieses File jetzt auf unsere CD gehen sollte. Sie können das übrigens mehr oder weniger schnell selbst herausfinden. Wandeln Sie einfach einmal ein AVI-File in ein SVCD - konformes MPEG2-File um. Nutzen Sie dazu einmal eine konstante Bitrate (obwohl für SVCD nicht vorgesehen) und zum zweiten die "2pass variable bitrate (VBR)". Sie werden feststellen, dass die beiden Dateien z.B. bei den neueren TMPGEnc-Versionen (>12c) gleich groß sind. Ein sicheres Zeichen dafür, dass TMPGEnc sich an die vorgegebene "mittlere Datenrate" gehalten hat. Bei den Versionen 12 und 12a waren die Dateigrößen von CBR zu VBR allerdings recht unterschiedlich. Achtung: Zwischen den Versionen 12 und 12 a und allen Nachfolgeversionen gibt es einen nicht unerheblichen Qualitätsunterschied. Der Encodertest
"The earlier versions were better. The current problem is if we set the dual pass VBR the result's bitrate is extremelly strange. There is some problem with the average bitrate calculation. You can see on the graph, that at the swimming pool scene the bitrate gets down instead of groving. The earlier version, for eg. the simple Beta 12 worked well from this point of view.The encoder strictly try to hold the set avg. 5 Mbit and as can be seen the result is an oscillation bitrate. The speed of encoder improved by 30% comparing to the first Beta 12 version. We are a bit disappointed..."
Stefan und ich haben zahlreiche Files mit allen möglichen Programmen gewandelt, um herauszufinden, wie genau eine solche Berechnung wirklich ist, bzw. sein muss.
Unser Film hatte 14.522 Frames. Bei 25 Frames pro Sekunde ergab sich eine Laufzeit von 580,88 sec. Da SVCDcalc nur ganze Minuten als Eingabe zulässt, haben wir die Kalkulation mittels einer Excel-Tabelle nachgebildet. Wir hatten im ersten Schritt unser File mit TMPGEnc umgewandelt. Das gleiche AVI-Ausgangsfile wurde anschließend mit AVI2MPG2 in einen SVCD-konformen MPEG-Stream gewandelt. Die eingestellten Parameter waren hinsichtlich der Datenraten vergleichbar. Bei unserem Versuch erzielten wir MPEG-Files mit folgenden Größen:
Nun kann man daran sehen, dass das Brennprogramm am jeweiligen File nochmals Hand anlegt und die Größe des Ausgangsfiles verändert. Was hilft also nun eine so schöne Software wie SVCDcalc, wenn sich die Brennprogramme nicht daran halten?
Wir wandeln den bereits bekannten AVI-Film mit einer mittleren Datenrate beim Video-Stream von 2200 kBit/sec und beim Audio-Stream von 224 kBit/sec in ein MPEG-SVCD-File um. Abgeleitet aus dem o.a. Programm SVCDcalc und unter Berücksichtung von empirischen Werten aus zahlreichen Versuchen addieren wir für den Overhead beim Muxen und Brennen 71 kBit/sec hinzu. Also:
Daraus machen wir nun Bit/sec und multiplizieren mit 1000 bit/kbit
Von weiter oben im Text wissen wir, dass unser Film 580,88 Sekunden lang ist. Um die Filegröße zu ermitteln, multiplizieren wir nun mit der Zeit
Nun rechnen wir das Ganze in Byte um
Wir glauben, dass Sie mit dieser Faustformel und 71 kbit/sec für den Overhead auf der sicheren Seite liegen. Sie können über diesen Weg von der eingesetzten Datenrate auf die Größe des Files schließen, das letztendlich ja auf Ihre CD soll. Im Internet und auch in einigen Newsgroups finden sich einige Veröffentlichungen mit rund 76 kbit/sec, doch wir glauben, da hat einer vom anderen abgeschrieben, ohne es jemals selbst errechnet oder probiert zu haben. Zumal uns keiner sagen konnte, wo der Wert eigentlich herkommt. Wir denken, dass es somit möglich ist, eine CD optimal auszunutzen. Viel Spaß dabei...
*) Das Programm "SVCDcalc" von Wiljo Heinen ist leider nicht mehr verfügbar. Herr Heinen hat es aus dem Web genommen. Wenn Sie wollen, können Sie sich für die Berechnung nach den o.a. Formeln auch eine einfache Exceltabelle erstellen. Alternativ kann ich Ihnen aber das Programm "FitCD" von ixi.nixi unter
| |||||||||||||||||||||||||||||||||||||||||||||||||||||