这篇文章对32bit和48bit的对比有严重的误导,目前很多DAW使用的都是32bit浮点型,
动态范围比48bit大10多倍,32bit干不过48bit的真正原因并不因为32<48,而是在于浮点型的数值越大精度越差!
,而且由于使用浮点型的DAW最大可以拥有1000多db的动态,很多人疯狂地加单轨电平,毫不顾忌声音在效果器
里,插件里,mixer里是不是已经红了。虽然浮点型夸张的动态可以保证不劈(其实在非HD的DAW里很明显,明明效果
器或者音源的输出已经红了,可声音却没有劈),但要记得数值越大精度越低,单轨音量巨大而总推子放很小的最终结果就是
一片浑浊。因为你总输出不可能是32bit的,只能是24或者16的。
浮点型的优势在于易于计算和设计程序,你要设计个牛逼的定点100bit效果器?好,首先你在C++里就找不到
100bit的整形,好,你用struct设计一个100bit,那么在发明效果器之前你得定义你这个struct的加减乘除这些最基础的数学运算,定义的好还行,定义不好会大大降低运算效率。不定义也行,您去汇编环境下数01去吧。。好不容易编完了,好!问题又出现了,VST,AU和RTAS的SDK的输入输出借口全部是浮点型的,你怎么把你这个定点性转成浮点型?
效率够不够?是不是得不偿失?这问题解决了,好,算法呢?100bit内你的每个数据应该占多少bit?这不能想当然,一个2000个点的FFT就瞬间让你可怜的100bit数据溢出(fft的每一段相当于把2000个采样点的数值乘以一个系数然后相加)。好,这问题也搞定了,太好了!大功告成了?早着呢!程序界面你做不做?做界面得用个Juce吧(水果,马头,UAD等等公司都用这玩意做界面),好!Juce里的推子,旋钮类的数值统统是浮点型,你发现你再次崩溃。。。。更崩溃的是每家和每家的定点性规则都不同,HD里是这样,在硬件处理器里又是另一样,而浮点都是一样的。
另外文章对抖动的解释也不准确,抖动处理添加的噪音不是为了让声音变得“细节”,
而是用我们假设用10进制来模拟一下高bit转低bit时音频发生的事情,假设我们的数据是5.7,8.9,4.4和3.4,那么
假设我降低了bit,只能记录整数位,我得到的数据就是:5,8,4和3,你会注意到,所有的小数位都被丢弃了,这相当于
计算机在原始信号上叠加了一个:-0.7,-0.9,-0.4,-0.4这一组数据,而所谓量化噪音就是这一组很小的,被丢弃的量
引起的,抖动处理的真正意义在于对这个量化噪音添加一组反向的量化噪音,当然我们不可能知道我们到底丢了什么(如果知道,直接加上就完了),但我们可以设计一个抖动算法让噪音减小,抖动算法很复杂咱们不妨说个最简单的:对原始信号添加一个:1,1,1,1的信号,这样信号会变成:6,9,5,4,这样量化噪音就编程了:-0.3,-0.1,-0.6,-0.6怎么样?噪音比原来小吧?
解答楼主的提问:
1.bit数值所代表的dB值并不是直接对应的。bit值取log*20才是dB值。学过log的都知道线性地*法等于log上的+法,
比如10的dB=log10*20=20,而20的dB=log10*20+log2*20,这个log2*20大概得6,所以,实际上所谓+6dB,意味着
bit值大了一倍,值原来是1.6,那加了6dB则值变为3.2。所以,所谓“1bit=6dB”,并不是说在-10dB和-16dB就不能存在-11dB,-12dB,而是一种计算动态范围的方法,在音频算法的设计里都是不按dB考虑问题的,也就是说
都是把dB转成数再处理的,而不是先把数转成dB再计算。
转成dB计算再转回来播放计算量巨大,当采样率为44100时,等于你让电脑在1秒钟内做44100次取log运算,44100次平方运算。
这只是一条单声道……
举个例子,在32bit浮点型中1是0dB,那么我加0.1db就意味着我要把0.1dB先变为线性值=
1.0011519.....再用1*1.0011519=1.0011519。只要线性精度够,dB的精度也够,换算一下,
分贝变化精度的最小值是:log(realmin+1)*20。其中“realmin”代表着在当前bit率下的非0最小正实数。
定点形较大,浮点型的话……保证够你用。。
[ 本帖最后由 门子 于 10-2-12 01:36 编辑 ]