第293頁,共715頁 第一第一 ... 193243283291292293294295303343393 ... 最後最後
顯示結果從 2,921 到 2,930 共計 7142 條
  1. #2921
    註冊日期
    2007-05-16
    文章
    720
    Thanks
    180
    Thanked 152 Times in 111 Posts

    預設

    此篇文章於 2016-07-13 10:27 AM 被 rendzaw 編輯。
    CALL:0932-377626黃先生



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

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

    預設

    此篇文章於 2016-07-13 10:26 AM 被 rendzaw 編輯。
    CALL:0932-377626黃先生



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

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

    預設

    好用的copy.com已無法使用。
    CALL:0932-377626黃先生



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

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

    預設

    很抱歉,拖了很久。

    一直想要把內容整理得有條理一點,但是想寫的東西又多又雜,只好想到什麼寫什麼。

    小弟再強調一次,這些只是小弟的想法,並不一定正確。如果有前輩發現小弟有任何地方說錯了,請指正小弟。

    先說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。
    也就是記憶體和硬碟在實體層放資料的方式,由於種種原因,其實不像我們想像的那樣規律。

  5. The Following 3 Users Say Thank You to bchsieh For This Useful Post:


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

    預設

    對了,順道一提...

    最近看了一篇有趣的文章,想辦法用盡量科學的方式,量化聲音的品質,來判斷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

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


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

    預設

    引用 作者: bchsieh 查看文章
    對了,順道一提...

    最近看了一篇有趣的文章,想辦法用盡量科學的方式,量化聲音的品質,來判斷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

    這篇前幾天有瞄到,研究過程看不懂,但結論就比較容易理解。
    怕各位懶得看,小弟雞婆,把結論轉貼出來:

    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.

  9. The Following 2 Users Say Thank You to awuwa For This Useful Post:


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

    預設

    有很多這裡討論分享的同好也在 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 的功能了?病好了趕快上來教教我!........

    2、cuda 的 rip,的確聲音好上一截!殘響多了一點,動態對比好了一點。

    3、但是,就是這個但是......原本我使用 jplay雙cat,兩者幾無差異;後來把audio pc設為『不是H模式』,才輕易聽出CUDA的 RIP檔聲音好一截。依我個人選擇,凡是使用雙CAT與H模式而『減小差異』的,我會列入比較不重要的考量。理由是這表示該差異比較是在DETERMINATE JITTER層次而不是RANDOM JITTER層次,那麼最簡單的方法不是處理CAT,而是換一台超高水準的DAC就好了。

    4、可是我還是要說,這個錄音水準跟我偏好的新天新地唱片有『非常誇張的差距』 。我獨尊CAT,正是希望透過我推薦的cat與音響器材,可以讓大家對錄音水準或演奏水準要求可以變得更嚴苛些......所以真希望大家可以透過cat系統見識到不同的錄音世界。

    5、至於有一個鬧場還敢拿我寫的文章抹黑別人的XX,那個垃圾級的rip,動態對比輸一大截的大花版cd居然沾沾自喜以為rip很好......那就請大家同情大概是嚴重木耳居然會燒壞腦袋..........

    (end)

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


  12. #2928
    註冊日期
    2007-06-07
    文章
    3,243
    Thanks
    3,174
    Thanked 2,972 Times in 1,404 Posts

    預設

    用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

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

    預設

    引用 作者: psycho 查看文章

    [恕刪]

    1、經過foobar2000擴充功能的二進位比較,兩者完全一模一樣。我好像被 bchsieh 誤導 CUDA 的功能了?病好了趕快上來教教我!........

    [恕刪]
    教授,抱歉,因為之前生病在工作上進度落後許多,最近正忙著趕進度。

    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介面是不是能加強音質。
    此篇文章於 2016-07-22 01:04 PM 被 bchsieh 編輯。

  14. The Following 5 Users Say Thank You to bchsieh For This Useful Post:


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

    預設

    引用 作者: bchsieh 查看文章

    前面大部分網兄提到HQPLAYER對聲音有很大幫助的原因,是來自於升頻以及數位濾波。
    如果有使用GPU,升頻和數位濾波的速度當然大幅度提升,latency降低非常多,聲音一定比「單純使用CPU做升頻和數位濾波運算」好非常多。

    但小弟有興趣的是,如果在bit perfect播放下,GPU的幫助是不是真的能讓聲音變好?
    HQPLAYER已經確定非bit perfect的播放器了。
    接下來如果有網兄願意,可以試試看使用JPLAY等bit perfect播放器,透過NVidia介面是不是能加強音質。
    HQPLAYER不能完全關閉DSP,單純decode輸出嗎?

    照理說應該會在UI中提供disable的選項??

發文規則

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