推 danisaku: 感謝說明 06/27 21:50
推 uone: 感謝O大分享 06/27 22:23
推 yys310: 不過amazon自己就有exclusive了 這樣是為了拉音樂去處理? 06/27 22:32
要不要 Exclusive 都是看廠商覺得合不合算吧
因為 Exclusive mode 又不是什麼困難的技術
拉一拉現成的 lib API 就有獨佔輸出了也不用自己重寫底層
但是 Amazon music 的獨佔不就是個殘廢嗎XD
Amazon music 的獨佔想要 BitPerfect 還要滿足特定條件
所以 Amazon 也可能是故意的,反正對大多數用戶來說根本不知道什是獨佔
知道獨佔的人中不少可能對於有獨佔模式的意義大於 BitPerfect 內容
這就跟 Hi-Rez 中的超音波和 MQA 被拿來宣傳一樣
推 yys310: 恩...個人後面還要過DSP所以對bitperfect沒要求XD 講到超 06/27 23:00
→ yys310: 音波之前loopback amazon一些96/192的歌確實有看到超音波 06/27 23:00
說真的個人感覺最能受益的不是無損、高清,而是水管這種爛音質XD
推 yys310: 想問一下amazon輸出44.1/16bit到VB或其他裝置時 如果選192 06/27 23:08
→ yys310: kHz這時候做SRC的會是誰來做? 06/27 23:09
→ yys310: 之前用VB matrix輸出192時有看到1kHz像是NOS波形的輸出 忘 06/27 23:10
→ yys310: 記那時候是用foobar來產1kHz還是rew了 總之VB matrix再給 06/27 23:10
→ yys310: 後面的硬體然後用示波器看波形時看起來像是NOS直接輸出.. 06/27 23:11
沒用 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 的年代掛鈎
推 yys310: 3Q 我amazon開exclusive時他看起來確實也不會去改後面裝置 06/27 23:37
→ yys310: sample rate之類的 原來是故意這樣搞?XD 06/27 23:37
→ yys310: 出的RME裝置windows上只能看到一個支援的sample rate的關 06/27 23:39
→ yys310: 係 sample rate不同還能開exclusive感覺真怪 如果是foobar 06/27 23:40
→ yys310: 就直接說不能初始化裝置了 06/27 23:41
Amazon music 應該是會 SRC 到 Device Capability(共用模式採樣率)
但基本上 SRC 品質跟 CPU 負載掛鉤
CPU Loading 不大、FIR's 延遲也不高的話,SRC 的品質也不太可能會好
推 yys310: 瞭解...那看來真的弄個配合的來拉然後交給比較好的SRC比較 06/27 23:46
→ yys310: ok... 06/27 23:46
SRC 基本上一般就是進行 Convolution=大量計算,沒什麼妖術能又快又好
推 jhjhs33504: 一樣的設定 Core Audio Shaerd mode SRC 品質會更好些 06/27 23:48
推 yys310: 嗯嗯 自己OS升是想說至少符合取樣定理在22.05時衰減夠多XD 06/27 23:51
→ yys310: 不過反倒沒有去量這途徑下SRC品質了 06/27 23:51
但我會承認一點,就是乾淨不一定等於好聽XD
推 jhjhs33504: 真要繞過還是要透過ASIO才會綁定後面裝置sample rate 06/27 23:53
推 yys310: 就 之前打CCIF 19+20kHz如果走44.1會看到28k 29kHz多鬼影 06/28 00:12
→ yys310: 出來心理有點阿砸XD REW如果輸出更高的sample rate就不會 06/28 00:12
→ yys310: 看到 雖然是聽不出來拉XD 06/28 00:13
推 UnWf: 感謝說明 怎麼使用是稍微搞懂了 但還是有些疑問 以我的理解 06/28 07:33
→ UnWf: 音訊路徑是 :軟體輸出->共用模式->vst或voicemeeter 基本 06/28 07:33
→ UnWf: 上是看起來相同 那為什麼會建議使用vst更好呢? 06/28 07:33
也不是一定要用 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好,雖然不到女人的小圈圈但也夠麻煩的
不然就是驗證輸出時發現有問題不完美,就像上面的提到的例子 ( ‵ー′)ノ
→ UnWf: 所以意思是如上圖所示 vst是擷取音訊在進入Audio Enggine之 06/29 03:16
→ UnWf: 前 而voicemeeter的虛擬聲卡是接收在之後這樣嗎? 06/29 03:16
上面這張圖中 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
推 danisaku: 感謝說明 06/27 21:50
推 uone: 感謝O大分享 06/27 22:23
推 yys310: 不過amazon自己就有exclusive了 這樣是為了拉音樂去處理? 06/27 22:32
推 yys310: 恩...個人後面還要過DSP所以對bitperfect沒要求XD 講到超 06/27 23:00
→ yys310: 音波之前loopback amazon一些96/192的歌確實有看到超音波 06/27 23:00
推 yys310: 想問一下amazon輸出44.1/16bit到VB或其他裝置時 如果選192 06/27 23:08
→ yys310: kHz這時候做SRC的會是誰來做? 06/27 23:09
→ yys310: 之前用VB matrix輸出192時有看到1kHz像是NOS波形的輸出 忘 06/27 23:10
→ yys310: 記那時候是用foobar來產1kHz還是rew了 總之VB matrix再給 06/27 23:10
→ yys310: 後面的硬體然後用示波器看波形時看起來像是NOS直接輸出.. 06/27 23:11
推 yys310: 3Q 我amazon開exclusive時他看起來確實也不會去改後面裝置 06/27 23:37
→ yys310: sample rate之類的 原來是故意這樣搞?XD 06/27 23:37
→ yys310: 出的RME裝置windows上只能看到一個支援的sample rate的關 06/27 23:39
→ yys310: 係 sample rate不同還能開exclusive感覺真怪 如果是foobar 06/27 23:40
→ yys310: 就直接說不能初始化裝置了 06/27 23:41
推 yys310: 瞭解...那看來真的弄個配合的來拉然後交給比較好的SRC比較 06/27 23:46
→ yys310: ok... 06/27 23:46
推 jhjhs33504: 一樣的設定 Core Audio Shaerd mode SRC 品質會更好些 06/27 23:48
推 yys310: 嗯嗯 自己OS升是想說至少符合取樣定理在22.05時衰減夠多XD 06/27 23:51
→ yys310: 不過反倒沒有去量這途徑下SRC品質了 06/27 23:51
推 jhjhs33504: 真要繞過還是要透過ASIO才會綁定後面裝置sample rate 06/27 23:53
推 yys310: 就 之前打CCIF 19+20kHz如果走44.1會看到28k 29kHz多鬼影 06/28 00:12
→ yys310: 出來心理有點阿砸XD REW如果輸出更高的sample rate就不會 06/28 00:12
→ yys310: 看到 雖然是聽不出來拉XD 06/28 00:13
推 UnWf: 感謝說明 怎麼使用是稍微搞懂了 但還是有些疑問 以我的理解 06/28 07:33
→ UnWf: 音訊路徑是 :軟體輸出->共用模式->vst或voicemeeter 基本 06/28 07:33
→ UnWf: 上是看起來相同 那為什麼會建議使用vst更好呢? 06/28 07:33
→ UnWf: 所以意思是如上圖所示 vst是擷取音訊在進入Audio Enggine之 06/29 03:16
→ UnWf: 前 而voicemeeter的虛擬聲卡是接收在之後這樣嗎? 06/29 03:16
推 yys310: 有什麼好方法確認軟體叫了哪些API跟走哪些管道嗎?foobar, 06/29 13:20
→ yys310: MPC我測起來覺得走DS的效果也很好 可是amazon music的DS爛 06/29 13:21
→ yys310: 得跟屎一樣 然後他的exclusive真的就只是勿擾模式XD 內容 06/29 13:21
→ yys310: 一樣爛 要自己手切sample rate+做一些預衰減才會好些 不過 06/29 13:22
→ yys310: 也只能還算是差強人意 06/29 13:22