32-Bit, Headroom und Clipping

[KoolKolle]

Es traten ja jetzt schon in vielen Threads Bemerkungen zu diesem Thema auf. Mich würde mal konkret interessieren wie das denn genau ist. Ein 32-bit Sequenzer der im Mixer einen Clip anzeigt übersteuert also nicht zwingend - ich kann die Clipanzeige also getrost ignorieren solange es sich nicht verzerrt anhört... Wird mir schwer fallen (ich habe noch nicht lange einen 32-Bit Sequenzer). Mir ist die ganze Materie dewegen auch sehr neu. In der Tat konnte ich aber auch trotz [g=99]Clipping[/g] oft keine Übersteurungsverzerrung hören.

Gibt es eine Faustregel wieviel dB das Signal Clippen darf bevor es übersteuert? ist das auch Spektrumabhängig?
Das Ding ist ja auch - jetzt mal reinhypothetisch - nehmen wir an ich leite das clippende 32-Bit Summensignal in einen anderen Sequenzer oder einen Audiorecorder der mit 16-Bit arbeitet und nehme auf. das ergebnis ist klar - die Aufnahme wird dann Übersteuert klingen. Wenn das Programm jetzt wavelab ist und ich stelle es um auf 32-BitAufnhame dürfte das dann ja nicht mehr der falls sein. Aber wenn ich die 32-Bit Datei dann auf Audio-CD Brenne wo sie dann ja umgewandelt wird dürfte sie wieder übewrsteuern.

Kann mir das jemand mal genau erklären?

 

[Brainsaw]

Na ja, da kann ich eigentlich nur 2 Sachen dazu sagen: erstens kann natürlich auch ein 32 Bit Wort übersteuert werden. Im Computer haben einfach alle Zahlen eine Ober- und eine Untergrenze. Zweitens: alte Regel: "if it sounds right it is right". Viele Hersteller bauen einen zusätzlichen [g=284]Headroom[/g] ein, es wird praktisch schon ein paar DB vor dem Übersteuern [g=99]Clipping[/g] angezeigt.

 

[KoolKolle]

kKlar können 32-Bit Dateien auch übersteuern. mich würde nur interessieren von was das genau abhängt (Nur Lautstärke allein scheint es ja nicht zu sein - ich vermute auch allein von der Logik her die Addfierungen von Signalen innerhalb eines Spektrums) und ob es Faustregeln gibt - abgeshen vom Ohr.

und wie das ist wenn eine 32-Bit datei eigentlich klippt, man es aber nicht hört wegen dem [g=284]Headroom[/g] in eine 16-Bit datei umgewandelt wird.

Weiß das jemand genauer?

 

[InSomnius]

KoolKolle schrieb:

und wie das ist wenn eine 32-Bit datei eigentlich klippt, man es aber nicht hört wegen dem [g=284]Headroom[/g] in eine 16-Bit datei umgewandelt wird.

also, wenn die dateien nach der umwandlung dann doch clippen würden, hätte es ja überhaupt keinen sinn, mit 32 bit zu arbeiten, weil man zwar THEORETISCH den fader noch gaaaaaaaanz weit nach oben ziehen könnte, das aber nicht darf, weil sonst hinterher die 16bit-datei für die cd clippt. man würde es sich also quasi unnötig schwer machen und unnötig speicherplatz verbraten.


Der Gruß

Griffin

 

[KoolKolle]

Also ist das arbeiten mit 32-Bit dateien quasi sowas wie ein "natürlicher Maximizer"?

 

[soultan]

Du hast doch Wavelab.Teste es doch einfach! Aber ich glaube kaum dass es da eine allgemein gültige Regel gibt, ausser wie gesagt das Ohr.

Wenn du keine CDs verbrauchen willst, mach doch einfach ein image. alles was eigentlich schlussentlich auf der CD wäre, hast du dann als eine Datei auf der HD.

 

[OldWise]

wenn du mit 32bit aufgenommen hast und dann deine Datei auf auf 16bit renderst, dann werden die überschüssigen Bits ganz einfach abgeschnitten. Dies kann stellenweise zu häßlichen Klängen im Endergebnis führen. Deshalb ist das Dithering wichtig.

Solange es nicht hörbar klippt ist es auch nicht so schlimm, da ja gute Sequenzer einen entsprechenden [g=284]Headroom[/g] haben. Die Signale die aber über der 0db Grenze sind werden dann beim Mixdown aber einfach abgeschnitten. Das kann man sogar sehen.

 

[he]

32Bit sind fast immmer Floating-Points, 16 fast immer Integers. Aber man darf niemals Floating-Points mit Integern in einen Topf werfen, da die Darstellung der Zahlen komplett unterschiedlich ist. 32Bit-Floats wirst du niemals zum Übersteuern bekommen, da du dafür weit über die 700dB gehen müsstest. Integer sind normalerweise so skaliert, das sie bis maximal 0dB gehen.
Reden wir hingegen jeweils über Integers (sowohl bei 16, als auch bei 32Bit), was sehr unwarscheinlich ist, dann wird dir in der Regel keines von beiden einen größeren [g=284]Headroom[/g] verschaffen. Allerdings kann man Integer so skalieren, dass sie mehr [g=284]Headroom[/g] haben, dafür aber weniger Genauigkeit, was aber unabhängig von 16 oder 32Bit geschieht. Dabei handelt es sich dann aber um spezielle implementierungen.

Da wir aber vermutlich über die üblichen Darstellungen reden, wie sie auch von z.B. Wave-Dateien verwendet werden gilt das anfangs gesagt: 32-Bit FP unübersteuerbar, 16-Bit Int übersteuert über 0dB

 

[ruecking]

hey he,
du scheinst dich auszukennen. was ist jetzt der genaue unterschied zwischen floating point und integer?
ich weiß integer sind nur ganze zahlen. aber bei floating point ist ja auch irgendwann schluss.
ein computer kann nur diskrete information speichern. irgendwann wird abgeschnitten.
32 bit heißt für mich nur, dass halt sehr viele nachkommastellen gespeichert werden.
aber das ist doch keine andere info, als wenn ich ganze zahlen mit mehr spielraum nach oben (rein zahlentechnisch) nehme.
seh ich da was falsch? du betonst ja den unterschied zwischen integer und floating point so sehr, was steckt da dahinter?
grüße,
ruecking

 

[netco]

Hallo ruecking,

floating point heißt im Deutschen Fließkomma. Das ist also eine Zahl, bei der sich das Komma verschiebt. Um dies zu realisierenn arbeitet man mit 10-Potenzen. So ist z.B. 100 das gleiche wie 0,1 mal 10 hoch 3. Für den PC gibt es bei floating point nur Zahlen der Form

0, ... mal 10 hoch ...

Mit dieser Konvention muss er nur noch die Zahlen speichern, die hier mit ... dargestellt sind. Für die Zahlen nach dem Komma, verwendet der Rechner 24 bit (eins fürs Vorzeichen, 23 bit für die Ziffern) kann also von 16 Mio. verschiedene Zahlen darstellen. Die restlichen 8 bit werden für die Potenz verwendet (wiederum eins fürs Vorzeichen). So habe ich Potenzen von -128 bis +128. Damit komme ich sehr nah an die Null ran, mit 10 hoch -128 (also nach dieser System auf ein 0, mit 128 folgenden Nullen, aber auch in sehr große Zahlbereiche, eben mit 1 und 127 Nullen dran (keine Ahnung, wie eine solche Zahl heißt.)) Systembedingt werden die Abstände zwischen den Zahlen immer größer. Aber man spart sehr viel Speicherplatz.

Für den Musiktreibenden ist nur wichtig, dass durch diese große Reichweite der Zahlen, ein Übersteuern unmöglich ist. (hier stand eben was von 700db, das kann sicher stimmen )

Ich hoffe, ich habe nicht zu viel Verwirrung gestiftet,

Netco

 

[ruecking]

ok. es ist also einfach eine geschickte art zahlen abzuspeichern.
so wie auch der taschenrechner besonders kleine zahlen
mit x*exp{-y} darstellt. hab ichs kapiert?

 

[he]

Fließpunktzahlen haben eine Mantisse und einen Exponenten. Bei 32Bit Floats ist die Mantisse 24Bit groß. Der Exponent belegt den Rest. Mit Hilfe des Exponents kann nun der Wertebereich quasi verschoben werden.

Integers haben eine bestimmte Anzahl von Ziffern, die gespeichert werden kann.

Das ganze will ich mal an Beispielen verdeutllichen. Da viele hier wohl nicht ganz so fit im Binärrechnen sind verwende ich einfach mal das Dezimalsystem. Damit das ganze übersichtlich bleibt, verwende ich nicht 16 oder mehr Ziffern (bei Integern äquivalent zu Bits), sondern nur 8.

Dann können wir beispielsweise die Zahl 12345678 speichern und zwar so wie sie ist:
12345678
Die größte Zahl die möglich ist, ist
99999999
, die kleinste Zahl ungleich 0 ist
00000001, also 1
. Wollen wir kleinere Zahlen ungleich 0 speichern geht das nicht. Wollen wir größere als 99999999 speichern geht das auch nicht. Ersteres bedeutet sehr schlechte Genauigkeit bei leisen Signalen, letzteres bedeutet Übersteuern bei zu lauten Signalen.


Bei FPs sieht das ganze etwas anders aus. Nehmen wir ebenfalls 8 Ziffern, die gespeichert werden können, allerdings werden sechs für die Mantisse und zwei für den Exponenten verwendet. (Allerdings wird der Bereich für den Exponenten nicht 0 bis 99 sein, sondern -50 bis +49, also trotzdem insgesammt 100 verschiedene Zahlen. Bei FP-Zahlen im Binärsystem ist das genauso. Da ist es allerdings auch bei der Mantisse so.)

Die Beispielszahl 12345678 würde als
123456*10^+02
gespeichert. Also erstmal weniger Genauigkeit, bei selber Gesammtgröße (nur die ersten sechs Stellen, statt der gesammten acht Stellen).
Allerdings ist die größte Zahl
999999*10^+49
Also ausgeschreiben:
999999000000000000000000... ( insgesammt 49 Nullen, also verdammt riesig!)
Die kleinste Zahl ist
999999*10^-50
Ausgeschreiben:
0,0000000000...000999999 (mit 49 Nullen zwischen dem Komma und der ersten 9, also verdamt klein)



Integers verhalten sich also ganz anders als FPs. Die Genauigkeit von Integern wird nur voll ausgenutzt, wenn das Signal die volle Lautstärke erreicht. Die Genauigkeit von FPs wird quasi immer voll ausgenutzt (es sei denn man nähert sich den extremst kleinen Zahlen, die dann in sogenannter denormalisierter Form gespeichert werden müssen, aber das geht jetzt über den kurzen Exkurs hinaus. Vielleicht habt ihr aber schonmal von dem Problem gehört, das Prozessoren mit Denormalen haben (Verarbeitung deutlich langsamer, vor allem beim Pentium 4). Bei Plugins, die nicht verhindern, dass die Zahlen zu klein werden, spricht man auch schonmal vom Denormal-Bug).
Dafür ist die Genauigkeit von Integern besser, wenn sie optimal ausgenutzt werden kann (wenn sowohl Integer, als auch FP die selbe Zahl an Bits hat).

 

[he]

OK, ich hab was länger gebraucht und glaube meine Erklärung war trotzdem nicht besonders verständlich. Die vor mir ist vermutlich viel einfacher zu verstehen.

ok. es ist also einfach eine geschickte art zahlen abzuspeichern.
so wie auch der taschenrechner besonders kleine zahlen
mit x*exp{-y} darstellt. hab ichs kapiert?

Ja.

 

[ruecking]

cool. kapiert.
merci auch für deine erklärung he.
doppelt hält besser.

 

[he]

loating point heißt im Deutschen Fließkomma. Das ist also eine Zahl, bei der sich das Komma verschiebt. Um dies zu realisierenn arbeitet man mit 10-Potenzen.

Fast. Es werden in wirklichkeit Zweierpotenzen verwendet. Aber das ist ja nur ein Detail.

 

[Brainsaw]

Für alle Interessierten: ein Artikel über Gleitkommazahlen bei wikipedia