Pre-emphasis☆超·大·全·补完☆

更新:我感觉我搜了下中文圈谈pre-emphasis的不多,而且很多没提到EAC无法识别subcode的问题,我觉得有责任感(大雾)写个摘要提炼下重点。这样别人找起来方便也不用读我这私货奇多的裹脚布。

TL;DR

  1. 关于Pre-emphasis的介绍见前文,那个不长。但是简单来说,为了减少噪声和量化误差的影响,部分老CD(尤其是日本八十年代)会对CD进行预增益,加强高频,并在播放的时候靠CD Player进行de-emphasis来还原。抓碟时需要手动进行这一过程,否则抓出来的音频高频偏高。
  2. 存在只有部分track有预增益的CD
  3. Pre-em的Flag可以写在CDDA的TOC里,也可以写在subcode(正常应该两者皆有)。抓轨软件识别出之后,一般会在CUE里加上FLAGS PRE
  4. 主流rip软件EAC只能识别TOC里的Pre-em flag,不能识别subcode里的!很重要所以再说一遍,EAC的pre-em识别功能是个残疾!要正确地读取subcode里的pre-em flag,Windows推荐使用CUERipper,Mac推荐XLD。
  5. pre-em的音轨即使识别出来,也需要处理。可以用SOX等软件直接进行de-em转换,也可以用foobar2000配合pre-emphasis=1(需要手动添加,CUE里的不识别)的tag和foo_deemph.dll、foo_dsp_deemph.dll等插件进行回放时即时de-em(不修改文件)。
  6. foo_deemph vs foo_dsp_deemph: 前者为后处理滤镜,只支持无损音频(fb2k本身限制),但是可以参与ReplayGain计算(即:RG scan是在考虑了de-em之后计算),另外BUG:暂不支持无损+内嵌CUE+仅部分轨有pre-emphasis=1的特殊情况。后者为DSP(需要DSP中勾选),支持所有格式但是不参与RG计算,无法计算出准确的音量增益。
  7. 可以利用频谱分析(推荐使用周期图,最清晰)来对比音轨和识别pre-em过的音轨。

下面正文。


我发现一个趋势:每次我写点啥文章,绝对会在写完之后发现更多该topic相关的东西,然后……写出一个比本篇还长的续。这次大概也不例外了。

Pre-emphasis危机

上篇说到Pre-emphasis的事情,有提到我对我之前的收藏里有多少没发现的Pre-emphasis的担忧,这不果然说中了。因为知道了这玩意的存在,所以在抓うしろゆびさされ組的第二专《∞》的时候专门留了个心眼,发现和首专不同,这张抓出来并没有pre-emphasis的tag,听起来也一切正常。不过和手头其他版本对比的时候我想起来当年我就觉得《おニャン子クラブ大全集》(下称:大全集)里的「バナナの涙」不太对,但是当时手头其他版本都是MP3的只有这个是无损,所以以为是别的都有问题。这和原版专辑《∞》里的一比就听出问题了:《大全集》里的版本明显尖锐许多。

我赶紧去看《大全集》的CUE,发现并没有FLAG PRE。这下我彻底恐慌了:连官方出的精选集都能搞这幺蛾子(有pre-emphasis却没标明),这到底要怎么避免哦?我进而把这《大全集》的DISC 4 with おニャン子クラブ集又重头到尾听了一遍(同时不断和手头有的其他版本对比),果然发现有多首,包括うしろゆびさされ組的全部四轨都有pre-em的问题。其他有些虽然听着偏尖锐,但是你别说,这个东西单独听真的很难说清楚到底有没有pre-em,尤其是要知道这个pre-emph主要是对某些音色的乐器影响比较大(比如上次提到过的,架子鼓里的钹),对人声尤其是比较粗的人声其实变化不大(嗯新田恵利这种很尖锐的声线就明显多了w),某些歌曲甚至对比着听都不明显。而且和其他版本对比本身也有个问题——你怎么知道其他版本就是正确的呢?尤其是我手里的其他版本很多连无损都不是。

当然,这张DISC 4本身就是从小猫单飞的各个单曲/专辑里采集来的,音源不一,所以有这种问题也算在我的意料之内,不过接下来的事情就更蛋疼了。《大全集》大部分碟是小猫俱乐部八十年代的原创录音专辑+额外曲目的形式。所以如果不出意外,至少前面和原专辑一样的部分的pre-emphasis状态应该统一:要么都有要么都没有。还是通过对比的方式,我发现至少前三张碟的大部分都OK——并没有pre-emph,还顺便发现了反而是我最早下的一张的小猫的碟(网易云扒的MP3),算是最经典的二专《PANIC THE WORLD》(下称:PANIC),其实有pre-em(汗,这碟我感觉听了有快上百遍了,当时也没觉得有啥问题……现在再去听真是尖到不行)。

用Foobar2000回放有损的pre-em音频的方案

这里插播一个实践上的问题。上次提到de-emphasis要用foobar的两个插件,lvqcl开发的foo_deemph和foo_dsp_deemph。前者是后处理插件,也就是说无设置,会无脑应用到后处理里(包含回放和转换,如果勾了后处理选项)。我之前是用的这个。结果这个的问题在于他仅作用于无损音频——关于这点我问了作者,并不是他不想改,而是foobar对后处理插件的限制(或者说foobar的工作流程如此)。所以,我上面提到那个,有pre-emphasis的MP3专辑《PANIC》,自然只能用DSP版本才行。但是这就又引出一个问题:回放增益(ReplayGain)。在进行了deemph之后,音频改动还是蛮大的,回放增益扫描的结果也不会一样。事实上,一般一个音轨deemph之后,回放增益得加个2dB。之前用foo_deemph的时候倒是OK,因为回放增益在计算时会自动考虑进去所有后处理;但是现在换了DSP版,这个在计算回放增益的时候是不工作的。

解决办法倒不是没有,就是非常啰嗦:

  1. 把MP3文件转换成WAV;
  2. 现在因为是无损了,所以foo_deemph工作了,可以扫描RG了。
  3. 把RG用MP3tag复制RG到之前的MP3(这是一个傻逼点,因为foobar2000刻意不支持文件间复制RG信息,只能手动一个个输入…一般的标签倒是支持)。
  4. 然后回放的时候……你得换成foo_dsp_deemph,因为只有这个支持有损(别忘了pre-emphasis的tag还得有,DSP里得勾上)。虽然顺序变成了先apply RG再apply deemph,从数学原理上来讲两者等效。

另外,因为回放的时候你不能同时装foo_deemph和foo_dsp_deemph(否则无损的有pre-emphasis tag的音频就会被deemph两次了),所以整个流程你得重启foobar N次,动用两个软件(foobar2000,Mp3Tag)。

不过这个流程可以稍微简化一下:在转换MP3到WAV的时候,直接用DSP版的把deemph硬编码进去——别忘了之后删掉pre-emphasis的tag——然后和上面就一样了。这个方案的区别在于完全用不到后处理版的foo_deemph,不需要重启foobar,但是总体而言还是很麻烦。

而且更麻烦的一点是,如果你改用foo_dsp_deemph(凡是你要给有损音频de-em,这是唯一的选择),那么就连原来没问题的无损的音频的RG扫描都不能直接进行了。所以,果然我的第一要务是赶紧把这些垃圾MP3洗版买二手CD洗掉。

哦顺便说句,foo_dsp_deemph还有另外一个同名的,由开发者mudlord从他的那个巨型插件foo_dsp_effect里分离出来的独立组件。之前说的有误,这个插件虽然名字叫DSP,但是其实包含上述两个插件的的功能,即后处理+DSP:在安装该插件之后,自动含对有pre_emphasis =1 tag的文件进行de-em;与此同时,你还可以在DSP开启强制de-em。而且其提供了俩DSP,外一个是黑胶的RIAA Curve

至于de-em算法方面,我对比了lvqcl版、mudlord版以及sox,虽然均非bitwise identical但是基本频谱一致,应该不会有任何听感上的差别。(7/5更新)

「およしになってねTEACHER」之谜

实践方面的问题就插播完毕,回到之前的话题,既然我们知道三专《PANIC》有pre-emphasis,那前两专呢?一专《KICK OFF》我手头的是无损,打开CUE一看发现里面大大的FLAGS PRE,这就好说了,直接给wav文件加个tag完事儿。二专《夢カタログ》(下称:夢)我之前虽然下了个MP3,但一直都没解压,因为反正《大全集》里都有了;这不为了对比我又翻出来了。果然这二专一听,也是有pre-emphasis的,但是前面说到的“蛋疼”的事情来了:我发现在de-emphasis之后,二专的大部分曲目听感和《大全集》版一致,唯有第一轨「およしになってねTEACHER」(即第二单曲),不但两者不同,和3专《PANIC》里收录的版本也不同!我又找了多个版本,最后从“尖锐程度”从大到小排列大概是这么个样子(其实有的差别很小,我用了耳朵听之外的方法检测,不过这是下一章的重点。另外,听的时候因为一定要保持平均响度高度一致(否则怎么对比),由于上面提到过的RG+pre-em的配合问题,这里请暂时配合on the fly版的RG DSP:foo_r128norm使用,并放在foo_dsp_deemph的后面):

  1. 《夢》(pre-emph)
  2. 《大全集》 = Single版
  3. 《夢》(de-emph)
  4. 《PANIC》(de-emph) =《SUPER BEST》
  5. 《大全集》(de-emph) = Single版 (de-emph)

这里,4这两个版本听感完全一致,外加精选集《SUPER BEST》是我从实体碟抓的无损(不过有个暂不相关的问题后面讲),所以姑且称之为“标准版本”。那么《夢》和重制《夢》的《大全集》的问题在于:第一,两者莫名地不一致,虽然差别不大;第二,《夢》即使加了de-em(根据其他音轨推算应该加),也比4这个标准版要尖锐一些(但是不至于刺耳);至于《大全集》版,不加de-em处于《夢》加和不加之间,加了就反而比4这个标准版还要低沉。

如果再进一步从听感上选最合理的然后简化,有三个版本(还是按照高频强度从高到低排列):

  • 《大全集》 = Single版
  • 《夢》(de-emph)
  • 《PANIC》(de-emph) =《SUPER BEST》

几乎可以肯定《大全集》制作的时候,是使用单曲音源替换掉了第一轨——因为手头的单曲版和他的特征一致,而且否则也无法解释为啥其他轨《大全集》和《夢》de-em后听感完全一致,唯有这个不同。但是要注意的是「およしになってねTEACHER」这张单曲是只有黑胶版的,并没有发过CD;我手头这个“单曲版”的MP3到底怎么从黑胶Rip出来,规不规范,无从得知;不过对于制作方波利佳音,他肯定有母带所以倒不是问题。

至于《夢》的版本,在正确地加了de-emph之后其实和《大全集》版/单曲版区别并不大,这里这里我大胆猜测,两者的区别可能仅仅是黑胶和CD制作上客观导致的(毕竟一个analog一个digital)。又或者是《夢》里的版本是Album version(当年album version基本都是没任何标记)。

至于后面为什么《PANIC》以及《SUPER BEST》这两张精选集里收的版本互相一致、却和上面的单曲版和专辑版都不同就很难理解了。而且这个“不同”还是相当明显的——从最最开始的前奏就很明显可以听出。一般而言,这类精选集收的应该都是单曲版,其不同的原因现在也很难考证了。

利用频谱分析

上述「TEACHER」这场风波,让我了解到纯靠听来比较音轨,实在是不靠谱,尤其是差别小的时候。而且很多时候,我手头只有一个版本,也很难判断是否有pre-em。介于pre-em技术的原理就是加个EQ,所以第一时间想到的就是用频谱来分析了。

一般而言,直接FFT后的Amplitude spectrum就OK,用频谱密度(Spectral Density)也行,不过基本趋势都是一样的。具体实现上前者没什么好说的,注意用双侧转换成单侧(参见Matlab的fft说明文档里的范例)就是。谱密度的话,可以直接用PeriodogramMatlab函数),或者用Welch’s methodMatlab函数)可能更美观些。

不过,在分析前,得先做一些前处理。为了方便对比,首先需要注意的是音量均衡的问题。虽然我可以在foobar里跑RG,但是为了简单起见我做了个纯粹根据数学RMS(均方根)来均衡强度的函数:


function [ y ] = normalizerms( x, targetdB )
%NORMALIZERMS Summary of this function goes here
% Detailed explanation goes here
%normalize
targetrms=10^(targetdB/20);
myrms=rms(x);
% valueDBFS = 20*log10(abs(myrms));
y=x/(myrms/targetrms);
end

view raw

normalizerms.m

hosted with ❤ by GitHub

这样,我就不用操心响度不一不便于对比的问题了。实际操作上,音轨通过audioread导入之后,要先downmix到单音道,然后跑这个来均衡强度:

 [wave,Fs]=audioread(file);
 x=(wave(:,1)+wave(:,2))/2; 
 x=normalizerms(x, -20);

这里我选了-20dB这个比较低的目标RMS,因为我不想导致clipping。

然后再把信号跑上面的提到的几种频谱法就行了,下面我主要以Periodogram为例。那么,就让我们先随便找一首歌,来对比pre-em和de-em的区别。用的曲目是上次提过的「偏差値BOY」,无损音源。

(左边:原始文件(pre-em),右边:de-em之后。点击查看幻灯片或者大图)

和想象的一样,两者的周期图的区别较为明显,后者高频方向向下倾斜的趋势更明显,也符合de-em的原理。基本上,如果看到曲线接近后者,可以认为是正常的歌曲;如果是前者这种很平的,那就是有pre-em。嗯,还是有点模糊…不过比纯靠听稍微强点。

接下来就看看上面提到过的「TEACHER」的部分版本。

左起:《SUPER》版,《夢》版(de-em后)和《大全集》版(de-em后)

其中,《夢》版(de-em)在16kHZ左右的狂跌是因为MP3格式所导致。不过除掉这部分不看,也可以看出和1的标准版相比,整体更平(即:高频更高)。而最后一个的《大全集》版(de-em后)则比1更斜(即:高频更低)一些。

这里有一点要注意,就是《大全集》版(de-em后)以及这里没贴出来的单曲版(两者基本一样)都在大约1.5kHZ的地方有一个凹槽,这是很不正常的(别的版本都没有)。同样的凹槽其实我在很多音轨上都见过,我强烈怀疑是早期母带制作时,在压制或者是analog转digital时什么过程的痕迹。也许这也能解释为什么《大全集》版(de-em后)比标准版要低,虽然两者听感几乎一致。

其他几种visualization的方法既然我都做了,就贴一下让大家感受一下。

Welch’s method估计PSD:参数我都瞎搞的,不过基本而言,x后面的第一个参数window越小分割次数越高,平滑度越高,也越慢。

左起:《SUPER》版,《夢》版(de-em后)和《大全集》版(de-em后)

另外,我一直想模拟一下类似foobar频谱的按band分开的柱状图:

QQ图片20170701184057

但是有太多的搞不清楚的问题:第一,band怎么分?Foobar明显不是用线性的,每个band的label分别是(以20个band为例):

[50,69,94,129,176,241,331,453,620,850,1200,1600,2200,3000,4100,5600,7700,11000,14000,20000]

看不出有什么规律,只知道肯定不是线性,手动回归了一下大概是类似y=10^(1.5633+0.1368x) (x=1:20)的样子。

第二,每个band里面到底应该怎么把里面的点“累积”起来?是直接相加(因为是离散的)?

总之,我瞎搞了一番,最后成图如下:

左起:《SUPER》版,《夢》版(de-em后)和《大全集》版(de-em后)。单位写错了应该是HZ,懒得改了。

完整代码(含所有的可视化方式,在上方切换):


filenames = {'samples/teacher/super.wav','samples/teacher/yume_deem.wav','samples/teacher/yume2005_deem.wav'};
%'samples/panic.wav','samples/super.wav', 'samples/yume.wav','samples/yume2005.wav','samples/single.mp3'
%filenames = {'old/good_rg.wav','old/bad_rg.wav'};
method = 'peri'; % peri, welch, fft, fftband
close all
for i = 1:length(filenames)
file = filenames{i};
[wave,Fs]=audioread(file);
x=(wave(:,1)+wave(:,2))/2; %Downmix
% %Filter
% N = 200; % FIR filter order
% Fp = 15000; % 20 kHz passband-edge frequency
% Rp = 0.00057565; % Corresponds to 0.01 dB peak-to-peak ripple
% Rst = 1e-4; % Corresponds to 80 dB stopband attenuation
% eqnum = firceqrip(N,Fp/(Fs/2),[Rp Rst],'passedge'); % eqnum = vec of coeffs
% lowpassFIR = dsp.FIRFilter('Numerator',eqnum);
% x=lowpassFIR(x);
x=normalizerms(x, 20);
switch method
case 'peri' % periodogram
figure
periodogram(x,rectwin(length(x)),length(x),Fs)
xlim([0 20])
ylim([-180 20])
case 'welch' % Welch's power spectral density estimate
[pxx,f] = pwelch(x,2000,[],[],Fs); % Disclamer: I have zero idea about those parameters
figure
plot(f,10*log10(pxx)) % You can remove dB conversion
xlabel('Frequency (Hz)')
ylabel('Magnitude (dB)')
xlim([0 20000])
ylim([-105 40])
case 'fft' % FFT (amplitude spectrum)
L=length(x);
f = Fs*(0:(L/2))/L;
Y = fft(x);
P2 = abs(Y/L); % You can choose to not divide it by L, no difference
P1 = P2(1:L/2+1);
P1(2:end1) = 2*P1(2:end1);
figure
plot(f,P1) % you can convert it to dB too, make sure to use 'voltage'
xlabel('f (Hz)')
ylabel('|P1(f)|')
ylim([0 0.004])
xlim([0 20000])
case 'fftband'
L=length(x);
f = Fs*(0:(L/2))/L;
Y = fft(x);
P2 = abs(Y); % I don't divide by L here, because I'm going to use dB later
P1 = P2(1:L/2+1);
P1(2:end1) = 2*P1(2:end1);
bars = 20;
% % Linear spacing
% fvalues = linspace(0,20000,bars+1);
% fvalues = fvalues(2:end);
% % Log10 spacing
% fvalues = logspace(-1,log10(20000),bars);
% Copied from FB
fvalues=[50,69,94,129,176,241,331,453,620,850,1200,1600,2200,3000,4100,5600,7700,11000,14000,20000];
fband = zeros(length(fvalues),1);
% Again, I don'tknow shoul you just add them together.
for k = 1:length(f)
for j = 1:length(fvalues)
if f(k) < fvalues(j)
fband(j) = fband(j)+P1(k);
break
end
end
end
figure
histogram('BinEdges',0:length(fvalues),'BinCounts',round(db(fband,'voltage'))')
ylim([0 180])
labels = [0 fvalues(2:2:length(fvalues))];
xticklabels(num2cell(labels))
xlabel('f (Hz)')
ylabel('dB')
end
title(file)
end

CD rip:正确读取subcode的pre-em flags

之前说过,我最怕的是厂商把明明有pre-em的曲目压到CD里面却不处理也不标明——因为这样作为听众哪怕有实体碟那么听到的也是错误的。那么我上面提到的几个例子,尤其是我手头有无损的《大全集》真的一定就是这样吗?答案是否定的。没错,虽然我手里的大全集的CUE,并没有FLAGS PRE,但是这并不代表原碟就一定没有对pre-em进行标记。

这要先从pre-em的标记方式说起。在CDDA中,可以有两个地方标记各种flag:一个是在目录(Table of contents,TOC)中,一个是在“subcode”(又称subchannel data)中。其实CDDA实际的结构要更复杂一些,简单地说就是除了16位的音频数据的部分,其他有大量的类似元数据的subcode存在。其中,每一轨都可以有自己的subcode,而在整张光碟的头部、尾部又各有一个区域完全是subcode。其中,头部的subcode包括了一些诸如discid之类的元数据,另外也有TOC(所谓的TRACK 00):TOC其实就是对整张专辑各个轨道的简单描述,主要是每轨的开始时间(便于跳转),但是也可以包括诸如pre-em在内的tag。

然而与此同时,在每一轨的subcode中,同样可以包含这样的信息。这问题就来了:虽然理想情况下两者应该是一致的,但是大量实践证明,有许多CD,只在其中一个中包含了pre-em的flag(一般是subcode)。

这俩不一致本身其实不是什么大事儿,但是问题在于,Win平台下最流行的CDrip软件,大名名鼎鼎的的EAC,不支持subcode flag。呃,其实准确地说,也是有难言之隐:早在01年左右的0.9x版本的EAC,包含一个叫做“Detect TOC Manually”的功能,说白了就是用subcode里的信息手动重建TOC(而不依赖于TRACK 00的TOC),这个功能就能检测到subcode-only的pre-em tag。但是由于当时有些CD利用hack TOC的方式来防复制,所以EAC这种功能有违反欧洲法规的风险(等于你绕过了TOC的加密),作者就在后面移除了该功能。大概这也是为什么我在论坛有时候会看到有人强调要用旧版EAC的缘故?

无论如何,身为几乎在烧友圈(至少国内)被神化的EAC居然缺失这么明显一个功能,也是略显讽刺。所以,即使碰到有的碟,正确用EAC抓取、CUE没有pre-em的flag,听起来却尖锐,也就是上面说的《大全集》中的某些轨,也不一定就是厂商搞砸,而是subcode的flag没被抓出来。当然现实来说,《大全集》是21世纪的2005年发售的,感觉还在发行带pre-em的CD概率并不高……大概还是搞砸了罢,这个没有实体版实在是无从确认了。别忘了之后波利佳音又洗过一版,说不定正是为了擦屁股呢?(笑)

不过虽然那个手头没有实体无法验证,我之所以会深入研究这个正是因为我手里就有一张这样的碟:[1986-10-21] [D32P6003] おニャン子クラブ – スーパーベスト(即前文所说的《SUPER BEST》)。这碟我用EAC抓,是显示没有pre-em:

QQ截图20170701222211

抓出来的CUE自然也没有flag。但是实际上呢?用听的就知道,第一轨「お先に失礼」肯定有pre-em,后面的第二轨又明显没有。可见这碟应该是属于部分pre-em那种(考虑到是选集,也说得通)。

既然EAC不行,我们只能换软件了。hydrogenaudio提供了一个非常完善的ripper软件列表。不过排除一些收费软件和非Win平台的(比如很有名的Mac平台的XLD),外加上我从这贴了解到的其他一些,我大概筛选出这几个:

于是先来试试最简单的CUERipper。

QQ图片20170701234441

选项非常简单,要我说是EAC过分复杂了。虽然这里看不出来,但是抓出来的CUE确实有正确的FLAGS PRE没错。具体来说,是tr. 1/6/9/11有,也和试听听感完全一致。

再让我们试试其他俩软件。cdda2wav和cdrdao都是命令行工具;而且更不方便的是两者官方网站都不提供binary,只有source code。cdda2wav现在是软件包“cdrtools”(原名:cdrecord)的一部分,这里可以找到Win-32原生的编译版本(最新:v3.02a07),或者用第三方的GUI版本——cdrtfe,里面也有编译好的cdda2wav(不过是虚拟版,如果你要单独运行,得把cygwin目录下的cygwin1.dll复制到和cdda2wav.exe一起)。

但是这个cdda2wav……用起来有问题。还是上面这张碟,让我们跑个-J(仅输出信息)来看看:

C:\Users\Administrator\Desktop\schily-cdrtools-3.02a07\win32>cdda2wav -J
No target specified, trying to find one...
Using dev=7,0,0.
Type: ROM, Vendor 'HL-DT-ST' Model 'DVDRAM SP80NB60 ' Revision 'RA00' MMC+CDDA
261632 bytes buffer memory requested, transfer size 64512 bytes, 4 buffers, 27 s
ectors
#Cdda2wav version 3.02a07_mingw32_nt_1.0.17-0.48-3-2-_i686_i686, libparanoia sup
port
AUDIOtrack pre-emphasis copy-permitted tracktype channels
 1-15 no no audio 2
Table of Contents: total tracks:15, (total time 57:28.72)
 1.( 3:50.00), 2.( 4:16.50), 3.( 3:59.45), 4.( 3:28.52), 5.( 3:44.08),
 6.( 3:12.20), 7.( 3:52.20), 8.( 3:45.20), 9.( 4:08.45), 10.( 4:00.65),
 11.( 3:58.67), 12.( 3:50.70), 13.( 3:50.15), 14.( 3:08.60), 15.( 4:21.60),

Table of Contents: starting sectors
 1.( 0), 2.( 17250), 3.( 36500), 4.( 54470), 5.( 70122),
 6.( 86930), 7.( 101350), 8.( 118770), 9.( 135665), 10.( 154310),
 11.( 172375), 12.( 190292), 13.( 207612), 14.( 224877), 15.( 239037),
 lead-out( 258672)
CDINDEX discid: Bk20VmlSPt6WEen5bpehBUBc6no-
CDDB discid: 0xc20d780f
CD-Text: not detected
CD-Extra: not detected
No media catalog number present.
scanning for ISRCs: 15 ...
index scan: 1...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
index scan: 5...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
difference: TOC:without, subchannel:with preemphasis
correcting TOC...
index scan: 6...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
index scan: 8...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
difference: TOC:without, subchannel:with preemphasis
correcting TOC...
index scan: 9...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
index scan: 10...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
difference: TOC:without, subchannel:with preemphasis
correcting TOC...
index scan: 11...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
index scan: 15...

前面的不重要,不过也可以看到TOC里没扫到pre-em。但是从每个track的subcode scan开始:

index scan: 1...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
index scan: 5...difference: TOC:without, subchannel:with preemphasis
correcting TOC...
difference: TOC:with, subchannel:without preemphasis
correcting TOC...
difference: TOC:without, subchannel:with preemphasis
correcting TOC...

这就很诡异了:扫第1轨的时候,显示发现了TOC和subchannel不一致(subchannel=有,pre-em,TOC=无),于是纠正TOC,到这步没问题;但是紧接着,居然又来了一遍,不过这次是说TOC有(废话,你自己刚改的),subchannel没(??),于是又改了一次,把TOC给改回成无了!

同理第5轨,不过这次不同的是这么翻来覆去改了三次,即TOC为无->有->无->有,最后结论是有pre-em。

那么上面的全部总结下来,最后留在.inf文件里的居然是:tr. 5/8/10有pre-em。发现问题没有?正好和之前用CUERipper测得的向前偏移了一轨(1前面是0所以没有了)。为了保险起见,我又把这几轨全部找出来,和其他碟里收录的同一轨进行反复对比。虽然有的确实比别的版本稍微锐那么一点点(例如tr. 10那首「シンデレラたちへの伝言」我手头有俩无损版本的,有一个还是我自抓),但是如果真的去跑de-em,那又钝太多(靠频谱),所以基本可以90%肯定是没有pre-em的。

好家伙,Linux下最有名DAE(digital audio extraction)软件的cdda2wav居然有毛病,这事儿我得去hydrogenaudio反馈一下了。那让我们看看cdrdao好了。这里先说个笑点:EAC的目录里赫然有个cdrdao.exe(虽然是很老的1.1.9版),可见他也是调用了cdrdao来进行TOC提取的……然而阉割了cdrdao带的从track subcode里提取信息的功能。这软件的Windows binary也是相当的难找,最后在这个已经404的网页Archive里找到了一个编译好的1.2.3版(2009年最后版)和相应的dll文件(其实就是上面提过的cygwin1.dll)。

废话不多说,上log。

E:\sync\Software\cd\cdrdao-1.2.3-bin\cdrdao-1.2.3-win32>cdrdao read-toc --device
 8,0,0 test.toc
Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de>

8,0,0: HL-DT-ST DVDRAM SP80NB60 Rev: RA00
Cannot read driver table from file "/usr/local/share/cdrdao/drivers" - using bui
lt-in table.
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)

ERROR: Unable to determine drive letter for device 8,0,0! No OS level locking.
Reading toc data...

Track Mode Flags Start Length
------------------------------------------------------------
 1 AUDIO 0 00:00:00( 0) 03:50:00( 17250)
 2 AUDIO 0 03:50:00( 17250) 04:16:50( 19250)
 3 AUDIO 0 08:06:50( 36500) 03:59:45( 17970)
 4 AUDIO 0 12:06:20( 54470) 03:28:52( 15652)
 5 AUDIO 0 15:34:72( 70122) 03:44:08( 16808)
 6 AUDIO 0 19:19:05( 86930) 03:12:20( 14420)
 7 AUDIO 0 22:31:25(101350) 03:52:20( 17420)
 8 AUDIO 0 26:23:45(118770) 03:45:20( 16895)
 9 AUDIO 0 30:08:65(135665) 04:08:45( 18645)
10 AUDIO 0 34:17:35(154310) 04:00:65( 18065)
11 AUDIO 0 38:18:25(172375) 03:58:67( 17917)
12 AUDIO 0 42:17:17(190292) 03:50:70( 17320)
13 AUDIO 0 46:08:12(207612) 03:50:15( 17265)
14 AUDIO 0 49:58:27(224877) 03:08:60( 14160)
15 AUDIO 0 53:07:12(239037) 04:21:60( 19635)
Leadout AUDIO 0 57:28:72(258672)

PQ sub-channel reading (audio track) is supported, data format is BCD.
Raw P-W sub-channel reading (audio track) is supported.
Cooked R-W sub-channel reading (audio track) is supported.
Analyzing track 01 (AUDIO): start 00:00:00, length 03:50:00...
Found 38 Q sub-channels with CRC errors.
WARNING: Pre-emphasis flag of track differs from TOC - toc file contains TOC set
ting.
Analyzing track 02 (AUDIO): start 03:50:00, length 04:16:50...
Found pre-gap: 00:02:10
Found 28 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 03 (AUDIO): start 08:06:50, length 03:59:45...
Found pre-gap: 00:02:08
Found 21 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 04 (AUDIO): start 12:06:20, length 03:28:52...
Found pre-gap: 00:02:00
Found 11 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 05 (AUDIO): start 15:34:72, length 03:44:08...
Found pre-gap: 00:01:72
Found 9 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 06 (AUDIO): start 19:19:05, length 03:12:20...
Found pre-gap: 00:02:03
Found 12 Q sub-channels with CRC errors.
WARNING: Pre-emphasis flag of track differs from TOC - toc file contains TOC set
ting.
Analyzing track 07 (AUDIO): start 22:31:25, length 03:52:20...
Found pre-gap: 00:02:03
Found 20 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 08 (AUDIO): start 26:23:45, length 03:45:20...
Found pre-gap: 00:02:03
Found 17 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 09 (AUDIO): start 30:08:65, length 04:08:45...
Found pre-gap: 00:02:03
Found 13 Q sub-channels with CRC errors.
WARNING: Pre-emphasis flag of track differs from TOC - toc file contains TOC set
ting.
Analyzing track 10 (AUDIO): start 34:17:35, length 04:00:65...
Found pre-gap: 00:02:05
Found 10 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 11 (AUDIO): start 38:18:25, length 03:58:67...
Found pre-gap: 00:02:03
Found 15 Q sub-channels with CRC errors.
WARNING: Pre-emphasis flag of track differs from TOC - toc file contains TOC set
ting.
Analyzing track 12 (AUDIO): start 42:17:17, length 03:50:70...
Found pre-gap: 00:02:02
Found 11 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 13 (AUDIO): start 46:08:12, length 03:50:15...
Found pre-gap: 00:02:00
Found 9 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 14 (AUDIO): start 49:58:27, length 03:08:60...
Found pre-gap: 00:02:00
Found 7 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 15 (AUDIO): start 53:07:12, length 04:21:60...
Found pre-gap: 00:02:00
Found 6 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.

Reading of toc data finished successfully.

可以看到,找到且只在1/6/9/11轨中找到了pre-em信息,和CUERipper一致。不过有一点,他只是提醒你“WARNING: Pre-emphasis flag of track differs from TOC – toc file contains TOC setting.”,实际在提取出来的TOC文件里并自动没有修改成正确的、来自subcode的pre-em tag,这个还得自己手动来。

部分Pre-em的CD rip的存储和回放方式

碟算是抓完了,pre-em信息也有了,这就引出下一个问题:如何存储/回放这样的碟。WAV+CUE的方式是行不通的——因为上篇说过了,外置CUE里的FLAG PRE foobar2000不认,你也无法给CUE加pre_emphaiss的tag,加到音频文件里又会适用给整张碟。

保持整轨的前提下,唯一的解决方案就是FLAC+内嵌CUE了(其他无损格式应该也行)。要注意的是,FLAC+内嵌CUE,并不仅仅等价于“FLAC+CUE,只不过CUE内嵌”。在这里,内嵌的CUE主要起一个提供时间戳分轨的功能,但是实际上你对每一轨的metatag的自由度非常高,和单独的FLAC没有两样。也就是说,你完全可以做到给单个FLAC文件里每一轨加不同的pre_emphaiss的tag——即使CUE不支持。你甚至可以做到:每一轨的album不一样!不过如果你真的这么做,然后用foobar2000带的内嵌CUE查看器你会发现,CUE里的album还是老的值,可见这些元数据里并不是真的存在CUE的(不过,如果你进行一些CUE能支持的metatag操作,比如同时修改所有轨的albumalbum artist,或者单独轨的artisttitle,内嵌的CUE还是会跟着同步更新的)。

这个方案算是不错,但是和直接用分轨FLAC+pre-em tag一样都有一个问题前面提过:RG。因为我有一些lossy的需要加pre-em tag的文件,所以我被迫用了DSP版的de-em;但是DSP和RG不兼容(计算RG时不考虑DSP)。所以我现在俩抉择:1) 转成分轨FLAC,且同时直接将de-em硬计算进去;2) 换回后处理版的de-em,但是把那些有损音频强行transcode成无损一份来存储。实话说,两种方案都很蠢。现在我暂时还没想好到底要用哪种方案,姑且先去foobar论坛发了一贴问。

更新:今天又发现一个foo_deemph的bug:丫不支持FLAC+内嵌CUE的pre-emphasis tag,加了也不会de-em,orz 所以指望靠FLAC+InCue来保持最大程度的原Image是不现实了。我现在采用的方案是:使用foo_deemph插件,但是把所有 1) 只有部分轨有pre-em的CD 2) 有损带pre-em的音频 全部转一份分轨FLAC然后加pre_emphasis = 1 的tag。老的文件打包备份(防止被foobar20000的数据库读取;我在FB里filter掉了*.rar和*.zip)。这样的缺点是很占空间(有损转无损,还保留两份…)

OK,这个话题到此算是结束了。接下来我得强迫症般地把之前抓的碟都拉出来看一看,以保证没有subcode的pre-em flags……

收集老CD要注意Pre-emphasis的存在

Blog荒废了好几个月,本来正好前天有个题材(压片相关)要写,结果正巧碰到另外个事儿,觉得得先写写这个。无损音乐自己玩了这么多年,以为算是太阳下面没什么新鲜事,没想到上次一个Replay Gain一个Media server把我好好折腾了一番。这不,今天又接触了一个前所未闻的概念——emphasis。

这个问题其实要从几个月前说起。当时我在收集小猫俱乐部相关CD的时候,下到这么一盘——うしろゆびさされ組的首专「ふ・わ・ふ・ら」。

うしろゆびさされ組 - ふ・わ・ふ・ら

当然,这种80年代的老碟都是基本只能找到MP3或者网易云音乐(这里顺便提一句,网易云绝大多数老一些的、尤其是非华语音乐资源都是网上找的,那么多码率选项显然都是二次转换出来的。那伪320kbps实际一般看频谱都是128kps级别,还不如直接128呢,少一次有损压缩),我倒也没要求太高。

但是这张碟的奇怪之处在于,听起来非常“不舒服”。什么程度呢?我听完一张甚至会觉得耳朵疼(我听音乐一般声音很小)。我自认对这些东西比较敏感,觉得这碟肯定是哪里不对。我找遍网上所有的版本,都有这个问题。其中比较明显的是其中收录的单曲1、2,「うしろゆびさされ組」和「バナナの涙」,和单曲版一比就能发现明显区别。

不过,后来我在维基百科看到,说是其中收录的单曲曲目虽然未标记但是是Album version,所以这也算解释的通。不过,这事儿我一直放在心里没忘。

后来,在网上漫无目的地搜索下不到的「AN bALANCING TOY」时,发现骏河屋有人卖二手的「ふ・わ・ふ・ら」等其他几张指指点点组的专辑,外加写真集什么的。正好从来没在骏河屋里买过东西,也试试代购靠不靠谱,就准备把上面有的东西都一起扫了。国内的几个,2poi啊玛莎多拉啊啥的试了下,总有支付或者快递之类的种种问题,于是转投面向西方的服务。最开始试的就是在骏河屋下面打广告条的“Buy Smart Japan”,网站倒是非常简单好用,全自动和亚马逊差不多,不过快递只支持EMS,那4500円的运费把我吓到了(毕竟日亚直购运费便宜的一笔)。

于是我又找了另外一家,Proxyrabbit Japan。这个的界面就蠢多了,买骏河屋一次最多5件,而且你填完表格之后他是通过人工确认和你邮件交流……并且不能即时出运费价格,要先交定金(最低25%商品价格)然后他那边到货了才告诉你邮费。不过我当时抱着上当一次也无所谓的心理就上了。大概quote后过了2天我交了定金(PayPal),又过了一周多那边才收到(据说骏河屋就是挺慢?)货。运费这次倒是有几个档可以选,结果EMS还是4500,于是我选了两千多的Air mail。

废话不多说,总之就是昨天才到我家,还没投递成功我去邮局自取的,前前后后快一个月了。以后还有需求的话,估计会试试转运而不是代购的(看到推荐了两家,http://www.biginjap.com 和 http://www.tenso.com/en/)。二手卖相还可以,没侧标就是了。

IMG_20170621_220513

EAC的话我虽然用得很少,前个月倒也抓过几次,我的经验就是没必要看什么“教程”,按照软件自带的指引一步步点,把offset之类的硬件相关设好就OK。我当年第一张是用的安全模式抓的,速度慢到发指(1.几x),我于是直接改用爆发模式抓(速度7-8x),反正抓完之后有AccurateRipCTDB两个数据库比较CRC32,如果都一致,都是bitwise identical了还觉得只有安全模式才行那只能认为是没文化了。这里容我吐槽下,都CURRENT YEAR了EAC抓出来的CUE居然还只能是ANSI(非Unicode)的,蠢哭。

总之……回到正题。于是我自然先赶紧抓了这张碟来听。嗯?听感好像和之前的完全一致,看来这碟本身就这样?就在我放弃治疗去改CUE的时候,发现有个没见过的玩意:

REM DATE 1986
REM DISCID 9109350A
REM COMMENT ExactAudioCopy v1.3
PERFORMER "うしろゆびさされ組"
TITLE "ふ・わ・ふ・ら"
FILE "うしろゆびさされ組 - ふ・わ・ふ・ら.wav" WAVE
 TRACK 01 AUDIO
 TITLE "SE・KI・LA・LA"
 FLAGS PRE
 INDEX 01 00:00:00

FLAGS PRE是什么鬼?

结果一查不得了,这正是问题的关键。原来,通信中存在一个叫做“emphasis”的技术。说来也很弱智,就是对于多少频率的信号(一般是高频),会进行放大;在信号到达接收端之后,再用反函数把信号衰减回去。放大的过程叫“pre-emphasis”,衰减叫“de-emphasis”。不用说,其目的是减少传输过程中噪音的影响,因为中间引入的噪音会被同样衰减,从而达到更高的信噪比。

这个技术在黑胶唱片、磁带等Analog领域广泛应用,但是在CD这种数字媒体中的应用很少。准确地说,在早期CD(70-80年代)只有14bit的时候,这个应用在其中来减少量化误差(为什么?留作思考题了w)。后来CD的精度变成16bit之后,就基本很少用了,但是其依然存在于CD的标准中,想用的话也是可以的。

事实上,带pre-emphasis的CD恰恰就仅在日本的80年代最流行(注意,日本的CD从80年代后半才开始普及,之前基本发音乐只发黑胶、磁带),其他国家不多。另外需要说明的是“pre-emphasis”(即:特定高频的信号的增益)是直接压在CD里的,不过一般同年代的CD player都会识别metatag里的相关flag,从而自动进行进行de-emphasis来还原信号。

但是到了电脑光驱,这就取决于你的软件端怎么处理了。我们上面可以看到,对于EAC抓轨,他会识别出相关的tag,并标记在CUE中。接下来就全看你的播放器了。

对于绝大多数人,和绝大多数软件,他们是完全无视这个信息的,所以就导致了我最开始提到的那张碟“很怪”的声音——高频被增益了(具体算法根据hydrogenaudio,是“a first-order filter with a gain of 10 dB (at 20 dB/decade) and time constants 50 μs and 15 μs”,我虽然大概能理解但是就不硬着翻译了,毕竟不是科班出身),所以听着耳朵疼,架子鼓里的钹的声音也变了。另外因为这个东西的存在过于冷门,大多数人估计根本没处理过,这也是为什么网上流传的版本全是这个德行的原因。仔细想想可怕极了,到底有多少手里的80s音乐会有这种问题而没被发现呢?

既然知道了原因,解决方案就很简单了。用Foobar2000的话,有网友开发出两个插件来处理这个问题——一个是后处理,一个是DSP插件,前者会自动在播放、计算音量增益、转换(前提你勾选了后处理)时进行de-emphasis,后者顾名思义需要在DSP里作为一个滤镜勾选。需要注意两个默认都不工作,需要对音频文件(而且前者仅限无损)添加PRE_EMPHASIS的tag,值为“1”,“ON”或者“Yes”。

这里有几个细节我啰嗦几句。一个就是CUE里的FLAGS PREFoobar是完全无视的,所以对于无损+CUE的方案,你要把上述的Tag加到你的无损文件里去。另外一个就是转换时,如果勾选了后处理(你一般应该勾选)会自动把de-emphasis给硬编码进去,所以出来的output是已经进行过de-emphasis的了。但是因为转换器默认会把tag都复制到新文件里,所以新文件还有PRE_EMPHASIS的tag,需要手动移除,否则就相当于de-emphasis两次,声音就变钝了。另外,虽然可能性很小,万一有别的软件支持识别CUE的flag,那么播放CUE+有PRE_EMPHASIS tag的无损音频可能会导致多重de-emphasis?嘛估计应该没软件这么蠢就是……

其他的处理软件比较著名的有命令行工具sox,用sox input.wav output.wav deemph可以轻松de-emphasis。虽然和foobar插件两者的结果并不是波形级一致,但是听感无区别。

至于我这张CD的处理方法自然可以是两种,一个就是直接硬编码进去,另外一个就是播放的实时进行de-emphasis。我暂时选的是第二种,这样就不用保留一个单独的原版WAV了,毕竟是破坏性操作;因此,转WAV为FLAC(节省体积)的时候要特别注意去掉勾选“后处理”选项,或者先转换格式,后加pre-emphasis tag。

最后,以这张专辑中我最喜欢的一首歌曲,『偏差値BOY』作为结尾吧 😀

ReplayGain在UPnP media server中的应用和补遗

UPnP media server是个挺有用的东西。在PC端配合一个功能非常全面的foobar2000插件——foo_upnp,安卓端配合foobar2000 Mobile或是BubbleUPnP,即可轻松实现包括但不限:用手机播放电脑里的媒体库,用手机当电脑的音响用(呃延迟没测过,估计只够听歌),用手机控制电脑播放器,以及前面的全部反过来控制等功能。当然,最理想的情况是把media server设在诸如NAS之类的设备上,但是就我个人来说,最常用的应用场景是躺在床上耳机插手机听电脑的媒体库/播放列表。

既然前一段时间折腾了那么就RG,这也得用上不是。让我们先仔细研究一下foobar2000那边的server的profile设置。

qq%e5%9b%be%e7%89%8720170220192532

另外为了便于测试,将Basic Settings里设成始终使用默认profile和关闭增加兼容性的额外流:

qq%e6%88%aa%e5%9b%be20170220193855

可以看到大抵来说,有这么几种streaming的方案:源文件直出,转码为MP3,解码为WAV。

直出最好理解,就是在http上host对应的文件而已。直出可以保有原始文件的所有metatag,自然也就包括RG信息;这样,在移动端使用支持RG的客户端时(这里就是foobar2000 mobile了),就会读取到信息进行响度调整。

但是直出的局限性非常大。foobar2000 mobile支持的格式非常有限。TAK这种就不用说了,自然也不支持任何音频文件+cue的类型。不过倒也不会播不了,只是sever会自动无条件帮你转成WAV。最吊诡的是,像FLAC这种明明是支持的格式(即,你把歌曲拷贝到手机里是能放的),有时候会在foobar2k mobile那边出现播放列表里完全看不到的现象(不能稳定重现。与之相对,第三方的BubbleUPnP则很稳定不会有这个问题)。

既然直出这条路不行,那就只能转码或者解码了。介于局域网带宽对于音频来说完全不是问题,自然选择音质更好的WAV,也避免了二次压缩的问题。不过,转码/解码之后有一个问题,就是RG信息完全丢失。哪怕是转码成MP3也是一样。还好,在下面那个Audio processing里,和Converter(转码器)一样,可以设置转码/解码时的处理。注意这里既然叫processing那自然是硬编码进去,而不是靠RG信息。所以foobar2000 mobile端会识别成无RG信息,调整那边相应的RG设置时要注意(我则是完全关闭)。

哦从图中可以看到,你可以设置规则对不同文件类型设置不同的转码规则(例如有些转,有些直出等等)。但是没啥卵用,因为你一旦开启了processing,所有的都会被强制转一遍mp3/WAV,所以还是死了这条心。

这里又是和上一篇文章中提到的普通用电脑回放时一样,面对一个抉择:是选择全部降低到和RG目标响度一样的响度(即:较低的响度),还是全部增益到和“新歌”一致的一个比较高的响度。这里还是选择了前者,因为毕竟那样对音质的保存是最完整的,而且主要用耳机听歌的话也不用担心有输出不足的问题。具体来说,就是在Processing里开启apply RG,同时对无RG信息的歌曲(主要是响度大的新歌)加个-9.5 dB的pre-amp。如果还不放心可以再加个Advanced limiter(虽然99%的情况根本不会有任何区别),但是介于Advanced limiter目前有个会把1缩成0.9999的bug,还是别了罢。

当然这种选择下就会有一个问题,那就是和我手机里那些已经转换好的、响度和新歌一个水平的音频文件有冲突。而且因为两者都是无RG信息,也无法靠调整手机端的RG设置中pre-amp来弥补。不过还好我一般其他场合听歌是用Google Music而不是foobar2000 mobile,以后就用fb2k mobile专门听媒体库就是。

多说一句,客户端那边选用foobar2000 mobile而不是BubbleUPnP的原因倒不是fb2k mobile支持RG(毕竟在我的最终配置下也用不到),主要还是foobar2000 mobile支持手机端的last.fm统计插件,虽然BubbleUPnP的界面大概好一万倍(电脑的foobar我觉得还行了,手机那个真的是丑的惨绝人寰)。另外,BubbleUPnP有个很烦的地方就是每次我修改服务器端(我电脑)的UPnP设置那边就必须会自动切断连接,也就是退出所有的远程playlist啥的,我还得重新选,在测试的时候尤其烦。而foobar2000 mobile则是另外一个极端……不但不会断,他还会缓存一部分媒体的地址(其实就是个URL,可以在电脑端或手机端的console里看到),也就是说我切换了设置之后有时候得在那边强制退出一次来让他刷新URL(服务器端这边即使你修改了设置,老设置的URL实际上还是并没有禁用的,依然有效)和播放列表。

screenshot_20170220-193326
客户端(foobar2000 mobile)读取流媒体的log范例

UPnP媒体库播放的响度规格化这事儿到此也就告一段落了。不过,我又回头去想在移动设备播放歌曲的workflow能否有可优化的地方。

如前文所述,我目前在移动设备采用的是“新歌不变,老歌先RG再+9.5dB”的方案,原因是因为这样兼容性最好,对没有RG支持的播放器也能完美播放,而且不会有输出太低的问题(我手机插车上听,即使在这种设置下都几乎要开到最大音量才行了,如果全部都低9.5dB那可调整的余地就太小了)。当然最大的问题就是+9.5dB导致的超过full scale引起的削波问题。

解决方案上次也说过,就是在转换时再用DSP加一层Advanced limiter,把超出的部分动态调整到1以下。不过由于犹豫会对音乐的完美呈现造成影响(毕竟还是部分压缩了动态范围)我之前一直没用。不过最近遇到这么一首歌,一下子就听出削波的问题了(下载链接):

废话一下,歌曲是菊池桃子的「卒業 -GRADUATION-」,个人的五星歌曲。算是无数好听的叫“卒业”的歌曲之一(其他的还有尾崎豊的,斉藤由貴等等)。菊池桃子天使般的声线在这歌里得到完美的体现。咳跑题了。

这歌的问题在于动态范围极大,在我的传统转换设置下,自然会溢出full scale很多,事实上,其peak达到了1.40(+2.93 dBFS)之高。从1:00左右开始,就会疯狂爆音,用手机+耳机听时最明显。因此,Advanced limiter就是非常必要的了。我对比了下开启Advanced limiter的版本和原版,完全听不出区别(毕竟音量大于1的部分只是极小的spike,频段可能更不是人耳敏感的部分),可见这个limiter的效果比起一般的动态压缩要好得多,也解除了我之前的一大顾虑。

不过在研究过程中我发现一个有趣的事实:AAC(m4a)这个格式居然可以保存大于1的数值!也就是说,我上面发这个+过9.5dB的音频文件,其实并没有损失任何信息或者削波——超过FS的1.4的peak也完整地记录在了音频中。这说明了什么呢?如果你的播放流程在输送到DAC之前有足够的衰减处理(例如软件中的波形层面的音量降低,但包含音响上的Analog的音量旋钮),又或者你的DAC/Analog设备足够专业,留有headroom支持超过1的波形,其实并不会产生削波/爆音。对应到电脑,foobar2000里的volume就是个不错的例子(但是别忘了上文提到的Win7的自带的limiter适用过早的bug,所以避免);对应手机端,根据我的观察,至少安卓系统的音量是不行的(不过安卓的音频处理一直都臭名昭著):如果仅仅靠调整系统的媒体音量,该爆音的还是爆(不清楚安卓的系统音量具体原理是数字上衰减波形还是模拟级)。不过,foobar2000 mobile中有个单独的volume设置,通过那个,或者里面带的RG设置的pre-amp,可以做到同响度情况下(即先用foobar2000 mobile的音量降低几个dB,再在系统音量里稍微开大一点达到同样响度)完美无爆音播放上面那个m4a文件。

不过这个用起来其实也有颇多不便:第一个不便是foobar2000 mobile的音量设置……他有bug。每次切歌,音量就会回归到0dB,即使界面里显示的还是你的设置。另外还是上面说的问题了,如果你降了几个dB,那输出不够这老问题又来了。所以,我最终还是经过权衡选择了转换时选择高响度水平+Advanced limiter的方案。当然还有第三个方案:转换时不加Advanced limiter(利用m4a的特性保留超过1的数值),但在播放时靠foobar2000 mobile自带的DSP即时加。这样可以最大限度保存动态范围,以后这些mp4拷贝到电脑上听时还可以还原。我现在还在想要不要全面转成这样——因为如果这么做,就表示了我就锁死只能用foobar2000 mobile当手机播放器了,这方面有点犹豫。

前面说了AAC(m4a)可以保存高于full scale的数值,那相对地WAV、FLAC和APE就不行了,如果你转换过程中增益到超过1,最终出来的文件会被削波到1。当然FLAC/APE之类的是为了完美呈现WAV而故意这么设置的吧,大概。MP3则比较奇怪,还是上面那个歌,转换之后会出来个peak为1.075的玩意…大概和MP3算法有关吧。另外每个的平均响度也会细微的差别,理论上来讲很自然AAC会高一些(毕竟没削波),虽然差别很小就是了。

qq%e6%88%aa%e5%9b%be20170221233307
利用RG扫描来查看peak和平均响度。因为Gain是负值,所以绝对值越大说明响度越大。音频全部通过原始wav文件+硬编码进(RG+增益9.5dB)的方式逐一生成

所以很显然地,如果你是转成了FLAC之类的已经会直接削波的格式,即使上面那个很复杂的操作也没法拯救你这音频了,怎么放都会爆音,万万要避免。

嗯,最后附一个几种流程的图示吧。三脚猫ps功夫不要笑话(点击大图)。

blog.png

上面的是最终响度=RG目标响度的workflow,优点是基本无损,缺点是输出比较低。目前我在电脑和UPnP媒体库输送到手机两种回放方式时使用。可以看到新歌直接降低-9.5dB(图里写成9了…),老歌直接RG,两者会获得一个相对一致的响度,同时不破坏老歌的动态范围。注意这里的-9.5dB和RG都是纯粹回放时加的,原始音频是不经过修改的。

下面的是方法2,即最终响度=新歌平均响度的workflow。我在转换歌曲到单独m4a文件时使用此方法。优点是兼容性强,和大多数市面上现成的歌曲文件响度一致;缺点自然是对于高动态的老歌峰值会溢出。为了防止削波,如果是即时回放或转换成支持超过FS的格式(AAC/m4a)时,可以通过再加个digital音量调整拯救(这种情况下就依然无损动态范围),或者如图所示干脆直接最后加个可选的Advance limiter进去(可以是转换时的硬编码,可以是回放的DSP)。对于不支持超过FS的音频格式,这大概是唯一可以接受的转换方案)。

ReplayGain、音量规格化与实战应用

又一个兔子洞(笑)。

ReplayGain和响度

故事开始前,大概得先讲讲到底什么是ReplayGain,以及为什么我们需要它。

响度规格化

一言以蔽之,ReplayGain是用来规格化(Normalize)音乐,或者说数字音频文件,的响度(Loudness)的。但是这里要非常小心术语,因为规格化这个词有很多不同的应用。控制动态范围——即“最响”和“最安静”之间的差别,这个有时候也叫作“规格化”(例如在PotPlayer中),但是在音频世界里,更常用的说法叫“压缩”(Compress)。可以看到,一个音频在单纯经过“压缩”之后,其平均响度可能并不会变,但动态范围会变小。这可以解决诸如“电影声效太大,人声小到听不见”之类的问题(但是注意:这并不是一个“正确”的解决方案。至少对我个人来讲,多数动态压缩滤镜听感极差),不过在混音界 Compressor 更常用的用法是指控制输出的范围,便于后期处理。可以看到,一个音频如果经过压缩,其声音特征就改变了。比如艺术家的本意就是这里是悄悄话,那里是爆炸声,结果压缩之后两者的差距就缩小了。因此,在播放音乐时,一般是不应该引入压缩的。

响度规格化,包括ReplayGain,则不同,它要解决的是这么一个问题:不同音轨之间的平均响度差别很大,用户播放时需要不停地调整音量来获得一个相对舒适的响度。在经过响度规格化之后,一个音轨本身的动态范围理想情况下应该不变,但是会整体地提升或者降低,从而达到音轨于音轨之间相对一致的响度。

既然知道了目标,那实现原理其实就不难理解:只要找到一种测量平均响度的方法,然后分别测量每个音轨的响度,然后再设定一个标准(Reference),比较两者不同,补上差值就行了。

不过这里有俩问题:一个是如何测量响度,一个拿什么当标准。ReplayGain作为音量规格化的一种实现,其实就是解决了这两个问题。

响度的测量

我之前一直以为,ReplayGain的响度测量其实就是单纯测量了一下音频信号的平均强度。

这里稍微赘述一下,(解码后的)音频信号其实表示起来非常简单,就俩量:一个是采样率(每秒多少个点,一般音频是44100 Hz),一个就是按照该采样间隔一字排开的一组时序的数据,每个代表当时的信号强度(当然,存储的时候这系列数据是逐个量化成一定位长的二进制)。至于强度的的范围,有多种表示方式,不过最常用的是是[-1, 1]。绝对值越大,理论上声音也就越响。其中最大的绝对值,一般叫做“Full Scale”,缩写FS。一个点的值既可以写成单纯的一个数字,也可以用dB来表示,例如如果是0.5,就可以写成-6.0206 dB relative to full scale,一般简称dBFS。这里有个计算器可以用(注意这里针对场量和功率量中dB的算法不同,这里应该用和电压、电流一样的场量的算法)。

说回“平均强度”。学过信号与处理的应该都知道(虽然我并没学过w),在这里是测量信号的方均根(Root mean square,RMS),而不是平均值或者绝对值平均。RMS这个度量,可以更好地反映比较不同音轨之间的“能量”差别。例如,一个幅值为1的正弦波的RMS就是 0.7071,这个值也可以写成dbFS的形式,这里就是-3.0103 dBFS(这个值很重要,我们后面还会遇到)。它的能量,就应该和峰值为0.7071的方波一致。同理,音乐文件多是多个波形(多为正弦波)的叠加,最简单的方法度量其“能量”的方法就是对所有的点求RMS。

公平地讲,用音频文件的RMS(物理特性)来表示响度,不算是个太坏的方式。响度和能量,两者本身就是非常相关的。不过由于人的听觉感应曲线并不是直线一根,对于不同频率的声音,敏感程度不同,还是应该有更先进的模型。“Loudness”这个词本身的含义其实就包含了人的主观感应在里面的,如果单纯讲物理特性一般会有其他的术语,这个一会再说。

ReplayGain的实现

关于ReplayGain的具体实现方式,其实在当年(2001年?)的Proposal里面讲得很清楚(这是另外一个版本,排版稍微好一点)。总体而言,分为三步:

  1. 先利用等响度曲线,通过滤镜对不同的频率部分的进行修正,给与不同的权重;
  2. 再讲音频分为每个50ms的段落,测量每段的的RMS;
  3. 将所有段落的RMS进行排序,然后选取位于95%处的RMS,作为整个音频的“代表RMS”。在这步作者的理论是,人类的感知响度其实和其中比较响的部分有关,而不是整个音轨的RMS。例如对于对话类型的音频,其中大部分时间都是空白因此总体RMS会很低,但是人只对有声音的地方敏感,所以并不会这么觉得。

最后,只要把这个代表RMS的dBFS值和标准进行比较,然后增加/减少其中的差值就行了。可以看到,整个过程很好理解,而且其本质上还是基于RMS。另外从算法中显然可见,如果放大整个音轨几个dB,其“代表RMS”也会提升对应的dB,所以要调整某个音频的响度,也非常地简单。

能量、声压、响度、RMS的关系

这里再废言几句。我们前面已经说了RMS是对音轨“平均”能量的一种度量,于是这里顺便讲讲感知响度/声压/能量的关系。说到声音大小,最常听说的说法就是“分贝”。其实准确而言,这里的分贝是dB SPL,即声压级(Sound pressure level)。我们知道dB是一个比较量,这里就是指相对于一个标准化了的基准声压,20 μPa(有时称为听阈)的dB值。声压级是个场量,所以20 dB = 10倍。而声音的能量,一般可以用声音能量密度(Sound intensity)或声功率(Sound power)(这两者之间就差了一个面积)来表示。这是另外一个不错的度量声音强度的方法。其和声压的对应关系是:声音能量密度扩大100倍,声压扩大10倍。不过由于声音能量密度和声功率都是功率量,所以如果也表示成级(Level)的话,是每扩大10倍=10 dB,或者20 dB等于变大100倍。因此,假设一个基准声音为1 [单位]的声压和1 [单位]的声音能量密度,那么一个有20 dB声压级的声音也正好会有20 dB的声音能量密度级——不过绝对数值上,分别会是10 [单位] 声压和100 [单位] 声音能量密度。

回到RMS的话,可以观察到,RMS的量纲是和波形的点的数值一致的场量(因为又开方过了),而非功率量。因此,和RMS对应的其实应该是声压级——也就是说,两个RMS差了10倍的音频,其“声压级”会差10倍(假设你的音响完全无其他损耗),“能量密度”或“功率”则其实应该是差了100倍。不过和上面一样,如果都用dB表示,数值则都是一样的,20dB。也就是说如果你整体提升一个音轨所有点的值2 dB,其RMS也会提升2dB(自己算算就知道),声压级和声能密度级也都会提升2dB。

到此为止,都是纯粹的物理量。牵扯到(感知)响度就复杂起来。说到响度,其实搜了一下相关的文献以外地少,连维基百科都说的很模糊。网上比较常见的是sengpielaudio的一系列文章([1][2]),这里也以此为基准。我们知道,人的各种感知和对应的物理强度,一般都是呈指数级关系(Stevens’ power law)。其中比较有名的是视觉(对光的敏感程度),这个话题我原来在知乎谈过一次,什么时候也可以整理一下发个blog。听觉自然也不例外,但是“指数级”的指数到底是多少呢?

一般而言,长度不过短、频率适中的声音,可以经验地认为声压级(SPL)每扩大10倍(即20dB),感知响度扩大4倍。也就是说,响度L正比于声压SP^0.6。如果换成声音能量密度,那就是L正比于SI^0.5*0.6=SI^0.3(因为声压和声能密度是开方关系)。换句话说,就是每10dB,响度翻倍(别忘了对于SI和SP,dB数是一样的)。

这里无耻地盗一张图来说明。

Loudness - Sound Pressure - Sound Intensity
响度/声压/声音能量密度对应表

Source:http://www.sengpielaudio.com/calculator-levelchange.htm

OK,既然我们知道了响度至少和能量、声压、甚至常说的dB数都不是线性而是指数关系,那么为啥我们还用RMS?仔细想想就会发现,我们的目的只有一个:使音量保持在一个水平线上。所以,不论他们之间的关系是啥,线性还是不线性,只要都是正相关的就可以:如果俩文件的RMS(或者是ReplayGain算出来的“代表RMS”)经过加减dB之后相同,那至少我们可以说,他们的响度也类似。毕竟,我们并不需要准确知道“A比B响多少”。其实就像我们说RMS是音频“能量”的代表,但也不是RMS大10倍能量就大10倍(而是100倍)。这就好比我们用摄氏度表示物体的冷热程度,你也不能说10度比1度热10倍一样(即使你换算成K,这种说法也不一定成立)。但是如果仅用来比较两者孰大孰小,就没问题。

响度的基准

现在,我们解决了第一个问题——如何测量响度。第二个问题自然就是选取标准。在当时,音响行业并没有任何相应的规范,于是RG的作者从电影行业——电影电视工程师协会(SMPTE)那里借来了一个规范:RMS是-20 dBFS的粉噪音,应该(在听众的位置上)呈现为83dB SPL。仔细解读这句话的话,你会发现它其实讲的是信号强度和实际声压的对应关系。你也可以说成“-15 dBFS的粉噪音应该呈现为88dB SPL”,关系依然不变。不过,这两个数也不能认为是任意选取的——粉噪音用-20 dBFS,是因为这个RMS级别的声音在电影、电视中比较典型,所谓“Alignment level”。“平均”强度是-20 dBFS,意味着在单侧有着20 dB的动态空间(即“headroom”)。这个强度的声音会被呈现为83dB SPL,大概也是认为83dB SPL是一个比较舒适的数值(这里有一份解读)。不过这里要注意,这个标准的本意是电影院用的,而电影院的音量,观众是不可调的,所以有一个规定的声压大小(83 dB SPL)很有意义。但是换成家庭媒体,意义就不大了:用户无论是在软件还是硬件,都有额外的Gain或者Volume可以调,这个数字并无太大意义。真正有意义的,是前半部分:-20 dBFS。

但是搞笑之处在于,ReplayGain自己觉得这个数太小(即平均音量太小),而且一般音乐也用不着这么大的headroom,于是自行加了6dB,变成-14 dbFS RMS粉噪音——作为RG的目标。那么,如果假设对应关系不变,那自然这个声音在理想的电影院环境里也就会被呈现为89 dB SPL了。这也就是你为什么会在各种地方看到,RG的目标是89 dB这种说法。但是可以看到,“89 dB”这个数字本身已经并没有任何实际意义了:在RG处理音轨的时候,纯粹是根据上面三步走,算出一个音轨的代表RMS,然后和-14 dbFS RMS的粉噪音的代表RMS比较而已。

事实上,RG1.0的原始代码都可以在这里下到,是MATLAB写的。里面也包括了一个ref_pink.wav文件,不过这还个是-20 dBFS RMS的,没有修改成-14 dBFS RMS。由于代码非常陈旧(2001年的…),MATLAB的一些函数已经发生了变化。所以,我进行了一些修改,发了个能用的版本在GitHub。对ref_pink.wav进行RG,可以看到得出的reference vRMS(前面我叫作“代表RMS”的那个东西)是-31.5。也就是说,如果是一个-14 dBFS RMS的粉噪音,就应是-25.5了。在真正的RG的实现中,无论是89/83还是-14/-20,其实都不需要参与计算,只要有这个-31.5/-25.5在就可以了。用同样的函数处理随便一个音频,得到其对应的vRMS为-14.9,也就是说我们需要降低16.6 dB,来使得其vRMS和reference(粉噪音)一致(如果换成-14 dBFS,那就是降低10.6dB)。

dBFS RMS的定义

这里又㕛叒叕得插播一段。如果你好奇地计算一下那个ref_pink.wav的RMS:

[y, Fs] = audioread(‘ref_pink.wav’);
myrms=rms(y);
valueDBFS = 20*log10(abs(myrms))

会发现……他并不是-20 dBFS,而是-23.0103 dBFS。这又是怎么回事?原来,dbFS又有“传统定义”和“数学定义”之分。所谓数学定义,就是我们这里计算的。但是在音响业中,经常用另外一种传统定义:因为音频大多是正弦波的叠加,故所谓的Full scale并无法达到。真正能达到的(在不发生削波的前提下),是一个幅值为1的正弦波的RMS,也就是0.7071。是不是觉得眼熟?前面出现过。这个数字换算成相对于数学上的Full sacle(通过方波可以达到),就刚好是-3.0103 dB。所以,经常情况下,业内说的“Full scale”,或者dBFS,是以这个值作为基准(0 dB)的。因此,一个数学上是-23.0103 dBFS的音频,在传统定义下,就变成了-20 dBFS了。这个定义一般只用于讨论RMS,在讨论波形上某个点、或者峰值时,FS依然是以1为基准。

ReplayGain——实战篇

OK,在彻底厘清了ReplayGain的今生前世,和相关的一些容易混淆的概念,我们终于可以进入实际应用,以及其中会遇到的问题——这也正是我要写此文的初衷。

响度竞赛

前面说过RG的目的是音量规格化,那就么具体到音乐,其问题来自于从90年代开始的“响度竞赛”。简单来说,商业公司发现,如果一个音轨明显比别人音量大,观众会心理上觉得更好听。因此,混音业开始悄悄地渐渐提升音频的响度,以求和别人一起放时“更突出”。

要提升响度,第一步自然是“maximize”——也就是把增益整个音频直到峰值(peak)达到1(或者0 dBFS)。不过要知道,几乎所有的商业混音本身就已经这么做了,那自然就没有上升空间。要进一步提高响度,唯有压缩动态范围——从而可以得到更高的平均响度(RMS)。因此,响度竞赛最大的影响其实并不只是响度增加,而是歌曲的动态范围也减小,起伏变小了(这里有一篇蛮长的文章,认为响度竞赛并没有导致动态范围减少。我没细看,不过在RMS level和峰值的差值这个语境下,动态范围变小是不争的事实)。

举例而言,おニャン子クラブ在1985年发行的专辑《KICK OFF》,随便选取一轨“真赤な自転車”,其RMS分别是(左右声道)[-19.6993  -20.3342](此处为“数学定义的”RMS,下同);如果拿它去跑ReplayGain,结果是-3.7319 dB(-14 dBFS粉噪音为基准,下同)。至于其峰值,是0.918945(或-0.7342 dBFS),甚至都没有max’d out(不过整张专辑的峰值确实是1就是了),单边动态范围约是19dB左右。

而前年发售的“ときめきポポロン♪”,RMS是[-11.5458  -11.5820],足足比上面的大了快9dB!峰值是1,也就是说从RMS到峰值的单边动态范围,只有11dB。如果拿这个去跑RG,算出来需要降低9.7776 dB。

在foobar2000中使用ReplayGain

可以看到,如果要想平衡所有的音量,最简单的办法当然全部都跑一遍RG,那自然也就都均衡了。不过这有俩问题:

  1. 跑所有的音乐实在是太不现实了。我本地的音乐足足有8 week+长,全部都跑一边的话大概要累死,而且这个计算其实还是挺慢的。
  2. 从上面的计算可以看到,RG默认的reference,实在是响度太低了。连以今天的标准来说声音小到不行的“真赤な自転車”,居然计算出来的是-3.7 dB,也就是还要再小3.7 dB!虽然我们可以通过其他途径再对结果进行增益,例如音量滑块或者音响的音量旋钮,但是这样的话就很难掌握foobar2000和其他程序相互的音量差。

然而,foobar2000内置的增益的目标响度是不可调的[*]。因此,我想到一种折衷的方法,利用foobar2000带的pre-amp选项。Pre-amp是一个RG之外的额外选项,可以在RG之后再加减一个dB,可以分别给有RG信息的音轨和无RG信息的音轨的设置不同的数值。我先选取大量近年的音乐,也就是音量合适不会太小、不用调整的音乐,然后全部视为一个整体进行RG计算。算出来的结果,大约是-9.5 dB。也就是说,近年的音乐的vRMS比RG的基准,平均来说高了9.5 dB。我们这里记住这个数,但是取消不保存,因为这些音乐并不需要任何处理。相反,对于那些音量偏小的老CD,我们先去真的跑RG:跑完之后的结果自然是一个一致、但是较低的音量。不过,我们只需要在pre-amp里设为+9.5 dB,所有的音乐就一样响了。而且,因为老CD毕竟是少数,这样也不用跑太多次。

[*] Foobar2000的RG的目标(-18 LUFS)是不能调的。在选项的高级里,确实倒有个选项可以设target volume level (dB)(默认89,呃至于这个数字怎么来的前面说了,这里你就理解为你修改后的数值和89的差值加到那个-18 LUFS就是),但是那个只对文件转换有用,对播放器内播放没用。

Clipping 和 True peak

和所有的增益有关的东西都需要注意一个点,就是clipping(削波)。我们知道信号的极限就是0 dBFS,如果你通过上述的RG+pre-amp之后,峰值超过了0,那就会被削波——这是我们不愿意看到的。事实上,前面也说了,80年代的音乐虽然RMS很低,但是峰值依然也是接近1的(毕竟,几乎所有的商业CD,出厂前都会max’d out)。经过我们上面的RG+pre-amp的处理,很容易地就超过了1。例如,“真赤な自転車”的峰值是-0.7342 dB,加上RG的-3.7 dB,和pre-amp的+9.5 dB,峰值就变成了+5.1 dB。这也是为什么RG同时也会扫描并且在元数据里记录峰值,便于事后再降低(fb2k里有选项)来防止clipping的缘故。

虽说一般而言,对少数峰值的削波,人耳并不敏感,不过还是尽量要避免这种情况。但是别忘了,在音频输出到mixer之前,还要经过“音量”的计算。一般而言,我的音量都设在-10到-20 dB之间,因此理论上来讲,应该不会有任何削波的问题。

呃,其实说到峰值和削波,还得插播一段讲讲true peak的问题。如果把数字形式的音乐(即一串数字)还原成模拟信号,相当于从一堆离散的采样点还原出波形。根据采样定理,在遵守原始的频带限制(频率不超过采样频率的一半)下,每一组离散点只能还原出唯一的波形信号(注:非科班出身的弊端又体现了,我原来一直没能真正理解采样定理。直到今天听到这句把常见说法“2倍于信号的频率采样可以完美采样”反过来的说法才豁然开朗。推荐看Xiph.org的这个视频,说的非常清楚,是科普的典范)。但是,能完美还原波形,不代表波形中的峰值就在我们的采样点中会出现(所以我上面说信号的极限就是0 dBFS也不太准确):

modified signal with ripple
曲线是过采样点的唯一的波形,但是峰值高于采样点

Source: https://techblog.izotope.com/2015/08/24/true-peak-detection/

因此,如果我们仅仅测试采样点的数值,来选取peak,可能会相差甚远。因此,更高级的峰值检测,一般会把信号还原之后再过采样2x甚至4x,从而来找到更准确的峰值。foobar2000的RG也自带oversample factor的选项,在advanced里的tools里。至于这个峰值搞这么准确到底有什么用(毕竟,我们的采样点本身并没有溢出嘛),就要牵扯到DAC了,这里就不赘述。

Windows mixer 的隐藏 Limiter 问题

不过,理论和实践总是不一样的。在我用上述方案播放音乐时,每当放到那些经过RG+pre-amp的老歌的大动态区域,总有一种很奇怪的感觉——嗯对,就是像被动态压缩过一样,听起来非常不适。百思不得其解之下,我决定把某首歌的RG和pre-amp硬编码进去(也就是说,彻底地修改波形,合成进去RG和pre-amp。RG本身则只是通过元数据的方法,并不真的修改波形文件本身)。虽然这样自然也会产生削波了,不过播放时的最终输出响度应该和有RG tag的原始文件一致。那么,现在播放这俩文件(原始文件+RG tag+re-amp)和转码后的文件,我惊奇地发现,听上去响度居然不一致:原始文件+RG+pre-amp的组合,要明显的小很多。

在实在没有思路的情况下,我斗胆去Fb2k的论坛发了一贴(要知道这种论坛,一般大牛脾气都不好)。不过惊喜地是,居然得到了答案。

原来,Windows的默认音频输出(Direct Sound,DS)混音器,有一个内置的“Limiter”。当输出音频超过一定值(这个值具体是多少不清楚,一说是0 dBFS)时,Windows会自行降低响度来防止削波。至于降低的方式不明,不过从我的感觉上来讲,不是整体降低音量,应该是类似于动态压缩的方式,即在一定的buffer内遇到超过1的峰值就降低,算法不是很高级从而产生不适感。

前面说过,考虑了音量之后明明根本不会超过0 dBFS才对。但是Foobar2000现在是用Windows自带的mixer来处理音量的(你改fb2k的音量,会发现右下角音量控制里面的foobar程序的音量也会跟着改),结果这个Limiter作用的时间早于音量(会检测音量调整前的峰值),结果就导致了这个现象。至于我自己压制的那个对比的文件,因为溢出的部分已经削波削掉了,自然就不会被Windows限制。不过,这个(limiter作用于音量前的问题)似乎是个Windows的bug:只有Win 7或者Win 8.1会有这个问题,在Win 10中,已经得到修复。另外,如果使用WASAPI之类的输出绕过DS,就完全不会触发这个Limiter,无论你真的溢出了没。

既然知道了原理,那解决方案也很显然了:我把所有没有RG信息的pre-amp设成-9.5 dB,有RG的设为0 dB,就可以保证两者依然均衡;但是总体音量偏小的问题,则只能通过把foobar的音量提升到0到-10 dB,还好之前留的余量足。其实,我也试过有RG信息的设成+3 dB(另外一个对应设成-6.5 dB),好像也不会被限制(虽然明明有少许溢出0 dbFS的peak),这就搞不明白了。

不过,往移动设备上转换的时候,我依然用的是新音乐原封不动、老音乐硬编码进RG+9.5 dB的方式。否则用我的解决方案播放转换过的文件,音量反而会变小了。虽然这样做可能会导致削波(因为转换时自然不会考虑音量进去),不过移动设备听不太出来。更好的方案应该是再加一层DSP,用fb2k自带的Advanced Limiter,把超过的部分智能地调整到0 dBFS以内;虽然有点像动态压缩,但是算法更高级,完全没有一般动态压缩的不适感。

顺便一提,根据某个帖子的说法,一般动态压缩的不适感似乎是来源于压缩“释放”得不够快,或者开始得太早的缘故:例如,你有一个音轨一直是很小声突然一个巨响,然后又恢复到很小声。我们想要压缩的自然是这个巨响,但是一般的动态压缩在检测到巨响(会有一个buffer预先检测)之后,会释放的比较慢,从而导致后面紧接着的“小声”部分会有个从小变大的过程,听起来就很不舒适了。

ReplayGain 2.0

故事到此,似乎也就告一段落。但是别急,还有最后一个爆炸性消息:fb2k的“ReplayGain”,并不(再)是ReplayGain。或者准确地说,并不再是原始的、也就是上面提到的算法了。我也是无意发现这件事的:你把之前我提过的ref_pink.wav文件放进foobar2000跑RG,因为是个-20dBFS RMS的而后来的RG标准是-14(见前文),理论上应该跑出来+6dB对不?结果却是:+2.35 dB

这又是怎么回事?!原来在2011年,欧洲广播联盟(EBU)提出了一个新规范,EBU R128解读),其中对响度规格化进行了规范。其中提出,响度规格化的目标应为-23 LUFS。LUFS又称LKFS,是ITU-R BS.1770中详细规定的一种测量响度的算法。比起RG,这好歹是一个正儿八经的行业协会,经过多年研究得出的规范,所以很快,foobar2000就修改了RG的算法(又称RG2.0)为ITU-R BS.1770中的算法了。唯一的区别是,为了和原来的RG保持在相当的响度,又“擅自”把目标提升了一些,改成了-18 LUFS。注意这里的“相当的响度”,是基于对大量音乐分析得出的(另参见当年的各种对比),而并不是把原始的pink噪音拿来分析的;事实上,原始的pink噪音(-14 RMS dBFS版)算出来是 -15.36 LUFS,响于-18。(如果想自己测试要注意,我发现bs1770gain对单声道处理和fb2k不同,于是我手动复制了一份声道把它变成了双声道先)。民间也有很多对这个的实现,例如r128gain (后改名为 bs1770gain,毕竟讲道理,算法的部分是bs1770规定的,而不是r128)、libebur128(fb2k就是用这个实现修改而成)等。

另外,除了直接使用ReplayGain之外,fb2k论坛的版主之一kode54开发了一个DSP插件,foo_r129norm,可以即时地将音轨的音量规格化。也就是说,如果用了个这个插件,完全傻瓜化,根本不需要单独去给音轨跑RG啦。不过,考虑到转换到移动设备的需求,我暂时并没有用它。顺便,DSP的处理是在RG之后的,也就是说pre-amp的选项就没效了。你要想再在此基础上提升一个音量,得用EQ整体加个dB咯。

结语

本文断断续续写了2天,阅读了大量的资料。不过可以说是很满足的,基本中间遇到的问题都算是想通了。中间看过的帖,我尽量都用链接插入到文章中了,算是便于自己以后查找。

什么,foo_infobox居然有可用的修改版?!

最新更新:好吧,这个foo_infobox还是有问题,经常导致报C++ runtime error导致fb2k崩溃,所以各位还是不要用了。

我居然一直都不知道!太好了,这下foobar 1.x唯一的遗憾也解决了唔哈哈哈。

另外字符集转换的问题,也有1.x可用的版本——官网就有,叫foo_chacon。但是官网那个我不好使,不知道是不是因为是中文版fb的缘故。于是我也去找了个汉化版,就能用了。

附2插件下载:skydrive

附记:foobar2000中文论坛有一个极为奇葩的问题,部分用户帖子列表一页只有一帖。是的你没看错,一帖。最奇葩的是这个问题从去年就开始有了。如果你登出,游客浏览,却是正常的。一个如此严重的问题1年都没解决,而站长的说法是

论坛只是复活了而已,以前论坛出现的问题并还没有解决,因为老烟还在找解决方法,有空在这里乱吐槽,还不如省点心去喝杯水,如果真有那么好解决的话,还真轮不到你来吐槽。另外,坛子倒不倒跟这个一点屁关系都没。

——Asion

呵呵。