试了一下TARO的lav中ALAC模块。
发现这个与reclock之间的兼容性不好。
1：
如果用WASPI输出，会出现多音轨不同步的问题。
而采用directsound或者MPC内置的渲染器或者waveout都无问题。
而FLAC+WASPI也无问题。
我用驯龙记测试。在Test Drive的音乐中出现了问题（7.1,24BIT）
2：
alac外挂在reclock下会报错,用M4A外挂，reclock显示无法播放，flac外挂，或者mka外挂无此问题。
用MPC外挂的ALAC用M4A外挂并无问题。
3：
诡异的ALAC解码优先级：
MP4封装下lav大于dssbass，而在m4a下则是dssbass大于lav。
最后，希望lav能够官方稳定的支持。
Re: ALAC解码问题
1. 測試用視頻：DTS-HDMA的demo視頻轉壓
首先看解碼。LAV Filters的解碼核心是ffmpeg，這裡我的patch也只修改了ffmpeg部分，所以只看用這個patch編譯出來的ffmpeg解碼能力：
格式：test_alac-${ENCODER}-dec-${DECODER}.wav
解碼出來的wav，用QuickTime(qaac)，refalac和lavf解碼結果是完全一樣的。實際上用foobar2000對alac和用lavf做decoder後的wav做bit comparison的結果也是相同的。本身解碼上沒有問題。
再看播放：
ASIO Renderer:
Reclock(WASAPI):
MPC Renderer(WASAPI):
全都沒有問題（我的聲卡不支持超過2.0ch，走ffdshow的mixer）。
只要能正確處理解碼，audio renderer面對的都是解碼後的PCM（非bitstream的話），所以同樣的解碼器+渲染器組合能處理一個格式就不應該處理不了其他格式，自己設置錯了是自己的事情…
唯一和其他格式不同的是ALAC如果是24bit的話，ffmpeg內部始終pad到32bit。這個在官方版LAV裡就是這樣（拿2.0ch的自己去測去），我只是把處理能力從2.0ch增加到7.1ch，bit depth處理邏輯我沒有也不會去改，因為沒必要，在ffmpeg內部24->32然後LAV裡32->24沒有任何損失，速度差距也幾乎可以忽略不計（兩次都是直接bit shift，而且LAV直接訪問ffmpeg解碼出來的相同內存地址，不會出現ffdshow->renderer那樣數據複製導致的內存帶寬消耗上漲，所以我沒像ffdshow那樣直接修改邏輯），所以沒必要對ALAC加一個workaround。我相信不會有人在使用Kernel Streaming或者ASIO的時候明明聲卡只支持到24bit卻不去掉解碼器裡32bit輸出的支持吧，雖然從你的錯誤報告裡我非常懷疑你的輸出bit depth就是這樣設置的…還有就是ALAC相比於其他lossless解碼速度相當糟糕，HD規格的alac遇到CPU解碼瓶頸也不是沒可能（和其壓縮率相當糟糕、容錯能力一般、編碼速度RP、支持度極低等問題一起在很多年內都阻礙了ALAC的發展，遠不是沒開源這種在APE、TAK裡都存在的問題，所以就算現在開源了以後發展也很難說，等fhg的HD-AAC正式搞出來後說不定就可以淘汰了）…如果是其他WASAPI通用性的問題就更沒啥好說的了…
2. m4a的外掛，在MPC-HC內默認使用的是quicktime，和其他的dshow解碼方式沒有相性，需要將m4a等從quicktime改成directshow。我這裡外掛m4a沒有任何問題。當然m4a的dshow分離器/解碼器也必須是LAV，要是設成了BASS之類不支持multi channel的ALAC的東西就更和LAV沒關係了…
3. bass不僅僅是decoder，它更準確地說是source filter。你讓bass接管的話，從file source到splitter到後面decoder一條龍都會接管，甚至還會影響mpc的v/a sync，所以如果m4a用bass作為source filter的話，絕對不可能在解碼的時候換成其他decoder的，不是詭異，bass就是這樣的東西，如果不理解它的工作方式就不要用它。同樣這也是為什麼我給LAV添加multi channel alac支持的原因。如果僅僅是要在mpc-hc內播放multi-channel的alac的話，直接在設置的formats頁面把包含這個音軌的格式從directshow調整到quicktime然後系統裡安裝好quicktime就行了。如果要走directshow的話，現在有很多directshow的quicktime wrapper，都可以支持把quicktime用在directshow機制裡。問題是不管哪種方式，quicktime都是作為source filter的。前者會接管包括渲染在內的整個播放流程，而後者至少會接管source/splitter/decoder流程。而且與bass這種純音頻的source filter不同的是quicktime連視頻都會接管，而quicktime的視頻解碼器能力太有限了。所以我才會想搞一個僅僅在decoder層接管音頻的解碼器。因此在針對視頻播放的應用裡沒事幹別用bass，LAV除了TAK之外沒有哪個解碼能力不如bass的。你要是用bass去解碼DTS-HD的話連HD部分都不支持。這當然不關LAV的事情。自己系統內的濾鏡優先級不調教好，就不要怪其中某個具體的濾鏡。
嘛…反正怎麼設置導致問題不關我事，愛用就用，不用等官方的請自便…官方要支持，至少要等ffmpeg/libav正式支持，而libav今年GSoC裡做ALAC的學生已經很久沒出現過了，ffmpeg又在等libav，會不會像x264的trellis-me那樣沒人管直接坑掉就不知道了…
► 显示剧情透露 MediaInfo
格式：test_alac-${ENCODER}-dec-${DECODER}.wav
解碼出來的wav，用QuickTime(qaac)，refalac和lavf解碼結果是完全一樣的。實際上用foobar2000對alac和用lavf做decoder後的wav做bit comparison的結果也是相同的。本身解碼上沒有問題。
再看播放：
ASIO Renderer:
Reclock(WASAPI):
MPC Renderer(WASAPI):
全都沒有問題（我的聲卡不支持超過2.0ch，走ffdshow的mixer）。
只要能正確處理解碼，audio renderer面對的都是解碼後的PCM（非bitstream的話），所以同樣的解碼器+渲染器組合能處理一個格式就不應該處理不了其他格式，自己設置錯了是自己的事情…
唯一和其他格式不同的是ALAC如果是24bit的話，ffmpeg內部始終pad到32bit。這個在官方版LAV裡就是這樣（拿2.0ch的自己去測去），我只是把處理能力從2.0ch增加到7.1ch，bit depth處理邏輯我沒有也不會去改，因為沒必要，在ffmpeg內部24->32然後LAV裡32->24沒有任何損失，速度差距也幾乎可以忽略不計（兩次都是直接bit shift，而且LAV直接訪問ffmpeg解碼出來的相同內存地址，不會出現ffdshow->renderer那樣數據複製導致的內存帶寬消耗上漲，所以我沒像ffdshow那樣直接修改邏輯），所以沒必要對ALAC加一個workaround。我相信不會有人在使用Kernel Streaming或者ASIO的時候明明聲卡只支持到24bit卻不去掉解碼器裡32bit輸出的支持吧，雖然從你的錯誤報告裡我非常懷疑你的輸出bit depth就是這樣設置的…還有就是ALAC相比於其他lossless解碼速度相當糟糕，HD規格的alac遇到CPU解碼瓶頸也不是沒可能（和其壓縮率相當糟糕、容錯能力一般、編碼速度RP、支持度極低等問題一起在很多年內都阻礙了ALAC的發展，遠不是沒開源這種在APE、TAK裡都存在的問題，所以就算現在開源了以後發展也很難說，等fhg的HD-AAC正式搞出來後說不定就可以淘汰了）…如果是其他WASAPI通用性的問題就更沒啥好說的了…
2. m4a的外掛，在MPC-HC內默認使用的是quicktime，和其他的dshow解碼方式沒有相性，需要將m4a等從quicktime改成directshow。我這裡外掛m4a沒有任何問題。當然m4a的dshow分離器/解碼器也必須是LAV，要是設成了BASS之類不支持multi channel的ALAC的東西就更和LAV沒關係了…
3. bass不僅僅是decoder，它更準確地說是source filter。你讓bass接管的話，從file source到splitter到後面decoder一條龍都會接管，甚至還會影響mpc的v/a sync，所以如果m4a用bass作為source filter的話，絕對不可能在解碼的時候換成其他decoder的，不是詭異，bass就是這樣的東西，如果不理解它的工作方式就不要用它。同樣這也是為什麼我給LAV添加multi channel alac支持的原因。如果僅僅是要在mpc-hc內播放multi-channel的alac的話，直接在設置的formats頁面把包含這個音軌的格式從directshow調整到quicktime然後系統裡安裝好quicktime就行了。如果要走directshow的話，現在有很多directshow的quicktime wrapper，都可以支持把quicktime用在directshow機制裡。問題是不管哪種方式，quicktime都是作為source filter的。前者會接管包括渲染在內的整個播放流程，而後者至少會接管source/splitter/decoder流程。而且與bass這種純音頻的source filter不同的是quicktime連視頻都會接管，而quicktime的視頻解碼器能力太有限了。所以我才會想搞一個僅僅在decoder層接管音頻的解碼器。因此在針對視頻播放的應用裡沒事幹別用bass，LAV除了TAK之外沒有哪個解碼能力不如bass的。你要是用bass去解碼DTS-HD的話連HD部分都不支持。這當然不關LAV的事情。自己系統內的濾鏡優先級不調教好，就不要怪其中某個具體的濾鏡。
嘛…反正怎麼設置導致問題不關我事，愛用就用，不用等官方的請自便…官方要支持，至少要等ffmpeg/libav正式支持，而libav今年GSoC裡做ALAC的學生已經很久沒出現過了，ffmpeg又在等libav，會不會像x264的trellis-me那樣沒人管直接坑掉就不知道了…
上次由 06_taro 在 2012-06-28 1:42，总共编辑 3 次。
つまんねー事聞くなよ！
I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)
Follow me: @06_taro
世界304日——
为纪念伟大的宇宙史上最强压制304先生，联合国教科文组织决定，将每年的第304天，即平年的10月31日或者闰年的10月30日，定为世界304日。
I, personally, for me, believe (
Follow me: @06_taro
世界304日——
为纪念伟大的宇宙史上最强压制304先生，联合国教科文组织决定，将每年的第304天，即平年的10月31日或者闰年的10月30日，定为世界304日。
Re: ALAC解码问题
我的声卡是alc892 支持7.1.
在ffdshow中混流成2.0再次输出无问题，混音成7.1输出无问题。
在ffdshow只做重采样到96khz，或者绕过ffdshow，就有不同声道不同步的问题。
PS：dssbass除了TAK至少还有optimfrog上的优势。
在ffdshow中混流成2.0再次输出无问题，混音成7.1输出无问题。
在ffdshow只做重采样到96khz，或者绕过ffdshow，就有不同声道不同步的问题。
PS：dssbass除了TAK至少还有optimfrog上的优势。
Re: ALAC解码问题
今天做了一堆測試，想到了一個可能的原因。alac在7.1ch的channel layout和標準的wav是不同的。LAV裡不包含channel remap的功能（到現在也沒有mixer），所以只能採取as-is的方式，對於ffmpeg輸入的pcm是按照標準的channel mask輸出。如果這個channel layout和聲卡支持的標準wavext的channel layout不同有可能會導致聲卡沒法直接支持，所以需要經過一個mixer，譬如ffdshow的mixer。如果確實是這個問題導致的話，我這裡是不會繼續處理的了，就算是LAV的官方如果不先給LAV增加channel remap功能的話也沒法解決的，而給LAV添加channel remap是nev長長的TODO list的一部分，目前估計是要等ffmpeg的libswresample項目完成後直接使用，如果我做掉的話連mixer也可以直接搞掉了，工程量有點大…反正我這裡主要是實現正常的解碼和使用，至於需要過mixer的話，就掛上好了，反正貌似現在除了這個方法之外也沒有其他multi-channel alac的dshow解碼器，就算哪天出來一個，不加上mixer的話也是同樣的問題…不過倒是可以考慮去給FFDShow也增加multi-channel alac的解碼支持，雖然最終效果應該是一樣的（ffdshow內部remap），至少看上去“好像”少了一些處理，讓大部分人可以看著感覺舒服點…
PS: optimfrog這種編解碼速度杯具到差不多都只有ape這種慢得蛋疼的編碼的一半（大眾化參數下）的東西真有人會用在dshow裡麼…
PS: optimfrog這種編解碼速度杯具到差不多都只有ape這種慢得蛋疼的編碼的一半（大眾化參數下）的東西真有人會用在dshow裡麼…
つまんねー事聞くなよ！
I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)
Follow me: @06_taro
世界304日——
为纪念伟大的宇宙史上最强压制304先生，联合国教科文组织决定，将每年的第304天，即平年的10月31日或者闰年的10月30日，定为世界304日。
I, personally, for me, believe (
Follow me: @06_taro
世界304日——
为纪念伟大的宇宙史上最强压制304先生，联合国教科文组织决定，将每年的第304天，即平年的10月31日或者闰年的10月30日，定为世界304日。