MPC-HC设置中输出项里，右下的DirectShow音频里选择MPC Audio Renderer，这样MPC就会使用WASAPI独占输出了。这样就避免了Win7那个共享模式采样率带来的重采样问题了呀！

而且我更加悲剧的发现，从r1297开始就添加了这个功能了。我靠我究竟是在干什么啊，这么久都没注意到。

T T

测试前先稍微讲一下影响渲染器品质的几个主要因素。
1、Resize算法
2、Upchroma算法
我的测试并没有涉及到Resize之后的品质，所以第一条就略过不谈了，我们重点来说第二条。

众所周知，视频文件并非使用RGB，而是YUV。在YUV当中，使用的最多的则是YV12，也就是YUV4:2:0。对于YV12来说，它的亮度分辨率为1，色度分辨率为1/2。举例来说，对于一个720P的视频，它的亮度分辨率是1280×720，但是色度分辨率仅为640×360。这也就是为什么把一个RGB转到YV12之后，体积会变小的原因。再往深里说，为什么YV12要抛弃一半的色度数据而保留全部的亮度数据呢？这是由于人眼的特性是对亮度敏感，对色度不敏感而决定的。那么再顺便说个题外话，从RGB转到YUV，是要经过一系列计算的，那么这个计算的方式，也就是算法的不同，会导致结果的不同。我们常说的BT.601、BT.709等等指的就是RGB <-> YUV转换时不同的算法。在国际标准中，对于SD以及SD以下的视频，是使用601，而HD以及更高分辨率则使用709。换句话说，DVD应该用601，720和1080应该用709。

扯的有点远了，回到主题上来。由于YV12的色度分辨率仅有1/2，所以在播放的时候，需要把这1/2变成1才行。那么这个从1/2变到1的过程就是“无中生有”了。这个“无中生有”指的就是第二条Upchroma算法，这个算法在很大程度上影响了视频的播放质量。

那么测试开始
系统：Win7 Pro x64
显卡：GeForce 9800GT
播放器：MPC-HC 1.3.1337.0
解码器：ffdshow
色彩输入：YV12
色彩输出：YV12

我们首先需要一个用来测试的原始视频。我拜托风儿做了一个分辨率是1280×720的测试用图片，然后将这个图片作为原始素材导入AVS生成了一段测试用视频。

原始图片 点击放大

ImageSource(”COLOR.bmp”,end=59)
Assumefps(”ntsc_video”)
ConverttoYV12(matrix=”rec709″)

以上内容为AVS脚本。
大概内容是，将Color.bmp文件作为图像，生成60帧。然后将帧率指定为NTSC制式的标准video帧率，也就是29.97，最后将RGB转换到YV12，使用709并将色彩范围压缩到16-235。
之后我使用VDM打开这个AVS脚本，把原始的YV12视频流直接保存出来，没有经过任何压缩。这样我们就得到了一个内容是YV12的测试用视频，接下来就要用这个视频来看各个渲染器的效果了。

VMR9

EVR

Haali

madVR

通过观察可以发现，在灰阶显示效果上，madVR以绝对的优势胜过其他的渲染器，Haali的表现也强于VMR和EVR。madVR的SoftCubic100带来的效果真不是盖的，难怪madshi一直在讲，madVR使用了效果最牛X的Upchroma算法。不过在彩色过度上，我的眼睛还真没看出什么太大的差别来……囧
排名的话，madVR > Haali > EVR ≈ VMR

madVR的确给了我们无与伦比的回放品质，但是正如我前面文章中讲过的一样，madVR的缺点也同样明显。在提供了高品质的同时，它无法给我们带来便利的功能。而且它对显卡性能要求也很高。是否要坚持使用madVR，还要各位自己决定了。

madVR v0.11

* 修复: 亮度重采样设置无法正确的读取/保存
* 修复: 在某些电脑上开始播放视频前会停滞若干秒
* 升级 cr3dlut 至 v2.2

从0.11的changelog中可以发现，那个无法保存Resample算法的该死bug终于被修复了。

接下来我稍微对0.11进行了一下简单的测试，使用的视频源都是我自己的Rip，以下为简单的测试结果。

系统：Win7 Pro x64
播放器：MPC-HC 1.3.1335.0
显卡：GeForce 9800GT

1、Resample算法无法保存的Bug确实被修复了
2、播放DVD会出现「Query unknown PropSet」的错误提示，但是可以继续播放下去，菜单可选
3、interlaced视频无法启用硬件Deinterlacer
4、MPC-HC内建字幕引擎不起作用，需要使用VobSub或者ffdshow来挂载字幕

目前测试的结果就这样。就品质来说madVR仍旧在我用过的渲染器中排第一，但是说到兼容性和功能，就不那么乐观了。对于希望搭建HTPC平台的朋友，这个渲染器不会是一个明智的选择。首先它对显卡的要求很高，其次它现在不支持并且将来也不会支持DXVA硬解，最后他也当然不支持显卡对视频的硬件处理效果（比如nVidia的PureVideo Deinterlacer）。

对于那些不追求功能只要求品质的发烧友来说，madVR还是可以尝试一下的。

● ESI中国官网新闻链接
● ESI全球官网驱动下载
● MAYA44驱动下载

啊啊，ESI你终于更新新驱动了，真是等的我好苦啊！
从用上Win7开始，MAYA44在Win7下用Vista的驱动，工作的就不太正常。经常出现各种莫名其妙的RP问题。比如MME/WDM录音不能啊，有时会莫名其妙的爆音啊，AA保持ASIO接口关闭之后无法再次打开啊之类的种种莫名其妙的问题，都随着这次新驱动的发布一扫而光。
用起来真可谓神清气爽啊，啊哈哈哈哈。
我的MAYA44现在终于可以在Win7下完美工作了，对于把整个平台彻底转移到Win7上我已经没有任何顾虑了。
再见了，XP（虽然我还在虚拟机里用它 XD）

这个这个这个就是这个东西！这个东西到底是怎么起作用的我完全搞不清楚啦！总之我进行了一系列的测试！

上面的单选，默认是选择的第一个，就是[通过视频播放器设置]，选这个的时候下面的一切都是不可调整的，这样就看视频播放器那边要怎么办了。如果选了[通过NVIDIA设置]，则下面的选项变成可选状态，视频将通过这里进行颜色等等的调整。

然而！对于不同的渲染器，结果会是什么样子呢！

进行测试的渲染器有两个，一个是VMR9，一个是EVR。然后根据我前文的理论，VMR9在XP下测试，EVR在Win7下测试。测试的标准，是我的眼睛，有异议的先闭嘴 XD

好吧现在开始，先进行VMR9的测试。测试播放器一律使用MPC-HC

VMR9 无渲染：
选择[通过视频播放器设置]，画面颜色为[16-235]
选择[通过NVIDIA设置]，下面的[动态范围]调节有效，调整到[完全 (0-255)]可以得到正确颜色

EVR：
选择[通过视频播放器设置]，画面颜色为[0-255]
选择[通过NVIDIA设置]，下面的[动态范围]调节有效，调整到[完全 (0-255)]可以得到正确颜色

结论：
在XP的VMR9下，这个渲染器自己是不会干把颜色扩张到0-255这个活的，要让它有正确颜色有两种方法。1是控制面板里这么调，2是用MPC的shader功能。
在Win7的EVR下，EVR是会自动进行颜色扩张的，当然你也可以通过NV的控制面板这样指定得到正确的颜色。

记得之前和茉莉曾经讨论过TMT是用的什么渲染器，我当时的意见是，因为NV控制面板里的这个选项对TMT的画面造成了影响，所以TMT用的应该是Overlay，而且TMT不能直接被QQ截图。但是现在看来这个观点可能有点站不住脚了，NV控制面板里的这个选项对VMR9和EVR同样会有效果（Overlay是必然有效果的，Haali和MadVR我没有测试，不过应该是无效），我太lag了，才发现这个……

所以说，如果打算用微软提供的VMR9或者EVR，我个人还是推荐把NV驱动面板这里调节到完全。

Adds Windows Audio Session API exclusive mode output support, allowing bit-exact output and muting all other sounds on Windows Vista systems. Windows Vista SP1 or newer required.
Version 2.0 highlights: fixed incompatibility with Windows 7; improved compatibility with certain soundcards.
Version 2.1 highlights: fixed glitch-on-seek bug.

这是WASAPI的changelog，支持Win7并且修正了bug，推荐使用Vista或者Win7的朋友使用最新的WASAPI来进行输出。

顺便附上下载地址好了：

http://www.foobar2000.org/?page=Download

扫盲：

那么WASAPI到底是啥东西呢？我引用一篇老文章给做个简单的解释。

Vista是微软近几年来，最大的操作系统改版。而在这次的新版本中，音效架构也出现了重大的变革，过去Windows XP的音效层级，除了应用程序之外，以下便属于核心模式（Kernel Mode）。这样的作法比较容易因为部分层级出错，就影响到整体的音效处理，因此在Vista上把过去核心模式层级的程序模块，大部分都移到使用者模式的层级中，如此一来可以增加系统稳定度，亦可以方便程序除错。Vista的音效架构起了大幅度的变化，主要的核心模式层级只剩下音效驱动的部分，而过去微软所制定出来的MME以及DirectSound API便不再直接起作用，取而代之是以WASAPI（Windows Audio Session API）来模拟这些旧有的API。

WASAPI是Vista新的UAA（Universal Audio Architecture）音效架构的API之一，这个新的API是以Session为概念，当不同的应用程序调用WASAPI，它们的需求会被各自独立成不同的Session进行音讯处理，处理过程会经过多个不同功能的APO（Audio Processing Objects），这些APO主要用来处理音量增益、格式转换及混音等功能，但并不包括SRC的动作。而且各个APO的功能各自独立不会混杂在一起，如此一来也能确保音讯处理时的质量，好过什么功能全包在一起的KMixer大杂烩，所以微软在APO的加入后，便拿掉了KMixer的功能，并将以上这些层级划分到使用者模式上，当这些流程处理完毕，才会将音讯送到驱动程序进行底层的运算处理。

从新的音效架构中，玩家可以得知Vista拿掉了几个过去常用的音效API，以及对音质影响颇大的KMixer，因此就这部分我们可以嗅出音质进化的味道。但是Vista新的音效架构，虽然改善了XP在安全性及音质层面的缺陷，却也导致了其它阶段性的问题产生。由于Vista推出前期有不少声卡厂商，还来不及针对WASAPI撰写新的驱动，因此只能以支持Windows XP的WDM（Windows Driver Model）驱动硬上，虽然Vista仍然可以使用WDM驱动，但并无法保证其兼容性，而且在音效架构本身就有所变化的同时，使用WDM驱动是可以完成安装没错，但却会出现音效播放时的时间位移或是音效中断等状况。除此之外，许多玩家会使用的创新未来EAX游戏音效处理，主要是透过DirectSound3D这个API，将数据送至音效晶片进行运算处理，藉此减轻处理器的运算负担，但在新的Vista音效架构中DirectSound已被移除，改由模拟转换的方式送至WASAPI中进行后续处理，但WASAPI并无法将数据直接送进硬件层，因此中间的转换过程便会造成EAX音效产生错误，这也使得创新未来必须重新针对各系列支持EAX音效的产品撰写驱动程序，就我们目前了解，X-Fi系列产品最先获得支持，至于较前期的声卡也会在近期陆续更新驱动。因此玩家若要在Vista使用音效，最好先到声卡的官网上，确认产品是否已有新的Vista驱动，否则难保不会出问题。

当然在Vista的音效功能中，除了解决KMixer的音质问题之外，WASAPI新的Session概念，也可以让每个使用音效的应用程序，个别控制其音量大小，也就是说如果同时有两个应用程序播放音效，玩家将可以在Vista的音量混音程序中，各别调整这两个应用程序的音量，这是过去在XP下所办不到的。另外Vista的音效控制还新增了几个功能，其中低音加强及低音保护，主要是针对低频段的几个频率讯号进行增益或衰减，如此一来可以满足玩家对于强劲低频的追求，或是降低其信号强度，以免发音单体出现破音的状况。而房间修正的功能，则是可以将麦克风放置在玩家最常聆听计算机音效的位置进行收音，然后透过喇叭系统播放测试讯号，如此一来麦克风便能将喇叭系统所处的空间播放状况收录下来，交由Vista进行空间反射的试算，自动调整声音播放时的频段增益，达到较好的聆听效果。而房间修正的功能只有在喇叭播放装置上才能进行调整，因为以耳机进行聆听的状况下，并不会有空间反射问题，但却会出现音场上的限制，因此针对耳机系统，Vista也提供了音效仿真功能，可以透过算法来创造出不同空间的环境音效。

从音效架构来看，理论上Vista操作系统下的播放音质会比XP来得好，因此我们一样采用foobar2000来播放测试讯号，并透过RMAA进行音质比对。在测试的过程中，小编发现Realtek的HD Audio Codec无法以foobar2000的KernelStreaming输出，但在X-Fi声卡中并不会出现这个问题，这有可能是因为创新未来的驱动程序仍以WDM为基础，而Realtek的HD Audio Codec则已针对UAA架构进行开发，所以在foobar2000中无法使用Kernel Straming输出，因此小编只针对DirectSound及ASIO输出进行测试。从RMAA所测得的结果，我们可以发现在Vista操作系统中，使用DirectSound跟ASIO输出，其失真度的测试表现略有差异，其中不论是总谐波失真（Total Harmonic Distortion）或是互调失真（Intermodulation Distortion）的成绩，都仍以ASIO输出为佳。但不是说Vista的音效架构比较好吗？架构优于XP是肯定的，只是DirectSound的输出就Vista音效架构上来看，虽然少了KMixer的干扰，但仍会透过仿真程序经WASAPI后端各APO处理后，才会送交驱动程序进行硬件层的连结，但ASIO就先天的特性来说，为了低延迟而直达硬件层，确实还是占有较高的优势。但如果我们对比XP及Vista在相同设定值下的成绩，可以发现Vista操作系统下所测得的大部分数据，都要比XP相同设定值所测得的成绩来得好，而且DirectSound及ASIO的差距幅度也明显减少，从这部分不难看出架构上的优势。另外就最佳设定值的取向来看，我们可以发现在Vista操作系统中，若内建音效要获得较好的声音质量，仍得使用ASIO输出外加SSRC的DSP，其设定值和XP的播放环境相同。除此之外，小编也对比了XP及Vista操作系统中的两个最佳化设定，我们可以发现尽管Vista的音效架构优于XP，但透过foobar2000的音质设定最佳化，则可以克服XP音效架构先天的缺陷，达到和Vista一样的播放质量。因此就音效使用来说，如果玩家习惯采用foobar2000当成播放软件，并且作了音质最佳化的动作，那就XP及Vista几乎没什么差别，但若是其它功能不足的应用程序直接播放音效，那么Vista的预设环境便优于XP。

这片文章基本上要表达的意思，就是说，在Vista（Win7）这个新的WASAPI音频构架下，十分不推荐使用DirectSound输出，因为在Vista（Win7）下已经没有DirectSound了，都是模拟出来的。当然如果你的声卡支持原生ASIO，也可以使用ASIO输出。我的MAYA44支持原生ASIO，但是我个人觉得用ASIO听歌有点蛋疼，还是WASAPI比较好一些。

另外既然说到这里，就再顺便说一下Vista（Win7）下的音频设置好了。

在Vista（Win7）下，可以设置播放设备和录制设备的属性，包括采样率、位深和是否支持独占等等。这个是很重要的设置哦~

我这里设置的是24位，48000Hz。这样设置就代表，系统发出的一切声音都将会以这个形式输出。采样率是影响音质的一个很重要的参数，而且重采样这个动作，是非常非常影响音质的。 我们听的歌，都是来自CD的，CD的格式是16位 44100Hz，所以如果在foobar里使用DirectSound输出，这里这样设置的话，输出的内容会被重采样到48000Hz，这就十分影响音质了。如果在foobar里用WASAPI输出的话，则会保持音源格式，也就是16位 44100Hz输出，这样就不会对音质产生影响。

但是为什么我要设置成24bit 48000Hz呢？=_=当然我有个专业声卡，我比较蛋疼都是原因之一。不过更重要的是，我们看的视频，无论是TVRip还是DVDRip或者是BDRip，音频都是48000Hz的（只要压制的时候别乱搞），所以这里这样设置，在看视频的时候就能保持原48000Hz输出了。

这样的话，foobar听歌可以44K输出，平时应用则是48K输出，皆大欢喜皆大欢喜。

打开GraphEdit，把mp4扔进去，然后我囧了，结果是解码器都用的什么微软的破东西……我就见鬼了……

甭管我怎么调，就是不用，CoreAVC CoreAAC ffdshow，哪个都不用……

后来某鱼提起来，说解码器被锁定了，msmpegvdec.dll就是这个文件搞的鬼。在system32目录下，还有一个msmpegadec.dll，这俩就是那恶心的解码器。

得处理一下这个东西，首先得修改这俩文件的所有者到自己的帐号，然后给自己的帐号添加操作权限，之后给这俩文件改名就行了。

啊，真恶心啊真恶心，M$怎么想的，Win7这个好的系统给硬塞进去这两个恶心的东西……优先级高的要死，有这俩在其他DS解码器通通不用，还真难为这俩东西什么都能解……囧