Re: [心得] Foobar2000播放Tidal
: → oohack: Ownyn 可否明示怎麼做 爬了很多vst怎麼做還是不瞭 06/25 10:22
: 推 henrylol: 推推 Amazon沒原生ASIO只能靠偏方了 06/25 20:53
: → yys310: 沒有原生ASIO那用這有啥好處? 不也是wasapi給VB嗎 06/26 02:06
在某些限定前提下,沒原生還是可以在共用模式生出類獨佔,雖然要繞幾個彎
擷取沒支援音頻專用 I/O (獨佔)APP 輸出的 RAW Audio Streaming = BitPerfect
雖然這還是要看應用源端拉出什麼 RAW 東西到輸出讓後面的人撿
對 Windows Audio Stack 有些了解,大概就能推測能從哪些地方下手
再來就是試錯,最大的敵人不是邏輯、流程問題
而是各種程式與系統軟硬體、驅動、API 間的神奇相容性問題與 Bugs
各種程式、Plugins、API 就算明明是同功能的替換還是有很大機率不相容而出問題
&現在訂閱制串流當道
但不少串流 APP 都沒提供獨佔模式,甚至提供過但又收回
究其主因我猜跟獨佔模式能被簡單的無損側錄有關
Spotify 連聽個有損破離線檔都要綁個 30天 DRM 加密
想聽的集中錄一錄還有必要付一整年的錢!?
無損串流就更不用說了,訂無損串流送無損○
理論上合理使用不觸法,BUT
截共用模式 RAW Audio 出輸明明不是很困難很需要技術
但還真沒看過有歪國仁直接給完整詳細教學,不知道是不是怕有人來敲門:D(啊我也會怕
※
Exclusive mode 對輸出比較重要,因為要繞過 Windows 共用堆棧
Shaerd mode 是讓大家上車用的當然不能獨佔
Shaerd mode I/O Device 端點能用閒置沒在用的 H/W 像 Onboard or S/PDIF 端點來用
但最好還是找個 Virtual Cable 或多個來專用
單個可以切採樣率,多個可以各自不同採樣率選輸出(APP or default)
要完全的 BitPerfect,ASIO4ALL 不能用在 Shaerd mode I/O 要找其它的替代品
輸出至 DAC 最好還是原生ASIO,沒原生或不想用 WASAPI Exclusive 輸出才用 ASIO4ALL
※
另一種思路可從 Equalizer APO 上車,簡易關鍵字是用 ReaStream 下車
比較簡單也比較少相容性的問題,有需要切 Samplerate 的話也較少操作
※
有需要切輸出或採樣率可以用 SoundVolumeView.exe 設捷徑s 放桌面點選切換
Device Name=開程式,右鍵內容查該設備的 Command-Line Friendly ID
/SetDefaultFormat [Device Name] [Bits Per Sample] [Sample Rate-Hertz]
{Number Of Channels}
/SaveDeviceFormat [Device Name] [Filename]
/LoadDeviceFormat [Device Name] [Filename]
可組合一鍵切預設裝置&改採樣率,如
"%PATH%\SoundVolumeView.exe" /SetDefault "Device Name" 0 /SetDefaultFormat "Device Name" 24 44100
沒法像上面直接指定採樣率的可從 /SaveDeviceFormat 存的設定檔讀設定
"%PATH%\SoundVolumeView.exe" /SetDefault "Device Name" 1 /LoadDeviceFormat "Device Name" "Hi-Fi Cable 24-48000.dat"
※
VST Host 個人推薦
NanoHost @ https://www.tone2.com/nanohost.html
Element @ https://kushview.net/element/
Pedalboard2 @ https://www.niallmoody.com/work/pedalboard2/
相容性這東西只能各人各自去試
試到合用、不破輟音、延遲滿意、想用的 Plugins 能掛等
不過說真的,除非你真的很想要很 RAW 很 RAW 的 Audio 流,何必這麼麻煩
比起 BitPerfect 輸出
我個人更傾向有進行實時 DSP 的需求,才有導出 RAW Audio Streaming 的意義
CAudioLimiter 我個人不推荐
因為看 YouTube 直播碰到沒處理好音訊、沒設好音量的會破音破更大
但在犧牲共用模式通用性的前提
關掉 Windows CAudioLimiter 不失為改善單一應用音質的偷吃步
所以可以考慮用這個就好
--
人間五十年、化天のうちを比ぶれば、夢幻の如くなり
^,,,^ 一度生を享け、滅せぬもののあるべきか
(ミ‵ω′)\m/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.136.202.32 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1719495959.A.10D.html
推
06/27 21:50,
8月前
, 1F
06/27 21:50, 1F
推
06/27 22:23,
8月前
, 2F
06/27 22:23, 2F
推
06/27 22:32,
8月前
, 3F
06/27 22:32, 3F
要不要 Exclusive 都是看廠商覺得合不合算吧
因為 Exclusive mode 又不是什麼困難的技術
拉一拉現成的 lib API 就有獨佔輸出了也不用自己重寫底層
但是 Amazon music 的獨佔不就是個殘廢嗎XD
Amazon music 的獨佔想要 BitPerfect 還要滿足特定條件
所以 Amazon 也可能是故意的,反正對大多數用戶來說根本不知道什是獨佔
知道獨佔的人中不少可能對於有獨佔模式的意義大於 BitPerfect 內容
這就跟 Hi-Rez 中的超音波和 MQA 被拿來宣傳一樣
推
06/27 23:00,
8月前
, 4F
06/27 23:00, 4F
→
06/27 23:00,
8月前
, 5F
06/27 23:00, 5F
說真的個人感覺最能受益的不是無損、高清,而是水管這種爛音質XD
推
06/27 23:08,
8月前
, 6F
06/27 23:08, 6F
→
06/27 23:09,
8月前
, 7F
06/27 23:09, 7F
→
06/27 23:10,
8月前
, 8F
06/27 23:10, 8F
→
06/27 23:10,
8月前
, 9F
06/27 23:10, 9F
→
06/27 23:11,
8月前
, 10F
06/27 23:11, 10F
沒用 Amazon music 所以無法肯定
但 APP 可以檢測輸出端點的格式,再依格式轉換採樣率或位深
KS & WASAPI Exclusive 不支援 SRC,所以 APP 需要自行 SRC
大多數 APP 不會自行轉換,而是丟給後端(Audio engine or backend APP)
共用模式時,APP 本身用什麼 API 會直接影響 SRC 性能
因為不同的 Windows API 會呼叫不同的 lib SRC
WASAPI Shaerd mode SRC 品質不錯,DS > MME 品質跟 API 的年代掛鈎
推
06/27 23:37,
8月前
, 11F
06/27 23:37, 11F
→
06/27 23:37,
8月前
, 12F
06/27 23:37, 12F
→
06/27 23:38,
8月前
, 13F
06/27 23:38, 13F

→
06/27 23:39,
8月前
, 14F
06/27 23:39, 14F
→
06/27 23:40,
8月前
, 15F
06/27 23:40, 15F
→
06/27 23:41,
8月前
, 16F
06/27 23:41, 16F
Amazon music 應該是會 SRC 到 Device Capability(共用模式採樣率)
但基本上 SRC 品質跟 CPU 負載掛鉤
CPU Loading 不大、FIR's 延遲也不高的話,SRC 的品質也不太可能會好
推
06/27 23:46,
8月前
, 17F
06/27 23:46, 17F
→
06/27 23:46,
8月前
, 18F
06/27 23:46, 18F
SRC 基本上一般就是進行 Convolution=大量計算,沒什麼妖術能又快又好
推
06/27 23:48,
8月前
, 19F
06/27 23:48, 19F
推
06/27 23:51,
8月前
, 20F
06/27 23:51, 20F
→
06/27 23:51,
8月前
, 21F
06/27 23:51, 21F
但我會承認一點,就是乾淨不一定等於好聽XD
推
06/27 23:53,
8月前
, 22F
06/27 23:53, 22F
推
06/28 00:12,
8月前
, 23F
06/28 00:12, 23F
→
06/28 00:12,
8月前
, 24F
06/28 00:12, 24F
→
06/28 00:13,
8月前
, 25F
06/28 00:13, 25F
推
06/28 07:33,
8月前
, 26F
06/28 07:33, 26F
→
06/28 07:33,
8月前
, 27F
06/28 07:33, 27F
→
06/28 07:33,
8月前
, 28F
06/28 07:33, 28F
也不是一定要用 VST,是因為現在的數位後製(DAW)的發達源於 VST
所以在 Windows 平台要用 DSP 的話選 VST 算最通用
然後要 True BitPerfect 的話不能用 VB-Audio VoiceMeeter & ASIO Bridge
理由跟 ASIO4ALL 一樣,這類 APP & Wrapper & Bridge
對接的端點是 Device 的 Output Endpoint Buffer 所以不完美
這就有點像 Amazon music 的獨佔模式一樣
都要搞了當然是要吃生肉,而不是七分熟的料理包
關鍵字是無套中出(/ω\)
但 VST 也不是沒缺點,由於 VST 是為了數位後製
所以不論是 DAW or VST Host 都是以 Session or Project 的方式
開啟、執行一個工作,這讓標準的 DAW or VST Host 只有一組 I/O 很不方便
而這個 Session 也只有一個工作採樣率=I/O都要與其同採樣率帶來很大限制
這還讓 Drift Correction 的問題最大化
如果發生了很多突發短輟音,也很有可能不是因為 Buffer size 造成的
而是不同源時鐘的時差造成的同步問題,能解決但又要多繞個彎
這些鳥問題正是鳥鳥的 Windows Audio Enggine 在背後默默解決的
就像這樣心目中理想的流程架構是個空集合
很多東西想用,試下去能用,但跟某些東西搭配時會出問題
A跟B好不跟C好,B跟C好不跟D好,雖然不到女人的小圈圈但也夠麻煩的
不然就是驗證輸出時發現有問題不完美,就像上面的提到的例子 ( ‵ー′)ノ
→
06/29 03:14,
8月前
, 29F
06/29 03:14, 29F
→
06/29 03:16,
8月前
, 30F
06/29 03:16, 30F
→
06/29 03:16,
8月前
, 31F
06/29 03:16, 31F
上面這張圖中 VST 的出口標的 Ok,但 Voice Meeter 的點標錯了
https://i.imgur.com/LnUmnMi.png

這是 Windows 的音訊號處理模式
因為 VB-Audio Hi-Fi Cable or Virtual Cable 是虛擬 H/W 所以
所以依正常音頻路徑選 Audio Device I/O
VoiceMeeter 會跟 DAW or VST Host 一樣得到 H/W 的出輸
故 Virtual Cable + VoiceMeeter 的組合 or ASIO4ALL
音頻路徑並不透明,這個結果可驗證,但不少人依直覺以為通透:D
更細部去看
https://i.imgur.com/Cmq59gs.png

正常的 APP 依正常的 API 管道只能接觸到所謂的 Endpoint buffer
端點 Endpoint 也就是 API 與 API 間(App to App or Sys)交換資料的接點
也就是左邊描述輸入、右邊輸出的 EFX 這個 FX 的出入口位置(Endpoint FX)
※ 編輯: Oswyn (114.36.247.156 臺灣), 06/29/2024 12:09:06
推
06/29 13:20,
8月前
, 32F
06/29 13:20, 32F
→
06/29 13:21,
8月前
, 33F
06/29 13:21, 33F
→
06/29 13:21,
8月前
, 34F
06/29 13:21, 34F
→
06/29 13:22,
8月前
, 35F
06/29 13:22, 35F
→
06/29 13:22,
8月前
, 36F
06/29 13:22, 36F
討論串 (同標題文章)
Headphone 近期熱門文章
PTT數位生活區 即時熱門文章