第681頁,共714頁 第一第一 ... 181581631671679680681682683691 ... 最後最後
顯示結果從 6,801 到 6,810 共計 7137 條
  1. #6801
    註冊日期
    2020-12-31
    文章
    186
    Thanks
    307
    Thanked 505 Times in 168 Posts

    預設

    我之前劃了一個 300MB 的 partition,沒記錯的話用 Gutmann method 也要兩分多鐘(我的速度顯示為 2.2Mb/s 左右,比教授的快一點點)。

    Disk Wipe 對 Gutmann Method 的標註是 「extremely slow」。想像中可能真的龜速會比較接近原作者的描述
    此篇文章於 2022-11-03 08:53 PM 被 dequad 編輯。

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


  3. #6802
    註冊日期
    2007-09-12
    文章
    4,542
    Thanks
    3,509
    Thanked 5,476 Times in 1,850 Posts

    預設

    引用 作者: dequad 查看文章
    接 SATA 以及通過 USB 外接,在 Windows 下執行 Disk Genius 的 Erase Sector 對硬碟寫零(可以在 format 之前就 wipe),得到的預估完成時間一樣。抹寫速度的瓶頸可能不在連接方式(都好慢好慢好慢
    我是猜想:gangster.tank 的 GUT 非常明確地保證加強供電可以讓 GUT更有力,所以我會只相信經過 USB HUB 與 1500W 的外接硬碟,內接硬碟就沒有試過了。至於要不要發瘋再加上三個大電容還在苦惱中,苦惱的理由很欠扁:再加上三個大電容,獨孤救敗更不可能了!!

    引用 作者: dequad 查看文章
    我之前劃了一個 300MB 的 partition,沒記錯的話用 Gutmann method 也要兩分多鐘(我的速度顯示為 2.2Mb/s 左右,比教授的快一點點)。

    Disk Wipe 對 Gutmann Method 的標註是 「extremely slow」。想像中可能真的龜速會比較接近原作者的描述
    我看到 sam0402你們講的速度也嚇了一跳:那有可能麼快?話說在我的電腦,同樣大小的外接硬碟分割區,WIPE成FAT速度慢到只有 1.7M/sec;WIPE成NTSC速度快到近40M/S;然後WIPE成NTSC當然無效.......

    所以我大膽猜測速度差2.0M/S太多的(太快的),應該都有問題?.....

    後續補充:改內接速度快到60M/S,在電腦本身1500W的情況下,WIPE個10次就可以扺得上USB外接了!所以我都改成內接了。
    此篇文章於 2023-02-01 02:02 PM 被 psycho 編輯。

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


  5. #6803
    註冊日期
    2020-12-31
    文章
    186
    Thanks
    307
    Thanked 505 Times in 168 Posts

    預設

    引用 作者: dequad 查看文章
    RAM Disk 就等能上到 8000M Hz 的 Hynix A-die DDR5 普及後再試了。
    早上醒來,改變主意了。記憶體的硬體性能應該獨立看待;讓 JPlay 在 RAM Disk 上運作則是不同的考量。記得 sam 大好像提過用 RAM Disk 跑他寫的 ArchQ,聲音不甚滿意?但目前看起來, 若想再提升 JPlay 的表現,除了電腦性能繼續提高外,唯一沒試過而可能讓速度、延遲等客觀性能大幅提升的,大概就是用 RAM disk 載入作業系統。

    JPlay 討論區上與此相關的 Win11PE 主題已經出現快一年了。那個討論串剛開始的時候完全沒提到跑 JPlay;那時候我的 JPlay dual PC 有很多問題待解決,不敢多想,就沒再 follow。最近偶然看到那裡已經出現跑 JPlay 的討論,該仔細讀一下了。版上先進若在這方面已有經驗,還請多多分享
    此篇文章於 2022-11-04 08:37 AM 被 dequad 編輯。

  6. The Following 3 Users Say Thank You to dequad For This Useful Post:


  7. #6804
    註冊日期
    2014-08-02
    文章
    320
    Thanks
    0
    Thanked 788 Times in 273 Posts

    預設

    基本上來說,把所有 C:\JPLAY 的 registry keys 改為 X:\JPLAY 該是比較折衷的方法,反正已經有成功的例子,但是小弟不知道 JPLAY 的 activation 狀況會怎麼樣,因為只要更換了 HDD/SSD 也需要再跑一次 C:\JPLAY\TurboActivate.exe,而 Win11PE 則分為 RAM Boot/Flat BootUSB Boot 這幾種方式,或許最後的那一種比較簡單,但是小弟沒有試過:

    http://jplay.eu/forum/index.php?/top...clean/?p=60163
    Then, I opened up regedit and searched for "JPLAY" with CTRL+F, and used F3 to cycle through all of the results. I changed every instance of C:\JPLAY to X:\JPLAY, except a few. The ones I didn't change were the ones relating to the Start Menu, the Compatibility Assistant ones that are in binary format, and the ones that don't have a drive letter (e.g. "\Device\HarddiskVolume3\JPLAY\JPLAYSettings.exe") that are also in binary format. Everything else I changed. There are filepaths that show up multiple times, like "c:\jplay\jplaydriver64.dll", but I found that after you change one the first time, the repeats get changed automatically. This process of editing the registry only takes 5 minutes or so.
    另外 internethandle 兄建議使用 Registry Workshop

    http://jplay.eu/forum/index.php?/top...guide/?p=57758
    In my case, I found this too cumbersome, and simply would use another Registry editing program in my host OS (where my VHD’s were all located) such as Registry Workshop (but you could even just use normal Regedit) to load the hives from the mounted VHD in system32\config, make edits, and then unload the hive.


    那一位 Dev 網兄相當「風趣幽默」,這邊廂說修改 JPLAY 所屬的 registry keys 就會顯得 messy 云云,那邊廂就問如何修改 Win11PE 所屬的 registry keys(將全部 X: 改為 C:),然後就天曉得他選擇了甚麼方法。

    很久以前已經說了那是 hard-coded,隨便搜尋 Win11PE 的 registry hives 也可以找到成千上萬的 X: 例子:

    https://web.archive.org/web/20110203....com/kb/892846

    僅僅修改個別的 registry keys,真的不知道會變得怎麼樣了:

    https://msfn.org/board/topic/155495-...comment-990098

    https://msfn.org/board/topic/149173-...comment-951669

    並非說 Registry Workshop 那種 Find and Replace 不可行,只是說小弟已經放棄了那種途徑。



    Win11PE 還有很多可以優化之處,例如:




    大致上就是參考 Chanh/internethandle/keith_correa/samotc 或其他網兄分享的方法就不錯了,資料太多,不能盡錄。



    Chanh 兄的「三合一」系統比較有趣,Roon Core 2.0 不知道是跑 Linux 還是 Windows,假設那是 Linux 吧。

    HQPlayer 4 Embedded 就明顯是 Linux,而 NAA 就當然是 Win11PE 加上 Accuphase 的 ASIO driver。

    假如 UPnP Media Server(Control PC)由原來的 JPLAY 改為 sam0402 兄的 ArchQ 會不會變得更好聽呢?

    https://aur.archlinux.org/packages?K=upnp&SB=p

  8. The Following User Says Thank You to seeteeyou For This Useful Post:


  9. #6805
    註冊日期
    2017-02-14
    文章
    563
    Thanks
    1,660
    Thanked 1,638 Times in 458 Posts

    預設

    引用 作者: psycho 查看文章

    非常明顯的,由於一直播放絕對正確的數位檔,導致音響系統被『更進一步RUN開』;這個現象早就知道了:任何被我在中壢音響室操過的機器,聲音都會RUN得非常開。沒想到只是玩了幾天的GUT,音響系統又更進一步被RUN開了一大截!.....

    這點請一起玩GUT的同好映證看看?
    這點我在測試的時候也有發現,不管用什麼設備播放,哪怕是手機,只要播放過極致正確的wav檔案,那個設備就會被『Run 開』。

    特別是播完wav後跑去看YouTube發現連那些影片聲音都變好的時候,很明顯是被run開了。

    本以為是因為聽了GUT過的wav知覺變得更強,但看到教授的文章才恍然大悟,應該是真的被run開了點。

  10. The Following 3 Users Say Thank You to gangster.tank For This Useful Post:


  11. #6806
    註冊日期
    2017-02-14
    文章
    563
    Thanks
    1,660
    Thanked 1,638 Times in 458 Posts

    預設

    引用 作者: dequad 查看文章


    早上醒來,改變主意了。記憶體的硬體性能應該獨立看待;讓 JPlay 在 RAM Disk 上運作則是不同的考量。記得 sam 大好像提過用 RAM Disk 跑他寫的 ArchQ,聲音不甚滿意?但目前看起來, 若想再提升 JPlay 的表現,除了電腦性能繼續提高外,唯一沒試過而可能讓速度、延遲等客觀性能大幅提升的,大概就是用 RAM disk 載入作業系統。

    JPlay 討論區上與此相關的 Win11PE 主題已經出現快一年了。那個討論串剛開始的時候完全沒提到跑 JPlay;那時候我的 JPlay dual PC 有很多問題待解決,不敢多想,就沒再 follow。最近偶然看到那裡已經出現跑 JPlay 的討論,該仔細讀一下了。版上先進若在這方面已有經驗,還請多多分享
    我認為可以試試看把ArchQ或者JPlay放入GUT過的HDD再開啟,或許會更好一點,我目前就是這樣做。

    我的想法是:既然GUT能夠幫助WAV變得更正確,那麼對於軟體應該也是一樣的;順序變成 HDD/SSD ➝ GUT過的HDD ➝ Ramdisk。

    不知道對於『整個系統』是否也能採取這樣的做法,有沒有人先嘗試了?製作USB開機碟倒是能先把裡面的檔案都GUT一次。
    此篇文章於 2022-11-04 04:54 PM 被 gangster.tank 編輯。

  12. The Following 5 Users Say Thank You to gangster.tank For This Useful Post:


  13. #6807
    註冊日期
    2015-03-17
    文章
    552
    Thanks
    351
    Thanked 1,416 Times in 482 Posts

    預設

    引用 作者: gangster.tank 查看文章
    我認為可以試試看把ArchQ或者JPlay放入GUT過的HDD再開啟,或許會更好一點,我目前就是這樣做。

    我的想法是:既然GUT能夠幫助WAV變得更正確,那麼對於軟體應該也是一樣的;順序變成 HDD/SSD ➝ GUT過的HDD ➝ Ramdisk。

    不知道對於『整個系統』是否也能採取這樣的做法,有沒有人先嘗試了?製作USB開機碟倒是能先把裡面的檔案都GUT一次。
    感謝Gangster.tank兄提供新訊息,小弟把kernel 在Wipedisk (zerofill) 重新打包,效果很好!

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


  15. #6808
    註冊日期
    2020-12-31
    文章
    186
    Thanks
    307
    Thanked 505 Times in 168 Posts

    預設

    引用 作者: seeteeyou 查看文章
    基本上來說,把所有 C:\JPLAY 的 registry keys 改為 X:\JPLAY 該是比較折衷的方法,反正已經有成功的例子,但是小弟不知道 JPLAY 的 activation 狀況會怎麼樣,因為只要更換了 HDD/SSD 也需要再跑一次 C:\JPLAY\TurboActivate.exe,而 Win11PE 則分為 RAM Boot/Flat BootUSB Boot 這幾種方式,或許最後的那一種比較簡單,但是小弟沒有試過:
    ......
    seeteeyou 大在那個討論串是主要貢獻者之一 (在JPlay 討論區和其他很多發燒討論區也是 key contributor)。我目前跳著爬文剛看到第14頁,seeteeyou 大提到微軟的 Factory OS iso 裡面也有 64bit version 的 WinPE.wim。

    除了跑 JPlay 之外,另一個挑戰就是讓 DT2(我覺得 DT2 的聲音真的非常理想)跑 Kernel Streaming (KS) mode。

    如果能得到一樣好的聲音,我一定率先棄用 JPlay。最近幾個晚上試了分別用 M10、M15 和 900P 三款 Optane 和 NTFS、exFAT、ReFS 等不同檔案格式的組合當系統碟,作業系統也從 Windows Server 2022 Standard 改成 Windows Server 2022 Datacenter,其間受盡 JPlay 的啟用機制折磨。改用舊版的 JPlay 6.x (我沒用過)是不是可以避開現在版本的啟用機制呢?



    引用 作者: gangster.tank 查看文章
    這點我在測試的時候也有發現,不管用什麼設備播放,哪怕是手機,只要播放過極致正確的wav檔案,那個設備就會被『Run 開』。

    特別是播完wav後跑去看YouTube發現連那些影片聲音都變好的時候,很明顯是被run開了。

    本以為是因為聽了GUT過的wav知覺變得更強,但看到教授的文章才恍然大悟,應該是真的被run開了點。
    我的短期聽覺記憶不夠好,而且從教授提出 GUT 開始,我的電腦數位訊源經歷許多調整改變,所以沒辦法排除所有變項去判斷 GUT 對系統進一步 run in 的效果。只能說從實施 GUT 以來,好像什麼音樂都變得更好聽了。很愛聽的那張 Racha Arodaky 彈孟德爾頌無言歌,聲音從來沒那麼好過(這不是雜誌評論的老梗嗎
    此篇文章於 2022-11-05 07:23 PM 被 dequad 編輯。

  16. The Following 3 Users Say Thank You to dequad For This Useful Post:


  17. #6809
    註冊日期
    2020-12-31
    文章
    186
    Thanks
    307
    Thanked 505 Times in 168 Posts

    預設

    引用 作者: seeteeyou 查看文章
    大致上就是參考 Chanh/internethandle/keith_correa/samotc 或其他網兄分享的方法就不錯了,資料太多,不能盡錄。



    Chanh 兄的「三合一」系統比較有趣,Roon Core 2.0 不知道是跑 Linux 還是 Windows,假設那是 Linux 吧。

    HQPlayer 4 Embedded 就明顯是 Linux,而 NAA 就當然是 Win11PE 加上 Accuphase 的 ASIO driver。

    假如 UPnP Media Server(Control PC)由原來的 JPLAY 改為 sam0402 兄的 ArchQ 會不會變得更好聽呢?

    https://aur.archlinux.org/packages?K=upnp&SB=p
    終於把 JPlay 討論區那個 WinPE 討論串粗略看過一遍,尤其是最後幾頁。現在比較了解 seeteeyou 大的意思了。

    時間寶貴。未來就務實一點,分四路進行:
    1)JPlay:我看還是照 gangster.tank 上面提到的,以 GUT 加持就好;頂多用 RamOS 試試看。硬想要裝在極度精簡的 WinPE 上跑,最終可能只是浪費時間 (加上 License Expired... )
    2)ArchQ:sam 大的極致 Linux 播放系統,可能已經超越 JPlay。不知道版上有沒有人配合 DT2 用過?
    3)HQPlayer,加 WinPE 當NAA:那位 Chanh 兄的 WinPE 精簡到只剩七個程序在跑 。這個應該有機會用 DT2 KS mode。
    4)PureAsioPlayer (PAP):待進一步調查......

    也要留意一下 Diretta 這個介面。

  18. The Following 2 Users Say Thank You to dequad For This Useful Post:


  19. #6810
    註冊日期
    2014-08-02
    文章
    320
    Thanks
    0
    Thanked 788 Times in 273 Posts

    預設

    關於拷貝檔案的方式,主要分為兩大種類:

    https://github.com/EighteenZi/rocksd...d#introduction
    Direct I/O is a system-wide feature that supports direct reads/writes from/to storage device to/from user memory space bypassing system page cache. Buffered I/O is usually the default I/O mode enabled by most operating systems.
    Windows 還有兩種也不是的第三類:

    https://learn.microsoft.com/zh-tw/wi...g-data-buffers
    https://github.com/MicrosoftDocs/win...g-data-buffers

    很久以前曾經有樂友說 FastCopy 的那種 Direct I/O 比較好聽,效果如何則耳聽爲憑了:

    https://fastcopy.jp/archive/FastCopy4.2.1_x64.zip
    https://portableapps.com/apps/utilit...tcopy-portable

    重複拷貝數十或數百次之話就當然是使用那個 fcp.exe

    https://fastcopy.jp/help/fastcopy_eng.htm#cmdline
    https://topic.alibabacloud.com/a/fas..._31357058.html

    白水 啓章さん的網站:

    https://shirouzu.jp/profile
    https://groups.google.com/g/fastcopy
    https://github.com/FastCopyLab/FastCopy/issues

    另外還有其他 Go 語言的資源,Linux 和 Windows 兩者也適用:

    https://github.com/ncw/directio
    https://github.com/brk0v/directio
    https://github.com/eantcal/ioperm
    https://www.cnblogs.com/muahao/p/7903230.html
    https://www.oreilly.com/library/view...2/ch16s03.html



    基本上 hdparm 亦提供類似的選項,但是它的功用跟拷貝檔案沒有甚麼關係:

    https://man7.org/linux/man-pages/man8/hdparm.8.html
    代碼:
           --direct
                  Use the kernel´s "O_DIRECT" flag when performing a -t
                  timing test.  This bypasses the page cache, causing the
                  reads to go directly from the drive into hdparm's buffers,
                  using so-called "raw" I/O.  In many cases, this can
                  produce results that appear much faster than the usual
                  page cache method, giving a better indication of raw
                  device and driver performance.
    而另一選項則可以用來 wipe 指定的 sectors,不過好像是相當危險的說:
    代碼:
           --write-sector
                  Writes zeros to the specified sector number.  VERY
                  DANGEROUS.  The sector number must be given (base10) after
                  this option.  hdparm will issue a low-level write
                  (completely bypassing the usual block layer read/write
                  mechanisms) to the specified sector.  This can be used to
                  force a drive to repair a bad sector (media error).
    Linux 和 Windows 的版本:

    https://archlinux.org/packages/core/x86_64/hdparm/
    https://web.archive.org/web/20201019...attredirects=0



    還有這個比較特別的軟件:

    http://www.compulsivecode.com/Images/CopyInOrder.zip
    http://www.compulsivecode.com/Project_CopyInOrder.aspx
    This is a program for copying files and folders in alphabetical order. Windows rarely copies files or folders in the order you would expect.


    假如主機板能夠支援第二代或以上的 Xeon Scalable(例如 Xeon Silver 4215),Optane DCPMM(用來代替 RAM 的 Optane)還可以支援 DAX,可惜 Windows 只有 NTFS 能夠支援 DAX:

    https://learn.microsoft.com/zh-tw/az...access-methods
    https://github.com/MicrosoftDocs/azure-stack-docs/blob/main/azure-stack/hci/concepts/deploy-persistent-memory.md#access-methods
    Direct access (DAX), which operates like memory to get the lowest latency. You can only use DAX in combination with NTFS. If you don't use DAX correctly, there is potential for data loss.
    Linux 由核心版本 5.5 開始就支援 DAX:

    https://www.phoronix.com/news/Linux-5.5-HMEM-Driver

    相關軟件如下:

    https://github.com/pmem/ndctl
    https://archlinux.org/packages/extra/x86_64/ndctl/
    https://man.archlinux.org/man/extra/ndctl/daxctl.1.en

    看來並非那麼簡單,而且一般 Optane 也不支援 DAX,非 DCPMM 版本不可:

    https://tanelpoder.com/posts/testing...istent-memory/
    https://www.intel.com/content/www/us...ning-pmem.html



    Kernel Streaming 和其他資料就有待下回分解了。

  20. The Following 3 Users Say Thank You to seeteeyou For This Useful Post:


發文規則

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