|
|
發表於 2016-10-31 13:39:02
|
顯示全部樓層
本帖最後由 blau.vol 於 2016-11-1 08:32 編輯
Hi CKKeung hing,
其實. 一個fundemental problem is 佢只係將 24/192 變成 16/44.1 PCM bandwidth required file, 個情況exactly the same as realtime send 個 zip file 比我!!! 其實條algorithm 好似 JPEG 的different layers
要部DAC 係內部CPU 做 de-compression ( 等於要DAC 的FPGA/ CPU做 WinZIP 的 UNZIP 工序 ! 要大量 CPU/FPGA processing power => 即係變成高 Latency !!! 只會比真 PCM 24/192 更衰聲!
情形就好似play AIFF / flac 唔會好聲過 de-compressed raw WAV FILE . 原因就係部 Music Server or CAS system 要做 REAL TIME de-compression => 提高了部device 的latency !!
For the best performance, it will NOT better than original 24bit/192Khz ! the main benefit is good for outdoor listening! 唔會用太多 4G 無限plan 的數據量 !!!
如果我係家..... 我的SSD / NAS 又好多位! 為什麼要部DAC 做多一個de-compression 工序, 而唔比個raw 24/192 wave file (raw PCM stream ) 我部DAC 呢!!
佢而家的做法只係將 CAS 內 , 用JPlay / JRiver / HQPlayer 部 電腦粒 i7 CPU 做 aiff/flac de-compression ! 而家send 去比部 DAC 做, 比 FPGA 做 , 而家最大的問題係. 佢其實唔比人知 佢的 decoding algorithm!!! 要同佢買IC , 但粒 IC 係會影響成個 USB=> FPGA => Delta Sigma IC 個 chain的聲底的 !
so.... if I am using iPhone for playing Apple Music outdoor , 我明為什麼要行 MQA 壓縮 (or encoding) for streaming ,但 for serious 2 channel listening , 我唔明為什麼要做多一次 compression and de-compression !
Best,
Blau
|
評分
-
4
查看全部評分
-
|