STSD DSD
試聽1 24bit/176k
https://drive.google.com/file/d/0B57...ew?usp=sharing
試聽2 16bit/44.1k
https://drive.google.com/file/d/0B57...ew?usp=sharing
可列印查看
STSD DSD
試聽1 24bit/176k
https://drive.google.com/file/d/0B57...ew?usp=sharing
試聽2 16bit/44.1k
https://drive.google.com/file/d/0B57...ew?usp=sharing
1.
https://drive.google.com/file/d/0B57...ew?usp=sharing
2.
https://drive.google.com/file/d/0B57...ew?usp=sharing
Google若無法播放可以自行下載試聽
好用的copy.com已無法使用。*42
很抱歉，拖了很久。
一直想要把內容整理得有條理一點，但是想寫的東西又多又雜，只好想到什麼寫什麼。
小弟再強調一次，這些只是小弟的想法，並不一定正確。如果有前輩發現小弟有任何地方說錯了，請指正小弟。
先說single-ported RAM和dual-ported RAM。
single-ported RAM這種記憶體一個週期只能做單純讀或單純寫的動作。
dual-ported RAM記憶體可以同時對不同的位址做讀寫。
電腦所使用的DRAM，硬碟的buffer等等，都是single-ported RAM，也就是不可同時讀寫的記憶體。
因此當這些記憶體當成buffer來使用的時候，輸入資料的穩定度，也會影響輸出資料的穩定度。
輸入資料的速度越穩定，輸出資料的速度也會越穩定。
當然輸出資料的穩定度一定會比輸入資料的穩定度高，但是仍然還是會受影響。
某些FIFO buffer會使用dual-ported RAM，通常是SRAM，可以同時邊寫邊讀。
雖然會比single-ported RAM好，但為了要避免buffer空了或是滿了，輸出速率還是要跟輸入速率同步。
這個同步當然可以利用各種方式估計出平均資料輸入速率，來當成輸出速率。
但是在平均的過程中，也會引入輸入速率的jitter。
舉個簡單的例子，假設輸入速率為5,10,15,10,5,10,15,10,5,10,15..., 很明顯的，無限數列的平均為10。
但實際應用上，FIFO不可能使用無限數列來做平均。
假設使用6個資料點來做速度平均，前六個資料的平均為(5+10+15+10+5+10)/6=9.16667，並不為10。
接下來移動ㄧ組資料來做平均: (10+15+10+5+10+15)/6=10.83333，也不為10。
以此類推，輸出速率為: 9.16667, 10.83333, 10.83333, 9.16667, 9.16667......
雖然輸出的速率比輸入的速率更穩定，但仍非穩定的10。
假設輸入的資料速率為更穩定的9,10,11,10,9,10,11,10,9...
那麼輸出速率為9.83333, 10.16667, 10.16667, 9.83333, 9.83333... 明顯比上個例子穩定，但仍不為10。
所以，並不是使用buffer或是dejitter，就不用管來源的穩定度。
下一則，小弟想談談Row Hammer和Data Scrambling。
也就是記憶體和硬碟在實體層放資料的方式，由於種種原因，其實不像我們想像的那樣規律。
對了，順道一提...
最近看了一篇有趣的文章，想辦法用盡量科學的方式，量化聲音的品質，來判斷lossless FLAC和WAV聲音播放的差別。
他們將FLAC轉成WAV，再轉回FLAC，再轉成WAV，一直持續反覆，做出五個FLAC檔案和五個WAV檔。
聲音品質量化的方法，是聽單一樂器在聲音重播時的高度，並由多人盲聽的平均當作結果。
他們發現，FLAC的metadata(也就是儲存作者，曲目，封面圖檔等資料的檔頭)對聲音的影響非常大。
其中封面圖檔的影響更為劇烈。
當然還有許多有趣的結論，有興趣的網兄可以先讀讀內容，之後大家如果有興趣，再一起討論。
http://www.hificritic.com/uploads/2/...ac_formats.pdf
http://www.hificritic.com/uploads/2/...ac_formats.pdf
引用:
作者: bchsieh
這篇前幾天有瞄到，研究過程看不懂，但結論就比較容易理解。
怕各位懶得看，小弟雞婆，把結論轉貼出來：
Conclusions and Discussion
On the basis of our results thus far, we can make specific recommendations to the music download industry for issuing improved music files:
■ Erase metadata containing historical records of previous repeated WAV-to-FLAC-to-WAV conversions and replace with fresh metadata prior to final distribution.
■ Since storage capacity is so cheap these days, unless there are bandwidth or download speed issues, or maintenance of metadata concerns, do not use compression (ie, use WAV or AIFF in place of FLAC or ALAC).
■Use a download manager that can add fresh metadata from internet sources just before writing to the customer's storage device.
■ If you must use the FLAC format, supply files created using the dBPA software with the uncompressed 'U' setting, or no less than the 0 setting. (Never follow the dBPA recommendation to use setting 5.)
■Make metadata-associated cover art no larger than 800x800 pixels with maximum or near maximum jpg compression (similar to Photoshop QL0 or QL1). (When ripping your own CD collection, be sure to follow this same advice for best sound quality)
Why Lossless FLAC Compression Degrades Uncompressed WAV File Quality
1. Resolution of metadata associated art (MDA).2. Degree of MDA compression as created in typical photo-editing software.3. Degree of FLAC compression according to settings in dBPowerAmp.4. CPU load during decompression and conversion of FLAC files to PCM format.5. Allocated buffer size in playback software, music server, and/or digital to analog converter.
有很多這裡討論分享的同好也在 myav 的 htpc討論區分享，我看到其中一個有趣的討論串，裡面提到 cuda 對 rip 的影響，而且提供下載檔比較：
http://www.myav.com.tw/bbs/showthrea...#post205634842
https://mega.nz/#!XtJ3mQpB!xOFAOLsr6...Gpi_RAHv6w16Is
https://mega.nz/#!DogCCbAI!84iLW3Blw...6NQrvuyvKgmigU
我下載來聽後，簡單心得是：
1、經過foobar2000擴充功能的二進位比較，兩者完全一模一樣。我好像被 bchsieh 誤導 CUDA 的功能了？病好了趕快上來教教我！........(blush)(blush)
2、cuda 的 rip，的確聲音好上一截！殘響多了一點，動態對比好了一點。(clapping)(clapping)
3、但是，就是這個但是......原本我使用 jplay雙cat，兩者幾無差異；後來把audio pc設為『不是H模式』，才輕易聽出CUDA的 RIP檔聲音好一截。依我個人選擇，凡是使用雙CAT與H模式而『減小差異』的，我會列入比較不重要的考量。理由是這表示該差異比較是在DETERMINATE JITTER層次而不是RANDOM JITTER層次，那麼最簡單的方法不是處理CAT，而是換一台超高水準的DAC就好了。
4、可是我還是要說，這個錄音水準跟我偏好的新天新地唱片有『非常誇張的差距』(blush) 。我獨尊CAT，正是希望透過我推薦的cat與音響器材，可以讓大家對錄音水準或演奏水準要求可以變得更嚴苛些......所以真希望大家可以透過cat系統見識到不同的錄音世界。
5、至於有一個鬧場還敢拿我寫的文章抹黑別人的ＸＸ，那個垃圾級的rip，動態對比輸一大截的大花版cd居然沾沾自喜以為rip很好......那就請大家同情大概是嚴重木耳居然會燒壞腦袋..........(devil)
(end)
用CUDA錄製的真的有差耶！我是用上班的Mac Mini，LH Labs的 Geek Out 450，再加上Sony MDR V6耳機。比較兩個檔案的check sum都一樣，但是聲音還真是有差。這個有趣！
（第一個數字是check sum，第二個數字是block counts）
32561 34562 01 Track01.wav
32561 34562 cuda_Track01.wav
教授，抱歉，因為之前生病在工作上進度落後許多，最近正忙著趕進度。引用:
作者: psycho
20~30年前就在接觸個人電腦的網兄應該知道浮點運算器(如80287, 80387等等)..
當時的CPU並未內含浮點運算器，所以如果沒有安裝80287或是80387而需要做特殊浮點運算，必須用軟體模擬(叫做軟87)。
而用軟87，速度比起真正的硬體加速器真是慢到天荒地老。
而當時的繪圖軟體如autocad/autoshade/autosolid甚至到後來的3d studio，如果沒有用繪圖卡，光是做隱藏線去除就可以算到天荒地老，更別說是做即時運算旋轉換視角。
而現在的NVidia CUDA也是類似的情形。NVidia GPU內建許多函式的硬體加速器，所以當程式想要使用GPU來運算這些函式的時候，就可以把程式內的標準函式名稱，換成對等的GPU函式名稱(如ABC換成GPUABC)，速度當然快得多。
HQPLAYER的CUDA offload就是最好的例子。
不使用CUDA offload，呼叫的函式為ABC。而使用CUDA offload時，呼叫的函式就變成GPUABC。
然而NVidia為了拓展他的GPU市場，另外寫了一個介面，讓一般不支援GPU的程式也可以使用GPU。
當透過這個介面執行程式的時候，一旦介面發現程式在執行的時候，有呼叫任何GPU可以支援的函式(如上述的ABC)，
就會自動把這個呼叫變成GPUABC，把計算移到GPU運算。
使用GPU來rip CD，就是這種模式。
當然，如果程式裡面沒有任何GPU可支援交換的函式，就算透過這個介面來執行，效能也不會變更好。
前面大部分網兄提到HQPLAYER對聲音有很大幫助的原因，是來自於升頻以及數位濾波。
如果有使用GPU，升頻和數位濾波的速度當然大幅度提升，latency降低非常多，聲音一定比「單純使用CPU做升頻和數位濾波運算」好非常多。
但小弟有興趣的是，如果在bit perfect播放下，GPU的幫助是不是真的能讓聲音變好？
HQPLAYER已經確定非bit perfect的播放器了。
接下來如果有網兄願意，可以試試看使用JPLAY等bit perfect播放器，透過NVidia介面是不是能加強音質。
HQPLAYER不能完全關閉DSP,單純decode輸出嗎?引用:
作者: bchsieh
照理說應該會在UI中提供disable的選項??
國外已經有人試過了.. 用盡各種方式，輸出仍非bit-perfect。引用:
作者: Higuma
原作者的奇怪堅持嗎XDD引用:
作者: bchsieh
bchsieh大，可以提供國外這部分的連結嗎?小弟想看一下試過的測試方式，想要思考一下這個問題，感謝您引用:
作者: bchsieh
pcherng兄，請看下面討論區:引用:
作者: pcherng
http://www.computeraudiophile.com/f1...3/index76.html
一直討論了大約十頁。
這位仁兄的帳號叫做tranz，DAC是MSB，有特異功能，播放特別測試檔案，DAC就可以知道是否為bit-perfect播放。
HQPLAYER的作者Miska也有參與討論，不過看來作者本身也不知道為什麼測出來非bit-perfect。
tranz有用其他的播放器做測試，都可以進行bit-perfect播放，就只有HQPLAYER不行。
所以證明並非是作業系統或是音效驅動程式的影響。
對了， tranz用的是Mac，但沒有道理HQPLAYER在不同作業系統下會有不同的表現。
也來回報這一個月來抓長芯盛偶有爆音不連續或斷訊的問題。依照前面的觀察到的現象我在adaptor上下放了散熱片(p286)先來觀察看看如果把本體加強散熱是否有甚麼變化，前面的現象改變了甚麼? 這期間也嘗試聽聽別的撥放軟體換成了KORG Audiogate 4.02，也入手一台DS-DAC-100把軟體的限制打開聽聽DSD的檔案，此部分與先前的使用環境不同，暫時把數字時代2收起來打算另組一台時再請出來玩玩。先前使用數字時代2時當異常發生時的狀況變成是音樂撥放的當中會停掉失聲了，必須結束撥放軟體再重新執行與DAC連線。沒找到root cause，但是我注意到了撥放軟體會斷掉聲音是因為dac的斷線狀況，突然想起用在100V的CDP和唱盤的隔離變壓器二次側有三種電壓規格，改了一下接線並把AOC兩端吃5V的變壓器，長芯盛adaptor的電供，dac的電供全部接上這個隔離變壓器上的排插，呦呦呦 沒再發生過異常了! 小弟猜想我的問題極有可能是市電帶入的突波，壓降等等的問題引起的狀況，如果有這方面問題的朋友可以朝這方向試試有沒有幫助。
越來越詭異了,原作者自己都不知道為何無法單純輸出?引用:
作者: bchsieh
就data層級,沒有coder無法控制的變因吧?
其實要測試也很簡單,用錄音卡做自身DO/DI錄音,
再拿原檔案比對就行了.........可有網兄測過?
感謝bchsieh大提供的連結文章，今天來看到教授也聽了兩個檔案後的感覺，呵呵~ 確實不是業障重，聽到都不是假的!!! XD 因為在myav上除了那個令人生氣的傢伙外就G660606大有發表聽感
myav john大提供的兩個檔案小弟初時聽到兩個結果，這兩個結果分別是用audiogate 4.02和 hqplayer聽到的，安裝audiogate 4.02的是參考機，沒有特別什麼原因去做設定，只有一點就是選擇低耗能的amd apu 2650的平台來聽音樂，當初只希望利用apu的特性與長時間聆聽時可以不要太耗電就好，也由於cpu不強，所以使用的撥放軟體也就試一些跑起來不耗資源的撥放器，一開始用myav的sigma大寫的playwave，因為用asio所以就某程度而言符合bit-perfect。
先說說這兩個檔案聽到不同的結果來說一下，起初是放到htpc上去聽，老實講我聽到兩個檔案撥放起來沒有差很大，幾乎是一樣，重複聽各十來次真的沒有聽到很明顯的差異，OK，後來G660606大說了cuda的聽起來比較有立體感，想了一下換工作用的NB內的hqplayer來聽看看好了，結果真的很容易聽到不太一樣的結果，cuda聽起來樂器間的位置形成的定位感不同比較好，空間殘響的所形成的音場及堂音也比較好，強弱的對比cuda的也比較好，我分別用winhex和spek再確認一下，確定是沒有不同處，雖然rip條件不同時產生的聽感在citymaster那玩過確實有差，是甚麼原因真的不懂!
比較慶幸的是教授用雙機流+jplay H模式可以消除rip差異的結果在小弟的htpc也相同 XD
因為這個問題今天下班前玩了一個小小的測試，用AMD Radeon RAMDisk做一個800mb的R:出來，把兩個檔案放在兩個資料夾順便把檔名一致，再分別把檔案複製到R:內用hqplayer聽，每次R:內只有一個檔案，如果要換cuda的就format R:後再複製進R:
挖糙~ 真的很認真的聽了幾次後 這是第三個結果，可是差異性縮小了，有趨近htpc上的聽感但還是有不一樣的地方
真的，小弟還是要說應該不是"業障重，聽到都是假的"，看到bchsieh兄說到國外測試hqplayer是不是bit-perfect的測試方法時小弟好奇了，從p76-p86間review quickly兩次，除了在p79內的#1958的bogi兄用ramdisk取代usb disk來聽音樂有獲得比較好的聲音細節外就沒有其他人用ramdisk來測試了
ramdisk的測試是突然閃過的念頭，靈感來源是在P900大的討論串提到有切一個ramdisk出來，當要撥放音樂時會把檔案複製到ramdisk去再撥放，如果聽一聽覺得怪怪的在執行一個程式類似清黑膠上面的灰塵把ramdisk整理一下，另外就是貓窩工坊的陳大也提到過，比對都沒有差異的兩個數位音樂檔聽起來不同時除了jitter外還要考慮的是執行時資料的一致性是否相同，是不是在磁碟內一樣的位置，loading到ram時的位置是不是相同的地方，這都要考量進去的問題。
再來，使用sigma大的playwave時最讓小弟收穫很大的地方就在一連串的4.x.x的改版經驗，sigma大有提到發聲的工作是驅動程式與os的事，playwave改變聲音的地方就僅在每次嘗試把資料送到driver的方式做的變動，有興趣的可以參考http://www.myav.com.tw/bbs/showthrea...eadid=20459807
其中小弟領悟到資料傳送的方式會有兩個層面現象，改變與改善致正確的再現
小弟假設一個可能性hqplayer不是bit-perfect的問題會不會是資料傳遞給驅動程式其實已經有改變了而沒有正確的再現。
小弟做的ramdisk實驗提出來，看看有沒有其他有興趣測試的大大試試看看這個結果有無差異，呵呵呵~ 小弟倒是希望是我"業障重聽到的是假的"
hqplayer小弟有很大的興趣，聽過citymaster大的系統及看了幾位大大用的經驗後躍躍欲試，打算把另一個閒置的ga-990fxa-ud7+1045t依照john大的建議，弄一個加料很誇張的系統玩玩!
小弟看法是除非作者找到原因不然真的不要期望這個hqplayer是嚴謹的bit-perfect方案
我沒有時間細想這個問題，目前粗略的猜測是：
JPLAY派或者聲音偏向JPLAY派的CAT播放理論，基本原理是CAT的運算速度越快越好。但是追求效能的嚴重副作用就是『躁感』(可能來自高速運算的電磁訊躁)會上升，於是後端調整要不像我一樣就是用超大暫態來躲問題、不然就是想辦法濾掉躁感如JPLAY作者們推薦的音響器材。
而CUDA的出現，似乎『分擔了』部份CAT的運算效能，所以從根本上就會促進CAT的聲音水準，而且應該至少有DETERMINATE JITTER變小與訊躁變小的優點。因為我長期的經驗，RIP水準越高的就是播放水準越高，而且兩者幾近若且唯若的緊密關係。因此這次CUDA RIP的成功，會讓我非常相信CUDA在播放上有效！！....(clapping) 因為RIP的結果完全相同(BIT PERFECT?) ，僅僅把CAT的工作分擔給CUDA就可以得到如此強大的 RIP 差異，這對於未來的CAT播放一定有全新道路。
但是，增加了CUDA效能同時也加重了CAT本身的電力負擔與太多電子零件，上述的優點能留下多少不無疑問。而CUDA本身的運算效能，一定得透過軟體最佳化才有可能達到最高效果。JPLAY早就利用CPU的雙核或多核，獨佔且鎖定一核專用於JPLAY了。所以如果JPLAY支援把鎖核的功能鎖在CUDA時，我們大概就要乖乖玩CUDA了.....(devil)
而HQPLAYER程式本身大概可以放棄了，之前測試CUDA就覺得聲音加料，這次RIP測試後更確定HQPLAYER的聲音理念與我不合；BIT PERFECT也許不是重點，JPLAY的 STREAMER引擎也是BIT PERFECT，但是聲音與我的要求完全天差地遠呢！我認為這些播放程式的作者，還是得依他自身的音響美學進行程式寫作。所以理念與我不合的播放程式一聽就知道有底了。但是幸好證明不是CUDA有問題，而是HQPLAYER有問題，這可是大事一件！.....:D
如果不要求CUDA的效能(只要GT730甚至210就夠用？)，只是讓CAT的工作可以分擔到CUDA就足以從而提升整體性能，那麼CAT播放應該又有大改善了。猜想下次 JPLAY "7"大概就是支援CUDA？.....(angel)
教授這個思維，最好JPLAY作者能看到！
JPLAY若真能支援CUDA Offload，那豈不等於在單機上完成雙機的任務，又能免去中間網路的瓶頸，一舉數得。
教授，GPU是用來分擔CPU計算，無法完全取代CPU，所以「鎖核」這件事情，用在GPU上是沒有意義的。引用:
作者: psycho
更進一步解釋鎖核... 鎖核應該是從P900大和小弟最先開始，在幾乎相同時間，應用在CAT上。
一般大家都認為鎖核是為了讓音樂播放有最大資源可以使用，所以聲音變好。
當然這個理由是正確的，但其實鎖核在音樂播放上有更多更深層的意義。
其中一個最重要的原因，也是小弟一開始決定要鎖核的理由，是時脈。
電腦內有許多種可以用來當作系統時脈的時脈源，在當時的CAT界普遍認為，HPET(high precision event timer)是最適合CAT的時脈源。
但其實更適合CAT的時脈源是TSC (time stamp counter)。
因為TSC的時脈頻率比HPET高很多(CPU的頻率 vs. 10MHz)。
也就是CPU跑什麼頻率，TSC時脈就是什麼頻率。例如CPU為3.2GHz，TSC時脈頻率就是3.2GHz。
除了頻率高這個優點以外，另一個最大優點就是呼叫TSC所使用的系統資源遠遠低於呼叫HPET，也因此呼叫的延遲快了一個數量級。
頻率高和低延遲，對音樂播放絕對有極大的幫助。
但是TSC的缺點有二:
1. 頻率不準(請注意，是不準，不是不穩)，也就是本來應該是3.200000GHz，但是實際上卻為3.199995GHz。
所以如果使用TSC來做為系統時脈，系統時間可能在一天內就誤差了好幾秒。
如果沒有做網路校時(NTP)，對於一般用途的電腦使用者可能會有不小的困擾。
2. 每個CPU核心的頻率都會有一點點不同，所以其TSC的頻率也會有出入。
如果相關的程式在不同的核心執行，就可能會因此發生問題。
所以TSC通常有設計每隔一段時間將不同核心的TSC同步。
然而在同步的時候，就會影響TSC的穩定度，並且會增加TSC的系統資源使用率。
這對音樂播放來說，明顯是個缺點。
對CAT來說，時脈穩定度的重要性遠遠大於準確度。所以TSC的缺點1，其實根本沒有影響。
而缺點2，就必須要解決了。
小弟的解決辦法，就是先將TSC的同步機制取消，然後把跟音樂播放相關的程式全部鎖在相同核心裡，使用相同的TSC時脈。
其他跟音樂播放無關的程式，就使用另外一顆核心。
這樣就算是兩顆核心的TSC時脈不同，不需同步也不會有任何影響。
以上才是小弟一開始想到要切割核心的理由。
從P900大之前的文章來看，小弟猜測P900 CAT切割核心資源應該也是基於類似的理由
(小弟如果沒記錯，P900 CAT大約在同時將BIOS內HPET的建議設定值從ENABLE改成DISABLE)。
ps. 基於上述理由，在超過雙核的環境底下(例如四核)，將超過一核心切給音樂播放程式，很有可能聲音會比不上只切一核心給音樂播放程式。
小弟前一兩篇文中有提到，只要將JPLAY透過NVidia介面(好像叫做NVidia控制台)來執行，就會讓JPLAY內能使用CUDA的函式交給GPU來處理了。引用:
作者: psycho
不需要等到JPLAY支援CUDA。
反過來說，如果JPLAY透過NVidia控制台來執行，聲音沒有變好，GPU的使用率也完全沒有增加的話，
就表示JPLAY根本不需要GPU來運作，以後也很難會有支援CUDA的JPLAY (除非JPLAY想要加入非bit-perfect播放的能力)。
目前不敢再做這個測試，CUDA的安裝會毀掉優化好的OS，變項增加根本無法好好比較........(blush)引用:
作者: bchsieh
不過看了你這篇文章多次，想不通為什麼經過CUDA的 RIP檔，聲音會變好？造成它變好的機制，不就會造成播放變好嗎？
目前從 MYAV的原作者行文看來，他僅僅是把EAC程式指定由CUDA協同執行，這個協同執行到底做了什麼真的是鬼才知道.....但是可以確定的是其中應該不涉及任何高階運算(記得我檢查過兩個檔都是44.1/16？)。如此就可以大幅提升RIP水準，不能不心動.....(clapping)
不過在此相信我的CAT解決方案之同好到也別緊張，『降低RIP差異』一向是本人調整CAT最偉大的成就(唬爛的啦！)；所以就算這麼有效的RIP方法，遇到本人調校的CAT還是無效的...(angel) 追這個問題，純粹是想再看看有沒有像長芯盛一樣又找到什麼超值且極緻的CAT播放方法。
如果真的要比RIP的絕對質量，用USB解決方案再加上長芯盛U3TT，然後從3.0 HUB外接藍光機，再RIP到同一個HUB的外接硬碟。OOK！這樣子的RIP絕對質量就可以完全滿足『HI-FI與暫態』的最高標準了。當然了，如果使用我推薦的JPLAY雙CAT+USB U3TT，RIP差異還是會被大幅降低，所以除了上次去嘲笑某個可愛的XX外，我幾乎不在此討論串談RIP差異了.....(giggle)
但是請記住，再怎麼強，遇到太離譜的RIP還是會死掉！所以最簡單的原則就是：用什麼CAT聽音樂，就用什麼CAT RIP CD！除了最後端是USB藍光機與USB DDC之分別，前端要完全一致完全相同。
好啦！我再公佈一個密技：
如果你是從不夠水準的電腦 RIP CD，怎麼辦呢？以下方法是rendzaw首先發現的，歡迎大家贊助他。
第一、一定要確定該rip是否bit perfect，最低標準是EAC，否則會有嚴重的混淆變項。
第二、用兩顆外接硬碟(用SSD碟或USB隨身碟你就自己去撞牆吧！)接在USB U3TT方案中的 USB 3.0 HUB。
第三、從第一顆硬碟COPY到第二顆，再COPY回來......在我的系統，只要反覆COPY個(二到五)次，使用我優化過的雙CAT播放就幾乎沒有差異了！！
第四、但是如果膽敢偷懶，例如說這次測試CUDA的方法，就是把AUDIO PC的JPLAY之H模式取消.....OK，RIP差異就消除不掉了！依rendzaw的研究，大概要反覆copy個一百六十次(！！)才能保證減小rip差異。
覺得上述資訊有莫大幫助的，記得要去贊助 rendzaw，他可是浪費了一千多片光碟、七台光碟機、二十幾個硬碟、n個 hub 跟無數電費研究出來的....(angel)
有可能，但並非絕對。因為RIP和播放，中間有許多函式呼叫是完全不一樣的。引用:
作者: psycho
目前可以肯定的，是RIP程式使用的函式，有部分可以被CUDA函式取代。
但JPLAY因為目前還沒有人用NVIDIA控制台播放過，所以到底CUDA可以幫到多少忙，還很難說。
CUDA協同執行，到底做了什麼，就在小弟前面貼文的內容裡啊...引用:
作者: psycho
CUDA能大幅提升RIP水準，以小弟的想法，是降低了資料傳輸的延遲，使得寫進硬碟時的資料流量更穩定。
就是小弟一開始提的假設，越穩定的寫入硬碟/記憶體，就能越穩定地讀出。
小弟在最前面所提到的WAV vs. FLAC音質測試的文章內(就是awuwa兄也有貼出結論的那篇)，裡面有用兩個不同版本的jriver來做比較。文章內指出，舊版的jriver由於RAM PLAY所使用的記憶體大小太小，所以經過多次轉換拷貝的WAV檔(ps.內容完全相同)，其音質差異性還是可以從播放中聽得出來。但換成新版jriver之後，只要使用RAM PLAY模式，多次拷貝轉換的WAV檔，音質跟原始檔案無異。引用:
作者: psycho
使用RAM PLAY，其使用的記憶體大小一定要大於播放檔案的大小，這是第一原則。原因就是小弟前面有提到的...電腦的記憶體是single-ported memory，一個時脈內只能讀或是寫，不能同時讀寫。所以當RAM PLAY記憶體小於播放內容，就必須邊讀邊寫，無法將整個檔案載入記憶體後才播放。這時候從硬碟讀出檔案的穩定度，就直接影響到記憶體輸出的穩定度，當然就會影響聲音。越糟的檔案，硬碟在讀出資料的時候越不穩定。越好的檔案，讀出資料的時候越穩定。才會讓舊版的jriver在RAM PLAY播放模式下，仍然聽得出來好壞檔案的差別。
其實如果系統夠靈敏，如果將檔案讀進記憶體時不做特別的處理，就算是RAM PLAY記憶體夠大，其實仍然可以聽得出不同版本之間的差異，只是這個差異性會變得非常小。這個除了在教授您的系統已經獲得驗證，在P900 CAT的系統，甚至是RAM OS上也都有相同的情形。使用RAM OS播放的網兄發現，如果將想要播放的檔案先放進虛擬硬碟VHD裡，重開機後隨著RAM OS一併讀進記憶體中，其音質會比RAM OS開機後，再將硬碟裡的檔案拷貝進記憶體內播放，還來得好。小弟的解釋，仍然是之前所說的假說，就是讀進記憶體的時候越穩定，讀取播放的時候聲音越好。
其實要說明這些之前，應該要先寫之前承諾的主題... Row Hammer和Data Scrambling.. 抱歉拖了很久..(blush)
教授，如果小弟的想法沒錯，使用隨便的裝置拷貝，拷貝越多次，聲音只會越糟，只是這個糟的程度會有邊際效應，最後趨近到某個糟度。引用:
作者: psycho
從小弟之前的假說，更進一步的推論，就是每一個硬體，還有硬體在不同模式下運作的方式，由於讀寫穩定度的不同，造成有不同的「指紋」。
隨著資料經過不同的硬體，這些硬體的「指紋」會陸續的印在資料上，越後面的硬體指紋會越清楚，因為這個指紋會蓋在越上層。
當資料一直反覆不斷在相同硬體傳遞，此硬體的指紋就會不斷的加強，使得最初期硬體所蓋上去的指紋，變得微乎其微。
所以小弟猜測，檔案經過多次在兩顆硬碟之間拷貝之後，聲音就會變成這兩顆硬碟的聲音(也就是指紋)。
一開始RIP所使用的光碟機的指紋，RIP軟體的指紋，都會被抹得一乾二淨。
另一方面，優質RIP的檔案，聲音一定帶有光碟機，RIP軟體的指紋。
如果使用非RAM PLAY播放的方式，優質RIP檔案的聲音一定仍然和多次拷貝檔案的聲音不同。但應該都很好聽。
而使用RAM PLAY播放的方式，嚴格說起來，聲音應該還是不同，只是由於記憶體的「指紋效應」太強，使得兩個檔案先前的指紋影響變小。
這個「指紋」猜想，就是想辦法用簡單的方法解釋為什麼有人說不同的硬碟有不同的聲音，不同記憶體有不同的聲音。
至於這個「指紋」是怎麼來的，要解釋，就必須回到小弟一開始的假說：寫入資料時穩定度的pattern，會跟輸出資料時穩定度的pattern，有高度相關。
沒錯！使用一般的3C產品只會越烤越差。
感謝bchsieh兄不吝分享。近來給小弟最大啟發的文章就是上面這段。引用:
作者: bchsieh
關於CAT的優化，真的除了P900和bchsieh兄外，千篇一律都是建議大家要在BIOS和Windows中開啟HPET，
小弟算是盲從者，也做了這個設定。
看了B兄關於HPET和TSC的見解後，
小弟先做了一個嘗試，在WS2102上裝上Process Lasso Server版，
並先把所有程序，移到CPU0，優先權為below normal；
再把Foobar2000.exe和ASIOhost64.exe移到CPU1，Foobar2000優先權設為realtime, ASIOhost64設為High。
光是這個調整，就讓聲音更上層樓，是全方位的提升。
再來，小弟嘗試
1. 關閉BIOS的HPET；
2. 停用Windows平台同步時鐘(在以管理者權限命令列輸入bcdedit /deletevalue useplatformclock，並重開機)
重開機後的聲音，讓小弟樂到昨晚差點睡不著覺。
以前CAT的聲音總會覺得過亮，弦樂群太亮、管樂太亮、人聲太亮…活像曝光過度的照片，不耐聽。
現在感覺亮度恢復到正常的水準，再者，弦樂群的低頻變得非常有厚實而綿密，愈來愈像現場的聽感，
這絕對是失真降低的成果！
再次感謝bchsieh兄，也感謝psycho兄在這討論串的用心經營，讓高手們願意不藏私的分享！
awuwa兄，很高興小弟寫的東西對您還有一點點幫助。
剛剛才發現小弟忘了說鎖核切核的另外一個好處。
一般多核心資源是動態分配的，也就是說，一個程式本來在核心1執行，可能過沒多久，就會被換到核心2。
就這樣一直換來換去。交換也是需要耗費系統資源，而且交換的時候，程式也會被短暫暫停。
這對realtime程式當然是大不利，所以鎖核讓程式持續在相同核心執行，也是讓聲音變好的其中一個原因。
ps. awuwa兄，您可以試試看將Foobar2000優先權設為high, ASIOhost64設為realtime。
在理論上，越後端(也就是越接近輸出端)的程式或是裝置，執行優先權越高會越好。
不過這也不是放諸四海皆準，一切都還是以實際測試結果為調整依據。:}
幾年前就聽謝兄建議以專用核心搭配TSC取代HPET播放,
但在Windows底下,我不知道怎樣能指定特定程式獨占核心,
近似的作法是在task manager手動一個個指定,但太麻煩了.
所以一直沒動手實做,不知道winserver底下是如何達成的?
想瞭解一下.
Process Lasso 這程式應該就可指定核心．
雖然給 awuwa 用力加分鼓掌，可是我看不懂：你是只用FOOBAR2000？還是FOOBAR2000+JPLAY？
使用JPLAY的話，根本不必感謝bchsieh（逗你啦！），因為JPLAY早在N年前就幫我們搞定了；所以我當時測試HPET完全無感，只是忘了寫出來.....(blush) 我都是使用雙核心的CPU，工作管理員可以看到JPLAY核心程式被指定用於CPU1，其他是CPU0；四核的電腦會指定放在那個自行查看。
如果是FOOBAR2000+JPLAY，然後把FOOBAR2000與JPLAY ASIO(ASIOhost64.exe或ASIOhost32.exe)都設成指定核心並加上bchsieh的調整方法，聲音也可以大幅提升嗎？與 jplaymini相比時如何？
因為jplay本身己經指定CPU1，如果再把FOOBAR2000也設去搶CPU1，聲音應該不增反而可能減。不過如果是高階的四核心CPU，就可以一般程式設CPU0，JPLAY預設CPU1，再把FOOBAR2000與ASIOHOST設成CPU2，也許聲音會變好？？awuwa是使用什麼CPU？
以上請千萬不要用I3！！因為I3是真雙核假四核，設了應該反而變差！其實我的I3 CPU根本在BIOS就關掉了假四核功能。I7也要小心，請把假八核功能關掉，否則造成JPLAY誤判，聲音會被我的PEITIEM CPU狂電！......(devil)
上述所謂『假多核』是指 INTEL 的超執行緒（HT, Hyper-Threading），I3 與 I7、XEON 都是這種假核心，對CAT是極端扣分，請務必注意！
教授，使用TSC時脈播放音樂，如果要得到最佳效果，如小弟前文所述，有兩個重點：
1. 所有跟播放音樂有關的程式，都必須在相同核心執行。
2. 不同核心的TSC同步必須關閉。
如果跟播放音樂有關的程式被放在不同核心執行，TSC同步不管是關還是不關，對聲音都有不良的影響。
播放如果是bit-perfect模式，CPU loading都很輕，是不用擔心單核心無法處理所有播放音樂的程式。
但是由於一個核心要處理好幾個程式，這幾個程式的優先權就變得非常重要。
調整的大方向就如小弟前文所述，越後端的程式優先權越高。
例如音樂播放的程式執行順序為: 播放程式(如foobar) -> 播放引擎(如JPLAY PLUGIN) -> 音效卡驅動程式
那麼音效卡驅動程式的優先權應該要最高，再來是播放引擎，最後才是播放程式。:}
小弟原本是使用Foobar，Output選 ASIO: JPLAY Driver，所以此時跟音樂播放有關的，應該是Foobar2000.exe, ASIOhost64.exe和Jplay Audio Service三個，其中Jplay Audio Service在安裝後，會把自己指定在CPU1這個核心，並在播放時自動把優先權拉到Realtime(停止播放時又自動降為Normal)。引用:
作者: psycho
因為小弟使用AMD 170u開成雙核的CPU，在未指定核心前， Foobar2000.exe和ASIOhost.exe這兩個程序會同時使用CPU0和CPU1，因為JPLAY Audio Service在播放時會以Realtime佔住CPU1，所以如果再把Foobar2000.exe和ASIOhost64.exe指定為只使用CPU1，並設為Realtime，得到的是衰聲，三個和尚沒水喝！
當時因為一直認定Foobar加了JPLAY更好聽，所以一直沒有考慮捨棄JPLAY，並把Foobar2000.exe及ASIOhost.exe移到CPU0並獨佔。
是在bchsieh兄的文章給了小弟啟發後，才決定暫時停用JPLAY，並讓Foobar及ASIOhost獨佔CPU1看看，沒料到有這麼大的提升。
在小弟的雙核CPU下，我看到的是：JPLAY會把自己指定於CPU1，但是，原本Windows的程序，仍會同時使用CPU0及CPU1，也就是，JPLAY只是指定自己只使用一個CPU核心，但並沒有進一步做到把其他程序移出CPU1。引用:
作者: psycho
而小弟參照B兄的建議，使用Process Lasso進一步的把Foobar2000.exe和 ASIOhost64.exe以外的所有程序，都移到CPU0，並設為Normal以下的優先權。所以，還是要固執的感謝bchsieh兄！
小弟使用AMD 170u單核CPU，並透過BIOS開成雙核運作。引用:
作者: psycho
上面提過，Foobar和Jplay同時指定獨佔CPU1的情況下，聲音不如Foobar不要指定CPU核心。
小弟還沒認真比較過Jplaymini，不過，我相信若不要使用Foobar，只使用Jplay Audio service加Jplaymini，並獨佔CPU1，應該會得到最好的聲音。但是因為播放方便性考量，所以小弟沒做此嚐試。
關於Foobar2000.exe和ASIOhost64.exe這兩個程序，誰的優先權應該調得比較高，小弟有參照bchsieh兄的建議試看看，引用:
作者: bchsieh
不過初步的心得是：
無論
Foobar2000.exe(Realtime)加ASIOhost64.exe(High)，
或是
Foobar2000.exe(High)加ASIOhost64.exe(Realtime)，
兩者並沒有太明顯的聽感差異。
小弟待系統穩定下來後，會再認真的針對這部份做測試，若有進一步發現，再跟大家報告。
請問awuwa兄，在windows下可以調整音效卡的IRQ優先權嗎？引用:
作者: awuwa
如果可以的話，您可以試試看將音效卡的IRQ優先權調整成realtime。:}
在regedit有相關機碼,此外還可以透過MMCSS(播放程式允許指定的話)引用:
作者: bchsieh
把音訊stream的優先權往上拉,我在Ptt分享過相關設定,可參考.
https://www.ptt.cc/bbs/Headphone/M.1...982.A.F71.html
硬體的IRQ小弟都有調整，謝謝提醒！引用:
作者: bchsieh
這部份的調整真的非常重要而且有效。
不過，既然說到IRQ Priority，就順便在此分享一下小弟前陣子的意外發現：
首先，感謝STSD眾燒友們的熱心分享，讓小弟在CAT的優化能有所依據，按部就班就能達到一定水準。
所以，舉凡在這些網兄們有提到的優化建議，小弟都嚐試過，但抱歉的是，未能完全掌握每個設值對聲音的影響。
直到2個月前，到友人家，聽他用老筆電(雙核、獨顯)當訊源播放音樂。
當天聲音一直不錯，但是音樂的節奏異常的緩慢，最明顯的就是鼓聲，總比平常習慣的聲音慢了半拍，
忍不住檢查一下電腦的設定，意外發現他的IRQ Priority被動了手腳，設定如下：
IRQ0Priority = 99(10進位) ==> System Clock(系統時鐘)
IRQ8Priority = 99(10進位) ==> Real Time Clock(CMOS實時時鐘，也就是bchsieh兄提到的RTC)
IRQ13Priority = 99(10進位) ==> Numeric Process Unit(數值運算器)
因為小弟有調整IRQ的經驗，所以當下試著把IRQ8Priority改為1(10進位)，
結果音樂的節奏馬上恢復正常。
回家再上STSD網站確認一次，發現文獻中的討論，都是建議把IRQ0Priority和IRQ8Priority設為1，
如此可以讓聲音更精準。
問題來了，我朋友對電腦優化並不熟悉，他不可能更動這些設定，那倒底是誰動的手腳；
再者，IRQ13Priority這個設值又有何影響？
由於友人的電腦安裝了AO和Jplay兩套優化軟體，
所以我請他先把IRQ Priority設值清除，並且先移除上述兩套軟體，
再重新安裝，並即時監控IRQ Priority的變化，
結果，被他抓到元兇，是AO搞的鬼。
AudiophileOptimizer (Ver. 1.4)這套軟體，不管您怎麼設定，它就是會固定把IRQ 0, 8, 13這三個元件的Priority設成最後。
原因為何？
小弟的猜測是：因為現在電腦運算速度愈來愈快，加上AO都有建議打開HPET，所以適時的把時鐘的中斷優先權降級，
可以讓聲音更和緩耐聽，若參照STSD的設定，反而容易出現比較衝的躁感。
不過AO作者這個設定，可能萬萬沒料到還有人用跑不快的雙核筆電(無法開啟HPET)，
此時時鐘的精準度顯得格外重要，優先權一降級，對聲音的速度造成直接的影響。
再者，IRQ 13數值運算器(浮點運算器)的設值又有什麼影響？
經友人的測試，簡直讓他發現了天堂！
友人發現IRQ13Priority這個值若設成99(10進位)，聲音的通透感會大幅提升，
有點像相機原本失焦變成完全準焦的清晰感，
聽感猶如雨後的夜裏在山上看台北市夜景，所以細節都鉅細靡遺，而且結像會大幅拉節，相當逼真。
所以，這個設值目前也變成小弟必設的參數！
優化軟體目前多未考量使用者的電腦等級，所以可能造成像友人的電腦優化後，反而聲音變得完全不正確的狀況！
再來，由於小弟曾在綱上做過以上的分享，有網友私訊小弟，提到原來Fidelizer這套軟體也會對IRQ Priority動手腳，
不過它卻是把IRQ8Priority設為和STSD網站建議一樣的1(10進位)，
這下好玩了，當電腦同時安裝AO及Fidelizer兩套優化軟體時，
其實他們有些設值是南轅北轍的，決定權在於那套軟體比較晚安裝，就可以蓋掉另一套軟體的設值，好笑吧！
所以，小弟目前已不再使用這些優化軟體了，
作業系統安裝完後，手動DIY照自己的需求來調整，反而更容易得到好聲。
Higuma兄也是小弟崇拜的先進之一，很多目前優化的手段，都是參考您先前留下的心得，感謝再三！引用:
作者: Higuma
不過，關於MMCSS，小弟有個疑問：
我知道Foobar現在可以設定MMCSS，小弟都把它設成Pro Audio，
並且也有調整登錄檔中有關Pro Audio的設定。
可是，小弟Foobar輸出選的是ASIO，
但MMCSS不是只有對WASAPI輸出有效嗎？
這樣的設定，對ASIO會有影響嗎？
還請前輩釋疑。
這倒是一個盲點,我沒想到過.引用:
作者: awuwa
查了一下,在RME的論壇中找到一些敘述如下,看起來ASIO一直都跟MMCSS
有連動,這也不意外,畢竟最早Steinberg就是尋求MS的幫助才搞出了ASIO.
https://www.forum.rme-audio.de/viewtopic.php?id=17575
第一篇大意就是說MS推出mmcss功能後,pro audio領域有了很多關於
mmcss的討論,在裝置driver中也都有提供相關選項,直到後來為了相容性
問題把這功能拿掉,但最後(2013 該篇post的時間點)遵循Steinberg
的建議,又把mmcss選項放回driver.
其實搞CAT,有個很重要的原則與前提:引用:
作者: awuwa
"你要知道自己在做捨麼"
否則實做起來永遠有太多的選擇在你面前,
單純只靠聽感實在太容易迷失方向,徘徊在
東牆與西牆之間,走不出去.
感謝awuwa提供的批次檔(下方為原出處,為Jacky2000網友製作),引用:
作者: awuwa
讓我能輕鬆完成指定核心的調整,目前正在聽,確實很有幫助,只是有種
速度變慢的感覺,還在適應中.
聽了一下,沒有問題,音色還原度更準確細膩,速度變慢是還原錄音本來產生的錯覺.
http://www.myav.com.tw/bbs/showthread.php?threadid=20473423&perpage=1&pagenumber=323