- 第 4 页 -
本帖最后由 elunxp 于 15-9-21 16:59 编辑
我在楼主的另一帖回复了，不过发现回在这贴比较好：
实际上这个帖子涉及了三个完全不同类型的问题：
（一）建立和输出文件的采样位深精度（如：24bit定点WAV、32Bit浮点WAV等）
（二）音频工作站内部运算处理的位深精度（如：Internal Processing 64bit浮点处理等）
（三）程序架构（如：x86和x64）
三种情况，大多数人都非常容易把概念混淆。
无论是x86还是x64的软件，都可能存在Internal Processing是64Bit或者32bit的情况，举例：
SawStudio 是x86（32位）软件，但是它的Internal Processing内部精度是64Bit整数运算；
Cubase Pro 8的x64（64位）的版本，它Internal Processing内部精度是32Bit浮点运算；
Reaper，无论是x86还是x64版本，它们Internal Processing内部精度都是64Bit浮点运算。
上面提到的软件，无论何种架构（不管是x86还是x64），无论何种内部精度（Internal Processing），都可以选择导出不同规格的音频文件，比如24Bit定点的WAV，32Bit浮点的WAV等。
程序架构中只会影响执行效率和内存寻址等因素，比如x64的工作站在x64的处理器下运算有更高的执行效率和更大的内存寻址范围，这些和工作站内部处理精度无关，也和输入输出文件精度无关。
软件内部处理精度（Internal Processing），直接决定母线处理的动态范围承受能力，并且直接决定多轨混音的处理精度，同时也会影响summimg运算品质，尤其是音轨数非常多的时候，高内部精度的优势会更明显。
音频文件的创建和输出采样位深精度，会影响音频文件所存储数据的动态范围，可以简单的理解为一个容器。比如24bit定点的音频文件，可以存储大约144dB的动态范围音频信号，并且整数型（定点）不具备动态可编辑性。但如果以32Bit浮点存储音频文件，则可以在1680dB范围内具备可编辑性和无缝转换性。比方说，你导出一个32bit音频数据文件，峰值是0dB，然后拿到别的软件导入，向上拉推子提升6dB音量，也就是过载了6dB，接着你再保存这个过载的浮点文件。你再把这个过载的浮点文件导入到原来的音频软件，听到是过载的，然后你拉下推子6dB还原到0dB的位置，发现又不过载了，可以无缝还原。如果你换成24Bit定点文件存储，重复做上面的事情，发现是不可行的。
注意，VST插件也分x86和x64，同时VST插件也存在不同的内部精度Internal Processing。举例：
Sonoris的VST插件是x86（32位）的，但是它的内部精度Internal Processing却是64Bit定点运算。
WAVES的VST/AAX插件，有x86（32位）也有x64（64位）的，而里面的不同效果器产品内部处理精度Internal Processing是不同的，比如C4多段动态处理器（无论是x86还是x64版本），它的内部处理精度Internal Processing均为48Bit浮点运算。但是某些签名版的插件，比如Abbey Road那些（无论是x86还是x64）似乎又提高到了64Bit浮点运算。
x86（32位）的VST效果器，可以在x64（64位）下的音频工作站宿主中桥接使用，但是内部处理精度Internal Processing是不变的，而变化的只有CPU执行效率和内存寻址范围（也就是程序架构的不同）。你可以大概理解为：32位的插件在64位的宿主下使用，音质精度不会变差，但是CPU和内存执行的效率可能会变差（如跑不动了）。
是不是我越扯越乱了？
我在楼主的另一帖回复了，不过发现回在这贴比较好：
实际上这个帖子涉及了三个完全不同类型的问题：
（一）建立和输出文件的采样位深精度（如：24bit定点WAV、32Bit浮点WAV等）
（二）音频工作站内部运算处理的位深精度（如：Internal Processing 64bit浮点处理等）
（三）程序架构（如：x86和x64）
三种情况，大多数人都非常容易把概念混淆。
无论是x86还是x64的软件，都可能存在Internal Processing是64Bit或者32bit的情况，举例：
SawStudio 是x86（32位）软件，但是它的Internal Processing内部精度是64Bit整数运算；
Cubase Pro 8的x64（64位）的版本，它Internal Processing内部精度是32Bit浮点运算；
Reaper，无论是x86还是x64版本，它们Internal Processing内部精度都是64Bit浮点运算。
上面提到的软件，无论何种架构（不管是x86还是x64），无论何种内部精度（Internal Processing），都可以选择导出不同规格的音频文件，比如24Bit定点的WAV，32Bit浮点的WAV等。
程序架构中只会影响执行效率和内存寻址等因素，比如x64的工作站在x64的处理器下运算有更高的执行效率和更大的内存寻址范围，这些和工作站内部处理精度无关，也和输入输出文件精度无关。
软件内部处理精度（Internal Processing），直接决定母线处理的动态范围承受能力，并且直接决定多轨混音的处理精度，同时也会影响summimg运算品质，尤其是音轨数非常多的时候，高内部精度的优势会更明显。
音频文件的创建和输出采样位深精度，会影响音频文件所存储数据的动态范围，可以简单的理解为一个容器。比如24bit定点的音频文件，可以存储大约144dB的动态范围音频信号，并且整数型（定点）不具备动态可编辑性。但如果以32Bit浮点存储音频文件，则可以在1680dB范围内具备可编辑性和无缝转换性。比方说，你导出一个32bit音频数据文件，峰值是0dB，然后拿到别的软件导入，向上拉推子提升6dB音量，也就是过载了6dB，接着你再保存这个过载的浮点文件。你再把这个过载的浮点文件导入到原来的音频软件，听到是过载的，然后你拉下推子6dB还原到0dB的位置，发现又不过载了，可以无缝还原。如果你换成24Bit定点文件存储，重复做上面的事情，发现是不可行的。
注意，VST插件也分x86和x64，同时VST插件也存在不同的内部精度Internal Processing。举例：
Sonoris的VST插件是x86（32位）的，但是它的内部精度Internal Processing却是64Bit定点运算。
WAVES的VST/AAX插件，有x86（32位）也有x64（64位）的，而里面的不同效果器产品内部处理精度Internal Processing是不同的，比如C4多段动态处理器（无论是x86还是x64版本），它的内部处理精度Internal Processing均为48Bit浮点运算。但是某些签名版的插件，比如Abbey Road那些（无论是x86还是x64）似乎又提高到了64Bit浮点运算。
x86（32位）的VST效果器，可以在x64（64位）下的音频工作站宿主中桥接使用，但是内部处理精度Internal Processing是不变的，而变化的只有CPU执行效率和内存寻址范围（也就是程序架构的不同）。你可以大概理解为：32位的插件在64位的宿主下使用，音质精度不会变差，但是CPU和内存执行的效率可能会变差（如跑不动了）。
是不是我越扯越乱了？
本帖最后由 wstsw888 于 15-9-21 19:44 编辑
那就是说插件的处理精度是不会因为是32位（x86）插件或64位（x64）插件而改变的，如果是这样的话，那这一点上，我原来的理解确实错了！
elunxp 发表于 15-9-21 16:50
我在楼主的另一帖回复了，不过发现回在这贴比较好：
那就是说插件的处理精度是不会因为是32位（x86）插件或64位（x64）插件而改变的，如果是这样的话，那这一点上，我原来的理解确实错了！
kang 发表于 15-9-22 05:06
谢谢elunxp大大的详细讲解，那么请问在目前情况下，多轨混音文件精度是设置成24bit的还是32bit的好呢？目前 ...
我10楼的帖子你可以先参考下。
我在知乎找到这么一段：
目前最理想的解决方案就是使用32位浮点运算格式的音频格式(最先由SonicFoundry制定). 这种格式并不是说采样是32位的, 而是指内部运算是32位浮点的. 这种格式可以完美记录下任何一个采样点, 一旦CLIP也不做任何削波处理, 而是记录下CLIP数据在0dB以上的真实情况并且保留下来.
- 尽管32位浮点运算格式的音频数据在电平大于0dB时候也会显示Clip. 但此时仅仅是提醒你有波形大于0dB了. 由于多数情况下我们不会将32位浮点运算格式的音频数据做为最终产品, 所以clip问题总是要解决的. 由于0dB以上的采样点没有被破坏, 所以只要简单地使用压缩,EQ等简单手段就可以保证最终产品不会有clip.
- 32位浮点运算格式的音频数据,其真实采样深度由你的硬件设置决定的!!!!!!! 所以它并不会象24bit录音那样得到比16bit录音更好的质量.
- 32位浮点运算格式的音频数据会要求更多硬盘空间
目前最理想的解决方案就是使用32位浮点运算格式的音频格式(最先由SonicFoundry制定). 这种格式并不是说采样是32位的, 而是指内部运算是32位浮点的. 这种格式可以完美记录下任何一个采样点, 一旦CLIP也不做任何削波处理, 而是记录下CLIP数据在0dB以上的真实情况并且保留下来.
- 尽管32位浮点运算格式的音频数据在电平大于0dB时候也会显示Clip. 但此时仅仅是提醒你有波形大于0dB了. 由于多数情况下我们不会将32位浮点运算格式的音频数据做为最终产品, 所以clip问题总是要解决的. 由于0dB以上的采样点没有被破坏, 所以只要简单地使用压缩,EQ等简单手段就可以保证最终产品不会有clip.
- 32位浮点运算格式的音频数据,其真实采样深度由你的硬件设置决定的!!!!!!! 所以它并不会象24bit录音那样得到比16bit录音更好的质量.
- 32位浮点运算格式的音频数据会要求更多硬盘空间
本帖最后由 wstsw888 于 15-9-23 22:44 编辑
我是在群里聊天，看他们有时会说PT音质好，那我就想可能是PT的处理精度都是一致的，所以说音质好，比如可能PT是48bit处理精度，然后插件也是48bit处理精度，（但是我也不确定，因为不太了解PT，而且PT的音质可能也与处理精度无关），但由此想到如果建立工程时的音频文件精度也高，宿主的处理精度也高，插件的处理精度也高，而且都一致，是不是处理中的失真就会更少了呢，因为不是有个木桶效应吗！木桶定律是讲一只水桶能装多少水取决于它最短的那块木板。比如你宿主和插件的处理精度都是64位，然后你桥接一个很低的处理精度的插件，是不是整体的处理精度就下降了！我知道32位插件和64位插件与他们的处理精度不相关，但是以为通常32位插件就是32位的处理精度，64位插件就是64位的处理精度，所以这一点弄错了！
我研究的也不专业，表述的也不专业，所以可能有很多人没看明白！
但并不是说要导出64bit的音频文件。只是说，处理过程中误差更少，最后导出16bit文件不也是更好吗！
aswhl 发表于 15-9-23 13:03
额，楼主想表达的我基本是看懂了，不过目前真正导出为64bit精度的音频我只见过一次，通常来说，目前流通的 ...
我是在群里聊天，看他们有时会说PT音质好，那我就想可能是PT的处理精度都是一致的，所以说音质好，比如可能PT是48bit处理精度，然后插件也是48bit处理精度，（但是我也不确定，因为不太了解PT，而且PT的音质可能也与处理精度无关），但由此想到如果建立工程时的音频文件精度也高，宿主的处理精度也高，插件的处理精度也高，而且都一致，是不是处理中的失真就会更少了呢，因为不是有个木桶效应吗！木桶定律是讲一只水桶能装多少水取决于它最短的那块木板。比如你宿主和插件的处理精度都是64位，然后你桥接一个很低的处理精度的插件，是不是整体的处理精度就下降了！我知道32位插件和64位插件与他们的处理精度不相关，但是以为通常32位插件就是32位的处理精度，64位插件就是64位的处理精度，所以这一点弄错了！
我研究的也不专业，表述的也不专业，所以可能有很多人没看明白！
但并不是说要导出64bit的音频文件。只是说，处理过程中误差更少，最后导出16bit文件不也是更好吗！
wstsw888 发表于 15-9-23 13:39
我是在群里聊天，看他们有时会说PT音质好，那我就想可能是PT的处理精度都是一致的，所以说音质好，比如可 ...
关于PT并不是因为精度高，而是因为算法好，所以音频在最后导出的时候损失最少，与处理精度的关系不大，同时并不是说精度越大就越好，相同情况下精度越大对于内存和cpu的占用会暴增，同时文件大小也会成倍递增，最重要的问题是你的源文件，如果你本身的源文件并不能达到这种精度，纯属就是浪费而已，也就是说这种精度只有在一开始就已经达到了足够的位深的情况下才会有考虑精度的必要。举例的话就是，初期录音和初期编曲时音频的精度达到64bit之后的处理才会考虑64bit，然而现在录音一般采用24bit，因为再大的作用不明显，并且在占用过高的情况下会导致不稳定的情况发生，所以够用就好，不要过多追求数据
wstsw888 发表于 15-9-23 13:39
我是在群里聊天，看他们有时会说PT音质好，那我就想可能是PT的处理精度都是一致的，所以说音质好，比如可 ...
而且，在考虑位深的同时，还有采样率，两者都很重要，目前录音影视输出一般为48000，音乐为44100，发烧级是96000，通常声卡支持到192000的采样率，也就是说通常录音采用96000已经足够
aswhl 发表于 15-9-23 14:07
而且，在考虑位深的同时，还有采样率，两者都很重要，目前录音影视输出一般为48000，音乐为44100，发烧级 ...
嗯，我觉得，24bit，32bit，88200hz，96000hz，基本就可以了。