dithering?

[MusicGene]

ni har missuppfattat mig om ni tror att jag har fel 😛

[VacUm]

sluta upp med det där klippande-snacket nu innan jag blir galen.

om ett ljudprogram använder 32-bitars upplösning internt konverteras alla 16-bitarsljud till 32-bitar (genom att lägga på 16 nollor troligtvis). Sen om ditt ljudkort bara kan spela upp 16 bitar så klipper den av de 16 minst signifikanta bitarna. Har du en dither på före så ser den till att använda informationen i de 16 minst signifikanta bitarna för att förbättra på de 16 mest signifikanta så när ljudprogrammet klipper bort de 16 minst signifikanta har lite av den informationen redan sparats bland de 16 mest signifikanta bitarna och på så vis förbättrat kvaliteten.

My statement stands, använd dither även om du spelat in i 16 bitar.

haha! 😛 Nu börjar det ju bli bra här...

Men summerar du och sen klipper ner till 16 bitar så förändrar du ju absolut ingenting, och då behövs ingen dither.

[MusicGene]

sluta upp med det där klippande-snacket nu innan jag blir galen.

om ett ljudprogram använder 32-bitars upplösning internt konverteras alla 16-bitarsljud till 32-bitar (genom att lägga på 16 nollor troligtvis). Sen om ditt ljudkort bara kan spela upp 16 bitar så klipper den av de 16 minst signifikanta bitarna. Har du en dither på före så ser den till att använda informationen i de 16 minst signifikanta bitarna för att förbättra på de 16 mest signifikanta så när ljudprogrammet klipper bort de 16 minst signifikanta har lite av den informationen redan sparats bland de 16 mest signifikanta bitarna och på så vis förbättrat kvaliteten.

My statement stands, använd dither även om du spelat in i 16 bitar.

haha! 🙂 Nu börjar det ju bli bra här...

Men summerar du och sen klipper ner till 16 bitar så förändrar du ju absolut ingenting, och då behövs ingen dither.

Är de två signalerna olika så förändrar du nånting och då hjälper dither.

[joachime]

Jag tror jag förstår Music Gene. Och det är klart att man kan vinna något på att använda dithering trots att man jobbar med 16 bitars upplösning.

Men jag tror ändå att diskussionen är förrvirrande för den som är ny med dither. Jag förslår att man aldrig använder dither vid mixdown, på samm sätt som man aldrig bör använda något annat mastering-tänk vid en mixdown. Lämna allt sånt till masteringssteget istället. Om man misstänker att summan av alla 16-bitars spår är större än - hrmm - 16 bitar, välj i så fall att mixa ned i 24 bitar.

[MusicGene]

jag föreslår att man alltid mixar ner till 24 bitar. När man vill mixa ner till 16 så använder man dither.

[VacUm]

sluta upp med det där klippande-snacket nu innan jag blir galen.

om ett ljudprogram använder 32-bitars upplösning internt konverteras alla 16-bitarsljud till 32-bitar (genom att lägga på 16 nollor troligtvis). Sen om ditt ljudkort bara kan spela upp 16 bitar så klipper den av de 16 minst signifikanta bitarna. Har du en dither på före så ser den till att använda informationen i de 16 minst signifikanta bitarna för att förbättra på de 16 mest signifikanta så när ljudprogrammet klipper bort de 16 minst signifikanta har lite av den informationen redan sparats bland de 16 mest signifikanta bitarna och på så vis förbättrat kvaliteten.

My statement stands, använd dither även om du spelat in i 16 bitar.

haha! 😱 Nu börjar det ju bli bra här...

Men summerar du och sen klipper ner till 16 bitar så förändrar du ju absolut ingenting, och då behövs ingen dither.

Är de två signalerna olika så förändrar du nånting och då hjälper dither.

Okej, matte-exempel:

Du har två 3-bitarsljud som ska beräknas inuti en motor som räknar i 8 bitar:

Exempel 1:

Du har en sample med värdet 7. Du adderar en sample med värdet 4 och få då värdet 11. (detta sker i motorn som räknar med låt oss säga 8 bitar)

Du ska klippa ner till 3 bitar.

Maxvärdet är då 7 och det klipper. (precis som när man stoppar in 2 normaliserade 16-bitarsljud i en 32-bitars engine)

Exempel 2:

Du har en sample med värdet 2 och en med värdet 3. Adderar du dessa i motorn får du värdet 5. Även om motorns beräkning använder sig av 64 bitar så blir ju värdet aldrig större än 5 och det spelar ingen roll om du konverterar ner till 3 bitar. Värdet är ändå exakt samma. Därför behövs ingen dithering.

[MusicGene]

inget mer klippande sa jag ju! 😱

😱

[joachime]

Skillnaden är att i det första fallet kommer du att sänka ljudnivån (eftersom du inte vill att det ska klippa). Vilket antagligen leder till kvantiseringsfel någonstans erfter tidsaxeln (förutsatt att ljudsignalerna modulerar).

Edit: Vilket kan motverkas med dither, som MusicGene skriver.

Redigerat 22 september 2005 av joachime

[VacUm]

Skillnaden är att i det första fallet kommer du att sänka ljudnivån (eftersom du inte vill att det ska klippa). Vilket antagligen leder till kvantiseringsfel någonstans erfter tidsaxeln (förutsatt att ljudsignalerna modulerar).

Edit: Vilket kan motverkas med dither, som MusicGene skriver.

Det hjälper inte en endaste gnutta om jag slänger på en dither på utgången eftersom modulationen sker innan.

[joachime]

Edit: Vilket kan motverkas med dither, som MusicGene skriver.

Det hjälper inte en endaste gnutta om jag slänger på en dither på utgången eftersom modulationen sker innan.

ÄR du säker på att alla extra bitar adderas i toppen? Det rimliga vore att man jobbar med ljudfilernas faktiska bitar centrerat. Typ såhär:

16 bitars ljudfil:

xxxxxxxxxxxxxxxx

32 bitars intern signalhantering:

00000000000000000000000000000000

16 bitars ljudfil i 32 bitars signalhantering:

00000000xxxxxxxxxxxxxxxx00000000

På det sättet kan du göra stora justeringar i dynamiken utan att introducera kvantiseringsfel internt i programmet, och samtidgit ha tokigt mycket headroom.

[VacUm]

Edit: Vilket kan motverkas med dither, som MusicGene skriver.

Det hjälper inte en endaste gnutta om jag slänger på en dither på utgången eftersom modulationen sker innan.

ÄR du säker på att alla extra bitar adderas i toppen? Det rimliga vore att man jobbar med ljudfilernas faktiska bitar centrerat. Typ såhär:

16 bitars ljudfil:

xxxxxxxxxxxxxxxx

32 bitars intern signalhantering:

00000000000000000000000000000000

16 bitars ljudfil i 32 bitars signalhantering:

00000000xxxxxxxxxxxxxxxx00000000

På det sättet kan du göra stora justeringar i dynamiken utan att introducera kvantiseringsfel internt i programmet, och samtidgit ha tokigt mycket headroom.

Jag är inte säker på nånting.

Vad menar du med kvantiseringsfel egentligen? Enligt min tes gör man ju aldrig nån egentlig konvertering mellan bitdjupen utan bara låter 16-bitstalet funka som ett 32bitarstal en sväng innan man kapar dom 16 höga bitarna. Skulle 32bitarstalet i slutändan (efter effekter, routing, summering osv) överstiga maxvärdet för ett 16-bitarstal (som ligger ungefär vid 65000 men minns inte exakt) så klipper det på utgången. Aldrig innan.

En _helt_ annan sak uppstår när man spelar in i t ex 24 bitar och bouncar i 16 då 0db ska motsvara maxvärdet i 24 bitar på ingången resp maxvärdet på 16 bitar på utgången. Då sker en matematisk omräkning där kvantiseringsfel uppstår och man behöver Dither.

[joachime]

Vad menar du med kvantiseringsfel egentligen? Enligt min tes gör man ju aldrig nån egentlig konvertering mellan bitdjupen utan bara låter 16-bitstalet funka som ett 32bitarstal en sväng innan man kapar dom 16 höga bitarna.

Jag menar att du kommer att sänka nivåerna för att undvika att det klipper.

Det innebär att du minskar dynamiken med ett visst antal db (eller bitar om man nu kan säga så). Det kommer då att uppstå kvantiseringsfel eftersom det summerade materialet ursprungligen innehåller högre bitdjup än du återger det med.

[VacUm]

Vad menar du med kvantiseringsfel egentligen? Enligt min tes gör man ju aldrig nån egentlig konvertering mellan bitdjupen utan bara låter 16-bitstalet funka som ett 32bitarstal en sväng innan man kapar dom 16 höga bitarna.

Jag menar att du kommer att sänka nivåerna för att undvika att det klipper.

Det innebär att du minskar dynamiken med ett visst antal db (eller bitar om man nu kan säga så). Det kommer då att uppstå kvantiseringsfel eftersom det summerade materialet ursprungligen innehåller högre bitdjup än du återger det med.

Nädå. Du sänker ju volymen så den "passar in" i 16bitars bitdjupet. Det sker ingen konvertering mellan bitdjup. Där är skillnaden.

Dom avrundningsfelen som uppstår vid volymändring sköter motorn såklart. Det kan man inte påverka med en dither som plugin.

Det enda som kan bli fel vid en multiplicering av samplevärdet är sista 1an eller 0an och det är ju inte mycket att göra åt liksom. Motorn ser till att den blir avrundad rätt. Men så är det ju alltid! När du spelar in analogt ljud till digitalt så avrundas givetvis sista biten.

[joachime]

Dom avrundningsfelen som uppstår vid volymändring sköter motorn såklart. Det kan man inte påverka med en dither som plugin.

Jag håller med dig här. Och jag menar att motorn sköter det genom att använda en del av de "extra" bitarna under ljudfilens bitdjup.

En 4-bitars ljudfil i en 8-bitars ljudmotor:

00xxxx00

kan i ett sånt exempel bli till:

0xxxx000

utan kvantiseringsfel.

[trombonisten]

Grabbar, ta det nu lugnt. Det är många halvförstådda saker här som gör att det blir märkliga diskussioner. Låt nu farbror trombonisten reda ut saker lite så klarnar det säkert.

Innan allting annat, så börja med att lyssna. Hör du ingen skillnad med eller utan dithering så spelar det ju ingen roll. Om någon annan hör skillnad, så låt han eller hon göra som han vill.

Om du tar en 16 bitars inspelning så är den kodad som ett tal, mellan -1 och +1 (eller inte riktigt, riktigt ända fram till ettan faktiskt). Så en 16 bitars inspelning, ett enda sample kan se ut som 0,12435.

Om du i stället har en 24 bitars inspelning så är skillnaden att det kommer fler siffror efter kommatecknet. Det kan till exempel vara 0,12434932 i stället för exakt samma sample. Lite fler siffror alltså, eller högre noggrannhet.

Så självklart är 24 bitar bättre än 16 säger nån då. Nja, kanske. Men vem bryr sig om du har 39.2345 graders feber eller bara 39,2 grader. Feber är det ju ändå. På nåt sätt finns det oftast en gräns när ytterligare noggrannhet inte tillför nåt. Så är det med ljud också. Det diskuteras en hel var den gränsen ligger, men om du frågar mig så är det nånstans kring 20 bitar. Mer än så är rätt meningslöst tycker jag. Nå, eftersom 24 är lite till så kan det väl inte skada.

Om vi nu skulle göra om en 24 bitars inspelning, en sample i taget till 16 bitar så är naturligtsvis det enklaste sättet att bara sudda ut dem sista siffrorna, alltså inte ens runda av ordentligt. Lite bättre blir det om man rundar av förstås, och det gör nog alla bra program.

Sådär räknar datorn på varenda sample som musiken består av. Vanligen är det 44100 sample varje sekund, men det är en baggis för en dator.

Klart inga problem.

Nja, nu är det så att några grabbar med riktigt bra öron kom på att just när man lyssnar på 16 bitar så uppstår det ett slags "frasande ljud" (en del beskriver det annorlunda). Och har man himla känsliga öron så kan det hända att man störs av det. Efter många doktorsavhandlingar kom man på att det hjälper inte att ändra hur man räknar, det är inte därför problemet uppstår. Det är i stället någon som kallas för kvantiseringsbrus, och hur man än trixar så finns det där. Och våra öron är rätt känsliga för just sånt brus. Men då kom de här grabbarna på att man kan liksom måla över skiten så att den inte syns så mycket (förlåt inte hörs så mycket). Och vips hade man hittat på en särskild färg som våra öron tycker hyfsat bra om som kallas för dithering. Kan man inte lösa problemet får man måla över det.

Det det hela handlar om är alltså att kvantiseringsbrus alltid uppstår när man jobbar med digitala saker. Redan när du spelar in allra första gången uppstår det. Det finns alltså redan i din första 16 bitars eller 24 bitars inspelning. Det finns med hela vägen i datorn oavsett vad du gör för nåt.

Men nu kommer vi till en av de stora finesserna med 24 bitars inspelning, det här kvantiseringsbruset ligger ändå bara i de där sista siffrorna längst bort till höger bortanför kommatecknet. Och där hörs dem inte. Men jobbar du med 16 bitar, så ligger de precis tillräckligt nära för att de som har känsliga öron kan höra det. Men det hörs inte i vanliga mp3-spelaren, du behöver jobba med 16bitars filen i riktiga lurar eller högtalare för att kunna upptäcka det. Nå, stör det inte dig så varför bry sig.

Nu är det också så att om man målar över skiten flera gånger, förlåt använder dither flera gånger, så blir det till slut fult av bara det. Det är orsaken till att alla säger att man bara skall använda det som en allra sista åtgärd.

Det var dither det. Måla över det värsta så det inte stör är liksom iden.

Funkade förklaringen?

G.

[VacUm]

Om du tar en 16 bitars inspelning så är den kodad som ett tal, mellan -1 och +1 (eller inte riktigt, riktigt ända fram till ettan faktiskt). Så en 16 bitars inspelning, ett enda sample kan se ut som 0,12435.

Om du i stället har en 24 bitars inspelning så är skillnaden att det kommer fler siffror efter kommatecknet. Det kan till exempel vara 0,12434932 i stället för exakt samma sample. Lite fler siffror alltså, eller högre noggrannhet.

Detdär beror helt på hur man ser på det. Ett binärt tal kan inte innehålla decimaler om man räknar bort 32bit FP som är nån sorts 24bitstal med en 8bitars "carrier" som lägger till decimaler på tal som hamnar under den 24:e biten. (iaf som jag fått det förklarat).

Fast samtidigt ska detta räknas om i dB och då anger man givetvis i siffror mellan -1 och 1 precis som inom mycket annan matte eftersom man då får ut en faktor.

Annars bra inlägg som vanligt.

[MusicGene]

joachime och jag snackar om samma sak. Det gör inte du VacUm. Du fortsätter envist med klippnings-snacket som du borde lagt av med för länge sen 😄

Tänk såhär. Du har en 16bitssampling med full dynamik (0dB). Du halverar volymen och sparar om den som en ny 16-bitssampling. Den nya 16-bitssamplingen höjer du sedan volymen på till det dubbla så att maxamplituden blir 0dB igen. Är du med på att den filen kommer låta sämre? Den hade låtit bättre om du använt en ljudmotor med högre upplösning än 16 bitar och använt dither när du sparade den. Sug på den.

[VacUm]

joachime och jag snackar om samma sak. Det gör inte du VacUm. Du fortsätter envist med klippnings-snacket som du borde lagt av med för länge sen 🙂

Tänk såhär. Du har en 16bitssampling med full dynamik (0dB). Du halverar volymen och sparar om den som en ny 16-bitssampling. Den nya 16-bitssamplingen höjer du sedan volymen på till det dubbla så att maxamplituden blir 0dB igen. Är du med på att den filen kommer låta sämre? Den hade låtit bättre om du använt en ljudmotor med högre upplösning än 16 bitar och använt dither när du sparade den. Sug på den.

haha!

Jag är med. Men du är inte med på mitt resonemang och du vet uppenbarligen inte hur det binära talsystemet är uppbyggt.

Tänk såhär:

Du har två maxade 16bitarsljud och ska få ut dom summerade som ett 16bitarsljud.

Hur du än vrider och vänder på det så _måste_ volymen halveras på båda ljuden. Annars kommer det vara omöjligt att få ett resultat i 16 bitar utan att det klipper 🙁

Men vi återgår till ditt exempel. Låt oss säga att vi har ett ljud på 16 bitar som vi ska halvera volymen på. Det enda som egentligen görs är att vi delar alla värden på två (eller multiplicerar med 0.5). Vad som kan hända nu är att sista biten _kan_ bli felberäknad. Eftersom resultatet kan bli ojämnt så tvingas vi avrunda till något vi tycker är lämpligt. Detta sköter givetvis audiomotorn åt oss. Hade vi haft en motor i en högre bitrate hade vi likt förbannat varit tvunga att avrunda den lägsta biten i 16bitstalet eftersom resultatet bli ojämt, och att avrunda är inga problem i något av fallen eftersom det sköter nog alla CPU's som kan köra windows95 och senare.

Även om du nu skulle ha en motor i 128 bitar skulle vi i slutändan få exakt samma värde ut i 16 bitar, så jag undrar vad poängen med en ljudmotor med högre upplösning har för poäng i just detta sammanhanget?

edit: detta resonemang bygger alltså på min tidigare idé om att ljudet summeras upp i högre bitrates i motorn (som jag inte alls är säker på om det verkligen är så det går till). Skulle ljudet moduleras upp i högre bitrate genom multiplicering och sen tillbaka genom dividering faller givetvis min teori här.

Redigerat 22 september 2005 av VacUm

[joachime]

joachime och jag snackar om samma sak. Det gör inte du VacUm.

Låt oss säga att vi har ett ljud på 16 bitar som vi ska halvera volymen på. Det enda som egentligen görs är att vi delar alla värden på två (eller multiplicerar med 0.5). Vad som kan hända nu är att sista biten _kan_ bli felberäknad. Eftersom resultatet kan bli ojämnt så tvingas vi avrunda till något vi tycker är lämpligt. Detta sköter givetvis audiomotorn åt oss. Hade vi haft en motor i en högre bitrate hade vi likt förbannat varit tvunga att avrunda den lägsta biten i 16bitstalet eftersom resultatet bli ojämt, och att avrunda är inga problem i något av fallen eftersom det sköter nog alla CPU's som kan köra windows95 och senare.

Jag börjar bli osäker på om någon av oss pratar om exakt samma sak. 🙂

Så här tänker jag iaf. Vi antar att vi har en en 16-bitars ljudfil och en host som jobbar med 32 bitar internt. Sänker jag ljudnivån på ljudfilen kommer ingen avrudning att ske eftersom de åtta bitar som ligger bakom ljudfilens 16-bitars upplösning tar hand om "decimalerna". Så här:

Ursprunglig ljudfil i host:

00000000xxxxxxxxxxxxxxxx00000000

Ett exempel på ljudfil i host efter nivåjustering:

0000000xxxxxxxxxxxxxxxx000000000

Vad jag däremot är osäker på är vad som händer med en 24-bitars ljudfil i samma scenarion:

24-bitars ljudfil i 32-bitars host:

xxxxxxxxxxxxxxxxxxxxxxxx00000000

Ett exempel på samma fil efter nivåjustering (?):

xxxxxxxxxxxxxxxxxxxxxxx000000000

Här uppstår väl ett kvantiserings(trunkerings)fel? Ett mycket litet, knappast hörbart, men ändå... 🙁

[hegobald]

Fanken.. Man kan inte ens vända ryggen till ett par timmar så blir det världens tjottablaj på forumet.. 🙂

Regel numero ono för en ljudtekniker. Använd örona 🙁

Labba och test och avgör själv.!

Självklart använder jag ALLTID dithering då jag går ner i bitantal.. En fråga som dock kan vara berättigad som inte jag förstår ännu.. Hur fanken hanterar Cubase,Logic etc.. detta internt i så gott som realtid??? I Cubase sker ju all intern beräkning i 32 bitar så?

[VacUm]

joachime och jag snackar om samma sak. Det gör inte du VacUm.

Låt oss säga att vi har ett ljud på 16 bitar som vi ska halvera volymen på. Det enda som egentligen görs är att vi delar alla värden på två (eller multiplicerar med 0.5). Vad som kan hända nu är att sista biten _kan_ bli felberäknad. Eftersom resultatet kan bli ojämnt så tvingas vi avrunda till något vi tycker är lämpligt. Detta sköter givetvis audiomotorn åt oss. Hade vi haft en motor i en högre bitrate hade vi likt förbannat varit tvunga att avrunda den lägsta biten i 16bitstalet eftersom resultatet bli ojämt, och att avrunda är inga problem i något av fallen eftersom det sköter nog alla CPU's som kan köra windows95 och senare.

Jag börjar bli osäker på om någon av oss pratar om exakt samma sak. 🙂

Så här tänker jag iaf. Vi antar att vi har en en 16-bitars ljudfil och en host som jobbar med 32 bitar internt. Sänker jag ljudnivån på ljudfilen kommer ingen avrudning att ske eftersom de åtta bitar som ligger bakom ljudfilens 16-bitars upplösning tar hand om "decimalerna". Så här:

Ursprunglig ljudfil i host:

00000000xxxxxxxxxxxxxxxx00000000

Ett exempel på ljudfil i host efter nivåjustering:

0000000xxxxxxxxxxxxxxxx000000000

Vad jag däremot är osäker på är vad som händer med en 24-bitars ljudfil i samma scenarion:

24-bitars ljudfil i 32-bitars host:

xxxxxxxxxxxxxxxxxxxxxxxx00000000

Ett exempel på samma fil efter nivåjustering (?):

xxxxxxxxxxxxxxxxxxxxxxx000000000

Här uppstår väl ett kvantiserings(trunkerings)fel? Ett mycket litet, knappast hörbart, men ändå... 🙁

nä jag tänker inte så. 😄

Men du kan ha rätt.. Fast du ritar upp dina binära tal baklänges så jag blir helt snurrig 😄 Lägsta biten ska va till höger.

Men det smartaste borde väl i så fall att expandera ut 16bitarstalet till ett 32bitars. Funkar en ljudmotor på det viset så borde man ju dock alltid köra dithering om man använder sig av 16 bitar.

Å andra sidan jobbar väl nästan alla engines med 32bit FP nu som jag fattat det och då får du ju dina gratisdecimaler på köpet.

[VacUm]

Regel numero ono för en ljudtekniker. Använd örona 🙂

Labba och test och avgör själv.!

Tyst med dej! 🙁 Nu pratar vi ju inte musik. Inte jag iaf. Nu är jag datornörd.

[joachime]

Regel numero ono för en ljudtekniker. Använd örona 🙂

Labba och test och avgör själv.!

Tyst med dej! 😄 Nu pratar vi ju inte musik. Inte jag iaf. Nu är jag datornörd.

Håller med dig, i den här diskussionen har vi lagt av oss musiktitlarna! 🙁

Och ursäkta att jag skriver binära tal baklänges. Jag är så gott som självlärd på området. Har skrivit åt det hållet ända sedan jag satt och plottrade sprite-matriser till Commodore 64. 😄

[VacUm]

Regel numero ono för en ljudtekniker. Använd örona 🙂

Labba och test och avgör själv.!

Tyst med dej! 😄 Nu pratar vi ju inte musik. Inte jag iaf. Nu är jag datornörd.

Håller med dig, i den här diskussionen har vi lagt av oss musiktitlarna! 🙁

Och ursäkta att jag skriver binära tal baklänges. Jag är så gott som självlärd på området. Har skrivit åt det hållet ända sedan jag satt och plottrade sprite-matriser till Commodore 64. 😄

Då är det ju ingen sport att skapa sprites. Dom skriver man i hex!

[joachime]

Men det smartaste borde väl i så fall att expandera ut 16bitarstalet till ett 32bitars. Funkar en ljudmotor på det viset så borde man ju dock alltid köra dithering om man använder sig av 16 bitar.

Å andra sidan jobbar väl nästan alla engines med 32bit FP nu som jag fattat det och då får du ju dina gratisdecimaler på köpet.

Ja du har nog rätt. Det är bara det att jag aldrig förstått hur FP fungerar teoretiskt.

Men om vi säger så här då, rent generellt. Det interna bitdjupet används för att bibehålla ljudfilens upplösning oavsett om nivåerna hamnar under ljudfilens ursprungliga upplösning eller över det maximala utslaget (dvs headroom).

Och för att svara på din fråga, ja eftersom många pluggar arbetar på ännu högre bitdjup än så (t ex 48 bitar) kan det i sin tur introducera kvantiseringsfel trots värdprogrammets 32 bitar FP.

Edit: ändrade lite

Edit 2:

Då är det ju ingen sport att skapa sprites. Dom skriver man i hex!

Jag kom aldrig så långt... 🙂 Redigerat 22 september 2005 av joachime

[MusicGene]

Men för böfvelen. Jag vet väl hur binära talsystem funkar.

Jag fattar väl att det klipper, det har jag skrivit hela tiden men det är inte det det här handlar om.

Det handlar om att två maxade 16-bitarsljud måste representeras av 17 bitar för att information inte skall gå förlorad. Det var det jag sa från början. Och du som är professor i binära talsystemet håller säkert med.

Dithering använder den 17:e biten för att göra en konvertering till 16 bitar så bra som möjligt. Svårare än så är det inte 🙂

*pust* Det var länge sen jag pladdrade så här mycket på forumet! 😉

PS. Hoppas jag inte är påverkad av min starka penicillinkur jag trycker i mig. Då blir det pinsamt DS

[VacUm]

Men för böfvelen. Jag vet väl hur binära talsystem funkar.

Jag fattar väl att det klipper, det har jag skrivit hela tiden men det är inte det det här handlar om.

Det handlar om att två maxade 16-bitarsljud måste representeras av 17 bitar för att information inte skall gå förlorad. Det var det jag sa från början. Och du som är professor i binära talsystemet håller säkert med.

Dithering använder den 17:e biten för att göra en konvertering till 16 bitar så bra som möjligt. Svårare än så är det inte 🙂

*pust* Det var länge sen jag pladdrade så här mycket på forumet! 😉

PS. Hoppas jag inte är påverkad av min starka penicillinkur jag trycker i mig. Då blir det pinsamt DS

lol!

Ja jag är med. Men i så fall bör man ju ha på dithering även om man både spelar in och bouncar i 16 bitar eftersom motorn jobbar i 32bit FP. Angående detta har jag hört två professionella mastringstekniker komma med helt motstridiga uppgifter. Den ena menar att det inte behövs dither om man kör 16 bitar på båda sidor medan den andra hävdar att man alltid ska ha dither på.

Jag har sabbat tråden lite, jag erkänner. Förlåt för det, men jag skulle vilja se algoritmerna till någon av dom större ljudmotorerna som finns. Vad jag förstår så har egentligen ingen av oss nån aning om hur ljudet hanteras mellan in och ut och då är det svårt att vara säker på nånting.

[Killercat]

den här tråden är ju underbar.

tänkte på en sak.

när jag sitter och mixar sent på natten och mina ögon klipper - då fixar jag det med 16 bitar i kaffet.

är det ungefär det ni snackar om här...?

[VacUm]

den här tråden är ju underbar.

tänkte på en sak.

när jag sitter och mixar sent på natten och mina ögon klipper - då fixar jag det med 16 bitar i kaffet.

är det ungefär det ni snackar om här...?

yes! Du verkar ha löst rubbet. Fasen nu blev jag kaffesugen också.

[joachime]

Hittade en artikel som går igenom hur 32 bitar FP fungerar. Även en liten hint om hur de binära talen förhåller sig till -1 < n < 1.

32-Bit DSP: A Digital Radio Performance Advantage?