录音 / 混音

这是很无聊的研究，和各位大神做音乐没什么关系，开口教育的请点x。

之前发了一个帖子http://www.audiobar.cn/forum.php?mod=viewthread&tid=531771关于新开一轨做平行dither的，我认为理论上dither就是叠加被截断位数的随机噪声，可是讨论结果却是从音频波形本身还原度来看，平行dither起到的效果和直接dither并不一样，而且要差一些。这让我很难理解，后来查了很多资料，果然问题不是出在平行dither的操作，而是在于宿主内部进行并轨或者其他运算时对轨道进行了预衰减。
首先必须要先说一下给定bit深度时的二进制数字运算，以24bit举例。
这一部分先说动态范围，24bit深度的动态范围是144db，这是因为电平db值每降低6db，波形点本身数值会变成2分之一，假设最大的波形数值是1的话，最小的波形数值就是2的-24次方。也就是说24bit数字音频只能用24个1或者0的小格子来记录数值。可以认为24bit的数字音频的电平为0，等于波形的数值被记录为二进制的111111111111111111111111（24个1），这个值就是可以记录的最大值。因此当超过这个值时，就不能被记录，这个值一半情况就是0电平。如果是定点运算比0大的最小值就是000000000000000000000001，但是对于浮点运算，因为小数点可以移动，理论上这个值可以无限小，当然这个帖子讨论的东西定点浮点都一样，就不深究了。
所以说不光最后的音频不能破0，在宿主内部运算的任何一个环节，都不能允许超过0电平，也就是比24个1更大的数字产生，因为这是完全无法记录的。
但是我们可以看到，其实你在宿主内部，除了过了总线之后的结果，都是可以破0而不削波的，在一个轨道上你可以增益6db却没有削波，即使你混音的时候破0了，你都可以在总线上面把推子拉下来也不会削波。可是宿主记录音频的方式又确定了内部任何时候都不能破真正的0，那么这是怎么产生的呢？
这就是因为，多轨宿主做了一点小小的手脚，让每个推子的0都不是真正的0，而是拉到顶时才是真正的0，这样你做的操作实际上都是不同程度的数字衰减，除非所有推子都推到顶了，不然就都被衰减了。在定点运算中，衰减直接会导致数值尾数丢失；浮点运算中，衰减本身虽然不会导致尾数丢失，但是如果不丢失尾数，重新增益时会导致溢出，也就是破0。所以为了不破0，宿主不论在定点还是浮点运算，都会舍弃尾数，来保证有增益的空间。
同理，并轨操作也是会使得数值增大的操作，因此宿主在并轨时也要对每轨数字信号进行预衰减来保证最终运算过程中不产生溢出。
可是为什么宿主进行了衰减，可是听起来响度却没变，这也很简单，因为它也偷偷做了增益。
我举一个例子，如果一个值本身是111111111111111111111111，进行推子的运算时，宿主会把他变成011111111111111111111111{1},最后一个1被舍入了，然后再增益回来，变成111111111111111111111110，这样操作之后，音频听起来会差不多，但是其实尾数丢失变成0了。最后就回到我上次发的那个帖子产生的结果，dither时，会为音频添加被截断位数的随机数，也就是说24到16时，会添加类似于00000000000000001011011这样的随机数（实际上就是最后8位）。但是经过宿主轨道推子的第一次衰减（如果时cubase推子从6.02到0就是衰减为原来的2分之一），这个信号会变成00000000000000001011010(丢失了一位），另外一轨的原始音频和这个dither信号一样也会丢失尾数，在并轨的时候可能也会进行同样的类似的衰减丢失了尾数。
和降bit的时候一下子丢失8位尾数比起来，宿主这样的预衰减产生的失真有可能几乎难以被人耳朵分辨，但是却可以一定程度上导致dither信号的随机性被削弱了，减弱了dither的效果，导致了之前平行dither之后产生的情况。
另外这里插一句，浮点运算有一个问题在于一些在十进制计算里面应该相减后等于0的计算结果有可能会得出一个非常小的数字而不是0，这是因为十进制有限小数用二进制来表示时可能会变成二进制循环小数进而导致截断误差，这个所以很多浮点算法里面可能会有一个修正手段，设定一个阈值来认为小于这个阈值的数值都是0，当然这个手段也会误伤到本来就很小的数据。因此相位叠加的结果是0，并不一定是真的信号完全相同，而是有可能反相叠加之后的数值小于这个阈值。不过这贴主要不是为了讨论这个，就不深究了。
最后附上自己做的实验的图，可以看到当将两个轨道的推子都推到顶的时候，平行dither的效果变得更加接近普通dither的效果了，剩下的一点区别我认为是并轨操作里面的预衰减导致的。

拜读。无论文章观点与结论如何，都感觉受益良多

总线bit一般是通道的两倍，因为要累加，通道32总线64，老hd是24/48，这跟fpga的累加器设计有关。之后生成24bit或者16bit要降bit也是为啥导出后觉得音质变差了。

所以最后证明了，反相抵消的方法并不能证明两个音频是完全一致的。

我也不太清楚诶，这次实验的时候因为考虑到声卡数字通道只有24bit，所以我用的24bit的工程。现在理论上经过插件处理后的文件都变成64bit浮点了。如果并轨的时候先升bit数也就是在尾数补零再进行累加的话应该可以避免需要进行预衰减的情况，但是如果在累加的时候即使有效数字只升了1位，最后再回到工程bit数时还是要对末尾数字进行舍入，这也可能是最后平行dither还是和普通dither有一点区别的原因。因为6.02db的衰减实际上只舍去了二进制的一位有效数字，就在dither上产生了明显的效果，那么宿主累加轨道到导出时的操作确实更可能是升bit再降回来这样才会使得误差小于一位数字产生的误差。导出后音质的问题我猜测可能和总线上的那个推子也有点关系，毕竟不推到顶就有一次衰减再增益的操作。而且任何一步数字处理的话应该都需要这样为数字处理的数据留出空间，要么先升bit再舍入，要么先舍入，复杂一点的计算过程中应该也会需要有舍入以及是否为0的判断之类的，这种过程应该都是有损的。压缩这类产生谐波的操作，理论上会生成高于插件采样率所能记录的频率，但是却最终无法被数字音频记录，因此数字算法本身有能会形成一个低通滤波器的效果，对数据舍入方式的不同，可能就会造成这个滤波曲线有着不同的形态。

这个还是要看测量方式的精度，和浮点运算判断一个小数值是否为0是怎么判断的。我觉得如果用一般的均衡器插件来看的时候，还真很有可能那个0不是真正的0，因为eq是非常占资源的算法，为了优化算法减少延迟可能精度不会特别高，再一个就是eq本身进行实时傅里叶分解来显示仪表的时候也需要取窗，由于要实时显示的关系取得窗是大小也比较小，这个窗也是用数字的方法取的，估计很难会精确到能显示出数字处理的尾数误差的程度

对的

1.推子零就是零，不存在你所谓的衰减，你说有预衰减，那么就要证明它，你既没有什么实验证明它，也没有什么理论支撑它。
2.最后3张图片的区别，我认为差别大了，你用的应该不是Sin吧，那些不一样的，我觉得就是Parallel额外产生的Odd。
3.能更加清楚的说你下你做的实验的过程，那就是极好的了。

学习学习

但是事实就是，我推了一下推子，信号叠加的结果就发生了改变，实验方法很简单我不是说了么，做平行dither的时候推子推到6.02，总线上再拉下来6.02，结果导致了这个不同的结果。你说的odd你有理论支持么，事实上我用protools和cubase分别用一样的插件做平行dither效果都可以不一样，只是我觉得cubase里这个现象已经足够证明了。而且预衰减为什么存在，你去好好了解一下浮点计算就可以，如果不预衰减，你只要把一个本来就峰值达到最大的信号数字增益就会溢出。

我确实有想过做这个实验，但是之前的实验都是在cubase里做的，没在pt里面做，cubase里面并没有办法去看到一个采样的二进制值，这个预衰减产生的不同dither也是在cubase里面产生的。说实话我不知道别的宿主会不会有这样的情况，因为实际上还有一个东西叫做尾数检查，可以修正尾数的改变。如果你找到什么方法比较好做这个实验的话，你也可以把你的实验发一下，我也学习一下，如果确实是可以证明信号100%一样，那也还是要给这个拉推子导致信号叠加结果改变的现象给出一个有理论支持的合理解释才行。

我用的是两个sin，100和1k

建议关注一下airwindows的Dither和文章，总比自己摸索来的强

文章我有看，就算自己摸索，也总比回复几句带优越感的话强