Skillnad mellan versioner av "Bitdjup"

Från Kontrollrummet
Hoppa till: navigering, sök
m
m
 
(5 mellanliggande versioner av samma användare visas inte)
Rad 22: Rad 22:
 
För de som inte vet vad mantissa och exponent är, så kan man förklara det med exempalvis det decimala talet 100, som också kan skrivas som 1*10<sup>2</sup>, där 1 är mantissan, 10 är basen och 2 är exponenten (typ hur många nollor det ska vara - och när exponenten har ett negativt värde, så handlar det typ om hur många nollor det ska vara mellan decimaltecknet och mantissans värdesiffror).
 
För de som inte vet vad mantissa och exponent är, så kan man förklara det med exempalvis det decimala talet 100, som också kan skrivas som 1*10<sup>2</sup>, där 1 är mantissan, 10 är basen och 2 är exponenten (typ hur många nollor det ska vara - och när exponenten har ett negativt värde, så handlar det typ om hur många nollor det ska vara mellan decimaltecknet och mantissans värdesiffror).
  
Eftersom formatet är organiserat som det är, så tillåter det en dynamik mellan 3,4*10<sup>-38</sup> och 3,4*10<sup>+38</sup>. Detta är ett spann på 1*10<sup>76</sup>, vilket blir hisnande 1520dB. Upplösningen för '''varje sampling''', oavsett nivå, är 24-bit - så formatet är enormt mycket bättre upplöst än övriga.
+
Eftersom formatet är organiserat som det är, så tillåter det en dynamik mellan 3,4*10<sup>-38</sup> och 3,4*10<sup>+38</sup>. Detta är ett spann på 1*10<sup>76</sup>, vilket blir hisnande 1680dB. Upplösningen för '''varje sampling''', oavsett nivå, är 24-bit - så formatet är enormt mycket bättre upplöst än övriga.
  
 
Detta utnyttjas dock inte när man spelar in, eftersom man bara kan få 24 bits från omvandlaren, så om man skulle spela in in 32-bit FP, så blir det bara 24 bits men ingen exponent som sparas.
 
Detta utnyttjas dock inte när man spelar in, eftersom man bara kan få 24 bits från omvandlaren, så om man skulle spela in in 32-bit FP, så blir det bara 24 bits men ingen exponent som sparas.
Rad 41: Rad 41:
 
Detta är dock ett helt felaktigt påstående!
 
Detta är dock ett helt felaktigt påstående!
  
Båda metoderna ger ett mycket bra resultat och skillnaden är helt enkelt att en dator jobbar mycket snabbare med flyttal än med heltal, medan DSP (som det sitter i ljudkorten till ProTools och i många externa digitala effekter etc), är bättre på heltal än på flyttal.
+
Båda metoderna ger ett mycket bra resultat och skillnaden är helt enkelt att en dator jobbar bättre med flyttal än med heltal, medan DSP (som det sitter i ljudkorten till ProTools och i många externa digitala effekter etc), är bättre på heltal än på flyttal.
 +
 
 +
===Vi går djupare===
 +
Nu blir det lite teori kring detta, som visar att det varken är bättre eller sämre med fixed eller float. Den suveräna utredningen nedan skrevs ihop av Lars på [[XLN Audio]] och han tyckte att det var ok att lägga in den här i Wikin. :)
 +
 
 +
Ur teknisk synvinkel så handlar det om att datorer räknar på flyttal mycket snabbare än heltal.
 +
Och DSP-chips som sitter i ProTools TDM och många hårdvarureverb etc är bättre på heltal.
 +
 
 +
Så valet av beräkningssätt har ingenting med ljudkvalitet att göra över huvud taget.
 +
 
 +
Det här är ju lite lurigt att förklara men let me ramble on.
 +
 
 +
Om vi tänker oss att vi har en vågform i 16 bit WAV eller AIF, så är samplevärdena lagrade som heltal. Det lägsta värdet är -32768 och det högsta är 32767. Mitten är 0. Vågformen går upp och ner mellan de värdena.
 +
 
 +
I en datorhost omvandlas värdena till flyttal som kan variera mellan -1.0 och 1.0 (mitten är fortfarande 0). Alla värden däremellan blir med en massa decimaler. Hur många decimaler bestäms av bitdjupet. Och de är många i standard 32bitsystem.
 +
 
 +
I ett DSP-system (heltal) multipliceras värdena till mycket större tal (hur mycket större bestäms av bitdjupet.)
 +
 
 +
Poängen är då att när man ska räkna på talen (multiplicera, addera och annat skoj som händer i hostens mixer) så får man då tillgång till mycket större noggrannhet. En massa decimaler i flyttalsfallet - I heltalsfallet finns inga decimaler så då jobbar man helt enkelt med mycket större tal istället. Samma grej egentligen, bara olika sätt att angripa problemet.
 +
 
 +
 
 +
Låt säga att vi vill sänka volymen 1%, till 99% av vad den var från början.
 +
 
 +
 
 +
Flyttal:
 +
Flyttalet 1.0 blir 0.99. (Ingen avrundning eller dataförlust där) 1 * 0,99 = 0,99.
 +
 
 +
Om vi sen omvandlar tillbaka till ett 16 bit heltal (säg vid export till master):
 +
0,99 * 32768 = 32440,32 ->avrundas till 32440
 +
 
 +
 
 +
Heltal:
 +
Heltalet 32768 multipliceras upp (för varje ytterligare bit fördubblas talet, så för varje 8 bitars djup multiplicerar man med 256).
 +
 
 +
32768 * 256 * 256 * 256 * 256 = 140737488355328 vid omvandling till 48 bit.
 +
140737488355328 * 0,99 = 139330113471774,72, decimalerna finns inte så det blir 139330113471774
 +
 
 +
Om vi sen omvandlar tillbaka till ett 16 bit heltal (säg vid export till master):
 +
 
 +
139330113471774 / 256 / 256 / 256 / 256 = 32440,319999999832361936569213867 -->avrundas till 32440
 +
 
 +
= Samma resultat.
 +
 
 +
 
 +
Trots dessa stora tal / många decimaler så sker hur som helt avrundningar hela tiden. Poängen är att de här avrundningarna är så oerhört små jämfört med de tal som utgör själva "ljudet" att det är som att försöka urskilja ljudet av en fallande knappnål bredvid en rusande jetmotor. De "fel" som uppstår ligger långt bortom vad någon levande männsika kan urskilja, bortom vad en mikrofon kan uppfånga eller högtalare återge.
  
 
[[Kategori:Ljudteknik]]
 
[[Kategori:Ljudteknik]]
 
[[Kategori:Datorer]]
 
[[Kategori:Datorer]]
 
[[Kategori:Mjukvara]]
 
[[Kategori:Mjukvara]]

Nuvarande version från 19 mars 2018 kl. 16.52

Avser det antal bits (och alltså den dynamik) som en digital inspelning kan innehålla i det valda formatet.

16-bit

En audio-CD har 16-bits dynamik. En bit innebär en skillnad på 6dB, vilket gör att en audio-CD kan ha max 96dB dynamik.

Varje sampling kan ha ett värde mellan -32768 och +32767. Det som hamnar mellan dessa absoluta värden, avrundas till närmaste nivå.


24-bit

En 24-bits inspelning kan ha max 144dB dynamik.

Samplingarna kan ha ett värde mellan -8388608 och +8388607 (16777216 nivåer).


32-bit Floating Point

192dB dynamik, eller...?

Fullt så enkelt är det inte, utan en 32-bit Floating Point inspelning innehåller egentligen 24-bits ljudinformation (det finns inte omvandlare med högre upplösning), medan de extra 8 bitarna är en skalningsfaktor, som ger möjlighet till ENORMT stor dynamik.

Formatet innehåller en 24-bit mantissa, en 8-bit exponent och en tecken-bit (+/-). Det blir 33 bits totalt, men mantissans värde har alltid MSB satt till 1, så behöver man inte bry sig om att spara den biten, utan det räcker ändå med 32 bits och programmen utgår från att MSB alltid ska vara 1.

För de som inte vet vad mantissa och exponent är, så kan man förklara det med exempalvis det decimala talet 100, som också kan skrivas som 1*102, där 1 är mantissan, 10 är basen och 2 är exponenten (typ hur många nollor det ska vara - och när exponenten har ett negativt värde, så handlar det typ om hur många nollor det ska vara mellan decimaltecknet och mantissans värdesiffror).

Eftersom formatet är organiserat som det är, så tillåter det en dynamik mellan 3,4*10-38 och 3,4*10+38. Detta är ett spann på 1*1076, vilket blir hisnande 1680dB. Upplösningen för varje sampling, oavsett nivå, är 24-bit - så formatet är enormt mycket bättre upplöst än övriga.

Detta utnyttjas dock inte när man spelar in, eftersom man bara kan få 24 bits från omvandlaren, så om man skulle spela in in 32-bit FP, så blir det bara 24 bits men ingen exponent som sparas. Det är däremot viktigt när man gör bearbetningar, eftersom man får avrundningsfel vid varje bearbetning om man har ett fast bitdjup i stället för floating point - och eftersom alla dagens DAW-program hanterar ljuddata med 32-bit FP internt, oavsett vilken upplösning det är i ljudfilerna, så har man stor hjälp av den bättre upplösningen.

Om man kör allting i realtid fram till slutmixen, så är det därför inga problem att behålla högsta möjliga kvalitet, utan det går helt automagiskt. Om man däremot behöver göra partiella nedmixningar under resans gång, så är det lämpligast att välja 32-bit FP som filformat, eftersom man då inte förlorar data som man gör med fast bitdjup.

Det går att ha signal långt över 0dB så länge man håller sig i 32-bit FP-formatet (som DAW-programmen gör internt), men för att ljudkortet ska kunna återge det utan distorsion, så måste man förstås dra ner det till 0dB.


48-bit

ProTools har i de senare versionerna börjat använda sig av 48-bit internt i stället för 24-bit, som de har haft tidigare. Detta ger en maximal dynamik på 288dB, något som borde räcka till för de flesta användare.


Float vs Fixed

Det har ibland hävdats (framför allt från ProTools-anhängare) att det är lämpligare för audiobruk att använda heltal (Fixed Point), än att använda flyttal (Floating Point) på grund av att flyttal är mer komplicerade uträkningar.

Detta är dock ett helt felaktigt påstående!

Båda metoderna ger ett mycket bra resultat och skillnaden är helt enkelt att en dator jobbar bättre med flyttal än med heltal, medan DSP (som det sitter i ljudkorten till ProTools och i många externa digitala effekter etc), är bättre på heltal än på flyttal.

Vi går djupare

Nu blir det lite teori kring detta, som visar att det varken är bättre eller sämre med fixed eller float. Den suveräna utredningen nedan skrevs ihop av Lars på XLN Audio och han tyckte att det var ok att lägga in den här i Wikin. :)

Ur teknisk synvinkel så handlar det om att datorer räknar på flyttal mycket snabbare än heltal. Och DSP-chips som sitter i ProTools TDM och många hårdvarureverb etc är bättre på heltal.

Så valet av beräkningssätt har ingenting med ljudkvalitet att göra över huvud taget.

Det här är ju lite lurigt att förklara men let me ramble on.

Om vi tänker oss att vi har en vågform i 16 bit WAV eller AIF, så är samplevärdena lagrade som heltal. Det lägsta värdet är -32768 och det högsta är 32767. Mitten är 0. Vågformen går upp och ner mellan de värdena.

I en datorhost omvandlas värdena till flyttal som kan variera mellan -1.0 och 1.0 (mitten är fortfarande 0). Alla värden däremellan blir med en massa decimaler. Hur många decimaler bestäms av bitdjupet. Och de är många i standard 32bitsystem.

I ett DSP-system (heltal) multipliceras värdena till mycket större tal (hur mycket större bestäms av bitdjupet.)

Poängen är då att när man ska räkna på talen (multiplicera, addera och annat skoj som händer i hostens mixer) så får man då tillgång till mycket större noggrannhet. En massa decimaler i flyttalsfallet - I heltalsfallet finns inga decimaler så då jobbar man helt enkelt med mycket större tal istället. Samma grej egentligen, bara olika sätt att angripa problemet.


Låt säga att vi vill sänka volymen 1%, till 99% av vad den var från början.


Flyttal: Flyttalet 1.0 blir 0.99. (Ingen avrundning eller dataförlust där) 1 * 0,99 = 0,99.

Om vi sen omvandlar tillbaka till ett 16 bit heltal (säg vid export till master): 0,99 * 32768 = 32440,32 ->avrundas till 32440


Heltal: Heltalet 32768 multipliceras upp (för varje ytterligare bit fördubblas talet, så för varje 8 bitars djup multiplicerar man med 256).

32768 * 256 * 256 * 256 * 256 = 140737488355328 vid omvandling till 48 bit. 140737488355328 * 0,99 = 139330113471774,72, decimalerna finns inte så det blir 139330113471774

Om vi sen omvandlar tillbaka till ett 16 bit heltal (säg vid export till master):

139330113471774 / 256 / 256 / 256 / 256 = 32440,319999999832361936569213867 -->avrundas till 32440

= Samma resultat.


Trots dessa stora tal / många decimaler så sker hur som helt avrundningar hela tiden. Poängen är att de här avrundningarna är så oerhört små jämfört med de tal som utgör själva "ljudet" att det är som att försöka urskilja ljudet av en fallande knappnål bredvid en rusande jetmotor. De "fel" som uppstår ligger långt bortom vad någon levande männsika kan urskilja, bortom vad en mikrofon kan uppfånga eller högtalare återge.