No .. to je sice pekne co pises .. ale trosku nesuhlasim .. 23bitov je na mantisu .. cize to je nepresnejsie ako 24bit .. totiz ked mas vacsie cislo , tak uz stracas v mantise detail .. to co pises o CD je jasne kazdemu .. pri 24bitoch sa tato vec straca samozrejme ..vras píše:integer cisla jsou dost nevhodna, jednak muzou teoreticky pretect (clipping - zname ze zvukovych karet, ze?) a jednak v pripade malych signalu se ztraci presnost - tj. zkresluji. Dobrym prikladem muze byt CD, kde velmi tiche pianissimo pasaze typicky ve vazne hudbe hraji hrozne, protoze pouzivaji jen par dolnich bitu z celeho 16bitoveho formatu a to uz kvalita dostane citelne zabrat. Oba problemy u floating point cisel odpadaji.zamyslime sa nad 32bit floatom .. neni to nepresnejsie ako 32bit integer ? kolko bitov sa pouzije na mantisu a kolko na exponen
Definice 32-bit "float" : The data type "float" is a 32 bit wide floating point number consisting of a 23 bit mantissa, an 8 bit exponent and a sign bit.
-
jeany_jeany_jeany
- Příspěvky: 139
- Registrován: 15 pro 2008 13:49
No jo, to ale plati akorat v pripade mixdownu, tam 32 bit float vyznam ma, bo se konverzi skutecne vyhnes - teda v pripade ze ten mixdown budes jeste sypat do nejakyho materovaciho programu. Ve finale te ceka konverze stejne...pavlii píše:2vras: napadá mě vlastně jen jedno pozitivum: protože DAW pracuje interně ve 32bit, tak vezmeme-li v úvahu, že máme audio ve 24bit (AD převodník), při práci si to DAW rozšíří na 32bit, zpracuje a zase překonvertuje do 24bit (případně opravte logickou chybu). Pokud nabereš audio 24bit AD převodníkem, ale "nadstavbou" v DAW budeš generovat 32bit soubory, nebudou se výše zmíněné 2 konverze dělat; mohlo by to ssebou nést tím pádem méně zaokrouhlovacích chyb.... To ale byla jen čistě teoreticko-matematická úvaha momentálního osvícení
P.
Ale v pripade nahravani tam ta konverze bude tak jako tak - je jedno budes-li nahravat 24 bit (pak si to engine cubase zkonverti teal-time pri prehravani) nebo budes-li nahravat 32bit (a pak to cubase zase zkonverti real time, ale pri nahravani)
-
jeany_jeany_jeany
- Příspěvky: 139
- Registrován: 15 pro 2008 13:49
Jenze v pripade 32 bit float je signal de fakto rozdelenej na 8 "podurovni" a KAZDA ma 23bit rozliseni, takze je to IMHO daleko presnejsi (hodne zjednoduseny ja vim..) Nehlede nato ze bych chtel videt prevodnik, kterej nestoji majlant a umi s rozumnou presnosti vyuzit vsech 24 bituPytkin píše: No .. to je sice pekne co pises .. ale trosku nesuhlasim .. 23bitov je na mantisu .. cize to je nepresnejsie ako 24bit .. totiz ked mas vacsie cislo , tak uz stracas v mantise detail .. to co pises o CD je jasne kazdemu .. pri 24bitoch sa tato vec straca samozrejme ..
To uz je dost off topic, ale "ztrata" pri prevodu integer 24 do float 32 je rovna presne nule. Pokud to nahodou matematicky neni presne nula, tak ve srovnani s SNR v audio-chainu a chybami ADC je to porad presne nulacize to je nepresnejsie ako 24bit .. totiz ked mas vacsie cislo , tak uz stracas v mantise detail
neni to tak .. mantisa je 24bit .. cize ak je slovo vacsie ako 24bit , tak sa v dolnych radoch straca cislo ..jeany_jeany_jeany píše:Jenze v pripade 32 bit float je signal de fakto rozdelenej na 8 "podurovni" a KAZDA ma 23bit rozliseni, takze je to IMHO daleko presnejsi (hodne zjednoduseny ja vim..) Nehlede nato ze bych chtel videt prevodnik, kterej nestoji majlant a umi s rozumnou presnosti vyuzit vsech 24 bituPytkin píše: No .. to je sice pekne co pises .. ale trosku nesuhlasim .. 23bitov je na mantisu .. cize to je nepresnejsie ako 24bit .. totiz ked mas vacsie cislo , tak uz stracas v mantise detail .. to co pises o CD je jasne kazdemu .. pri 24bitoch sa tato vec straca samozrejme ..
polopate vysvetlene .. dajme tomu ze mame 5 znakovu mantisu a exponente .. kym sme v cisle do 100.000 , tak je vsetko ok
trebars 00969 alebo 99500 .. nic sa nestraca .. dokonca pozitivne je ze pri malych cislach mame vacsiu presnost .. trebars 0.0500 je vlastne 5.00 e-02
Ked ale prejdeme cez 100.000 , tak sa nam straca detail ..
lebo cislo 100.005 sa zapise ako
1.0000 e+5 ... ta 5 na konci sa stratila ..
Z tohto hladiska ked sa na to pozeram , tak 64bitove spracovanie v SONARE ma zmysel ..
Presnost 64-bit v plovouci carce ma opravneny smysl u DSP a pluginu, kde se deji neskutecne kvanta vypoctu a kde by se mohla v dusledku zaokrouhlovani kumulovat chyba. Ale v normalnim DAW je to IMHO spise reklamni tah nez aby to melo realny vyznam, vsak si uvedom ten neskutecny dynamicky rozsah, ktery 32-float ma ve srovani s analogovou cestou.Z tohto hladiska ked sa na to pozeram , tak 64bitove spracovanie v SONARE ma zmysel ..
vras : ale straca sa detail , ako som uz pisal .. nerozumiem naco je dobry dynamicky rozsah .. ked zoberiem 32bit spracovanie integer , tak vypocty su omnoho rychlejsie a cez nulu mozes ist tiez .. samozrejme headroom je maly .. 64bit integer by bol asi lepsi .. a 64bit float v sonare je trosku asi zbytocny ale ten detail sa nestraca ..
Nejlepsi je si to vyzkouset v praxi, pac me to zajimalo, tak jsem za par minut udelal programek, co _vsechna_ cisla v intervalu -8388608 az 8388607 (coz odpovida rozsahu 24-bitoveho audia) prevedl na float_32 a zase zpet na int a porovnal a vysledek? Cely vypocet trval zlomek sekundy, absolutne zadny rozdil, ani v jednom pripade. Nic se nikde neztraci. Proc je tomu tak a ne jinak je jiz otazka na tvurce floating point aritmetiky v procesorech.
Pokud to dobre chapu, pouze jsi ta cisla pretypoval na float a zpatky. To nema s fp aritmetikou v cpu nic spolecnyho, protoze jsi zadny fp operace neprovadel.vras píše:Nejlepsi je si to vyzkouset v praxi, pac me to zajimalo, tak jsem za par minut udelal programek, co _vsechna_ cisla v intervalu -8388608 az 8388607 (coz odpovida rozsahu 24-bitoveho audia) prevedl na float_32 a zase zpet na int a porovnal a vysledek? Cely vypocet trval zlomek sekundy, absolutne zadny rozdil, ani v jednom pripade. Nic se nikde neztraci. Proc je tomu tak a ne jinak je jiz otazka na tvurce floating point aritmetiky v procesorech.
