第295頁,共715頁 第一第一 ... 195245285293294295296297305345395 ... 最後最後
顯示結果從 2,941 到 2,950 共計 7142 條
  1. #2941
    註冊日期
    2007-09-12
    文章
    4,544
    Thanks
    3,511
    Thanked 5,491 Times in 1,852 Posts

    預設

    引用 作者: bchsieh 查看文章
    [恕刪]
    反過來說,如果JPLAY透過NVidia控制台來執行,聲音沒有變好,GPU的使用率也完全沒有增加的話,
    就表示JPLAY根本不需要GPU來運作,以後也很難會有支援CUDA的JPLAY (除非JPLAY想要加入非bit-perfect播放的能力)。
    目前不敢再做這個測試,CUDA的安裝會毀掉優化好的OS,變項增加根本無法好好比較........

    不過看了你這篇文章多次,想不通為什麼經過CUDA的 RIP檔,聲音會變好?造成它變好的機制,不就會造成播放變好嗎?

    目前從 MYAV的原作者行文看來,他僅僅是把EAC程式指定由CUDA協同執行,這個協同執行到底做了什麼真的是鬼才知道.....但是可以確定的是其中應該不涉及任何高階運算(記得我檢查過兩個檔都是44.1/16?)。如此就可以大幅提升RIP水準,不能不心動.....

    不過在此相信我的CAT解決方案之同好到也別緊張,『降低RIP差異』一向是本人調整CAT最偉大的成就(唬爛的啦!);所以就算這麼有效的RIP方法,遇到本人調校的CAT還是無效的... 追這個問題,純粹是想再看看有沒有像長芯盛一樣又找到什麼超值且極緻的CAT播放方法。

    如果真的要比RIP的絕對質量,用USB解決方案再加上長芯盛U3TT,然後從3.0 HUB外接藍光機,再RIP到同一個HUB的外接硬碟。OOK!這樣子的RIP絕對質量就可以完全滿足『HI-FI與暫態』的最高標準了。當然了,如果使用我推薦的JPLAY雙CAT+USB U3TT,RIP差異還是會被大幅降低,所以除了上次去嘲笑某個可愛的XX外,我幾乎不在此討論串談RIP差異了.....

    但是請記住,再怎麼強,遇到太離譜的RIP還是會死掉!所以最簡單的原則就是:用什麼CAT聽音樂,就用什麼CAT RIP CD!除了最後端是USB藍光機與USB DDC之分別,前端要完全一致完全相同。

  2. The Following 3 Users Say Thank You to psycho For This Useful Post:


  3. #2942
    註冊日期
    2007-09-12
    文章
    4,544
    Thanks
    3,511
    Thanked 5,491 Times in 1,852 Posts

    預設

    好啦!我再公佈一個密技:

    如果你是從不夠水準的電腦 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 跟無數電費研究出來的....
    此篇文章於 2016-07-24 12:22 AM 被 psycho 編輯。

  4. The Following 4 Users Say Thank You to psycho For This Useful Post:


  5. #2943
    註冊日期
    2007-10-23
    文章
    884
    Thanks
    3,147
    Thanked 3,785 Times in 778 Posts

    預設

    引用 作者: psycho 查看文章
    [恕刪]
    不過看了你這篇文章多次,想不通為什麼經過CUDA的 RIP檔,聲音會變好?造成它變好的機制,不就會造成播放變好嗎?
    有可能,但並非絕對。因為RIP和播放,中間有許多函式呼叫是完全不一樣的。
    目前可以肯定的,是RIP程式使用的函式,有部分可以被CUDA函式取代。
    但JPLAY因為目前還沒有人用NVIDIA控制台播放過,所以到底CUDA可以幫到多少忙,還很難說。

    引用 作者: psycho
    目前從 MYAV的原作者行文看來,他僅僅是把EAC程式指定由CUDA協同執行,這個協同執行到底做了什麼真的是鬼才知道.....但是可以確定的是其中應該不涉及任何高階運算(記得我檢查過兩個檔都是44.1/16?)。如此就可以大幅提升RIP水準,不能不心動.....
    CUDA協同執行,到底做了什麼,就在小弟前面貼文的內容裡啊...
    CUDA能大幅提升RIP水準,以小弟的想法,是降低了資料傳輸的延遲,使得寫進硬碟時的資料流量更穩定。
    就是小弟一開始提的假設,越穩定的寫入硬碟/記憶體,就能越穩定地讀出。

    引用 作者: psycho
    不過在此相信我的CAT解決方案之同好到也別緊張,『降低RIP差異』一向是本人調整CAT最偉大的成就(唬爛的啦!);所以就算這麼有效的RIP方法,遇到本人調校的CAT還是無效的... 追這個問題,純粹是想再看看有沒有像長芯盛一樣又找到什麼超值且極緻的CAT播放方法。
    [恕刪]
    小弟在最前面所提到的WAV vs. FLAC音質測試的文章內(就是awuwa兄也有貼出結論的那篇),裡面有用兩個不同版本的jriver來做比較。文章內指出,舊版的jriver由於RAM PLAY所使用的記憶體大小太小,所以經過多次轉換拷貝的WAV檔(ps.內容完全相同),其音質差異性還是可以從播放中聽得出來。但換成新版jriver之後,只要使用RAM PLAY模式,多次拷貝轉換的WAV檔,音質跟原始檔案無異。

    使用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.. 抱歉拖了很久..

  6. The Following 4 Users Say Thank You to bchsieh For This Useful Post:


  7. #2944
    註冊日期
    2007-10-23
    文章
    884
    Thanks
    3,147
    Thanked 3,785 Times in 778 Posts

    預設

    引用 作者: psycho 查看文章
    [恕刪]
    第四、但是如果膽敢偷懶,例如說這次測試CUDA的方法,就是把AUDIO PC的JPLAY之H模式取消.....OK,RIP差異就消除不掉了!依rendzaw的研究,大概要反覆copy個一百六十次(!!)才能保證減小rip差異。
    [恕刪]
    教授,如果小弟的想法沒錯,使用隨便的裝置拷貝,拷貝越多次,聲音只會越糟,只是這個糟的程度會有邊際效應,最後趨近到某個糟度。

    從小弟之前的假說,更進一步的推論,就是每一個硬體,還有硬體在不同模式下運作的方式,由於讀寫穩定度的不同,造成有不同的「指紋」。

    隨著資料經過不同的硬體,這些硬體的「指紋」會陸續的印在資料上,越後面的硬體指紋會越清楚,因為這個指紋會蓋在越上層。

    當資料一直反覆不斷在相同硬體傳遞,此硬體的指紋就會不斷的加強,使得最初期硬體所蓋上去的指紋,變得微乎其微。

    所以小弟猜測,檔案經過多次在兩顆硬碟之間拷貝之後,聲音就會變成這兩顆硬碟的聲音(也就是指紋)。

    一開始RIP所使用的光碟機的指紋,RIP軟體的指紋,都會被抹得一乾二淨。

    另一方面,優質RIP的檔案,聲音一定帶有光碟機,RIP軟體的指紋。

    如果使用非RAM PLAY播放的方式,優質RIP檔案的聲音一定仍然和多次拷貝檔案的聲音不同。但應該都很好聽。

    而使用RAM PLAY播放的方式,嚴格說起來,聲音應該還是不同,只是由於記憶體的「指紋效應」太強,使得兩個檔案先前的指紋影響變小。



    這個「指紋」猜想,就是想辦法用簡單的方法解釋為什麼有人說不同的硬碟有不同的聲音,不同記憶體有不同的聲音。
    至於這個「指紋」是怎麼來的,要解釋,就必須回到小弟一開始的假說:寫入資料時穩定度的pattern,會跟輸出資料時穩定度的pattern,有高度相關。

  8. The Following 7 Users Say Thank You to bchsieh For This Useful Post:


  9. #2945
    註冊日期
    2007-05-16
    文章
    720
    Thanks
    180
    Thanked 152 Times in 111 Posts

    預設

    沒錯!使用一般的3C產品只會越烤越差。
    CALL:0932-377626黃先生



    新竹市光復路2段882號6F~1

  10. #2946
    註冊日期
    2013-02-20
    文章
    51
    Thanks
    52
    Thanked 81 Times in 26 Posts

    預設

    引用 作者: bchsieh 查看文章

    電腦內有許多種可以用來當作系統時脈的時脈源,在當時的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)。
    感謝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兄在這討論串的用心經營,讓高手們願意不藏私的分享!
    此篇文章於 2016-07-26 02:13 PM 被 awuwa 編輯。 原因: 錯字

  11. The Following 7 Users Say Thank You to awuwa For This Useful Post:


  12. #2947
    註冊日期
    2007-10-23
    文章
    884
    Thanks
    3,147
    Thanked 3,785 Times in 778 Posts

    預設

    awuwa兄,很高興小弟寫的東西對您還有一點點幫助。

    剛剛才發現小弟忘了說鎖核切核的另外一個好處。
    一般多核心資源是動態分配的,也就是說,一個程式本來在核心1執行,可能過沒多久,就會被換到核心2。
    就這樣一直換來換去。交換也是需要耗費系統資源,而且交換的時候,程式也會被短暫暫停。
    這對realtime程式當然是大不利,所以鎖核讓程式持續在相同核心執行,也是讓聲音變好的其中一個原因。

    ps. awuwa兄,您可以試試看將Foobar2000優先權設為high, ASIOhost64設為realtime。
    在理論上,越後端(也就是越接近輸出端)的程式或是裝置,執行優先權越高會越好。
    不過這也不是放諸四海皆準,一切都還是以實際測試結果為調整依據。

  13. The Following 4 Users Say Thank You to bchsieh For This Useful Post:


  14. #2948
    註冊日期
    2009-06-13
    文章
    426
    Thanks
    40
    Thanked 875 Times in 261 Posts

    預設

    幾年前就聽謝兄建議以專用核心搭配TSC取代HPET播放,

    但在Windows底下,我不知道怎樣能指定特定程式獨占核心,

    近似的作法是在task manager手動一個個指定,但太麻煩了.

    所以一直沒動手實做,不知道winserver底下是如何達成的?

    想瞭解一下.
    此篇文章於 2016-07-26 08:06 PM 被 Higuma 編輯。

  15. The Following User Says Thank You to Higuma For This Useful Post:


  16. #2949
    註冊日期
    2008-09-19
    文章
    80
    Thanks
    4
    Thanked 11 Times in 9 Posts

    預設

    Process Lasso 這程式應該就可指定核心.

  17. The Following 2 Users Say Thank You to Merci For This Useful Post:


  18. #2950
    註冊日期
    2007-09-12
    文章
    4,544
    Thanks
    3,511
    Thanked 5,491 Times in 1,852 Posts

    預設

    雖然給 awuwa 用力加分鼓掌,可是我看不懂:你是只用FOOBAR2000?還是FOOBAR2000+JPLAY?

    使用JPLAY的話,根本不必感謝bchsieh(逗你啦!),因為JPLAY早在N年前就幫我們搞定了;所以我當時測試HPET完全無感,只是忘了寫出來..... 我都是使用雙核心的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狂電!......

    上述所謂『假多核』是指 INTEL 的超執行緒(HT, Hyper-Threading),I3 與 I7、XEON 都是這種假核心,對CAT是極端扣分,請務必注意!

  19. The Following User Says Thank You to psycho For This Useful Post:


發文規則

  • 不可以發表新主題
  • 不可以發表回覆
  • 不可以上傳附件
  • 不可以編輯自己的文章
  •