PTT數位生活區 / Headphone (耳機)

[問題] 音源格式與藍芽編碼方式

看板Headphone (耳機)作者 (離自相空她相)時間5年前 (2020/12/12 02:48), 編輯推噓8(8推 0噓 50→)
留言58則, 9人參與, 最新討論串1/1
我查到 SBC 是 source > pcm > sbc > pcm > source 不知道 aac、aptX 是不是也是這樣類推, 假設使用 mp3 160k.經由 sbc 到 tws+ 藍芽耳機, 因為 A2DP 的限制,剛好達到雙通道 320k 的上限? 所以如果是超過 160k 的 mp3,就應該用 aptX,這樣才能得到比 sbc 更好的效果? 如果是 128k 以下的 mp3,乾脆用 sbc 聽聽就算了~ 我這樣的理解對嗎? 所以,你們這些聽 B&O、M&D、Sony、森海 藍芽的大佬, 是都用 192k 以上的 mp3 在當音源,還是都上 flac 這種號稱無損的音源了? -- 讀者審校網試行版(2018/1/1 更新網址) http://readerreviewnet.processoroverload.net/ (哲、史、法、政、經、社，人文翻譯書籍錯譯提報網) ◎洪蘭"毀人不倦"舉報專區 http://tinyurl.com/ybfmzwne 讀者需自救，有錯自己改... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.250.90.238 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1607712508.A.030.html
→
12/12 03:01, 5年前 , 1F
不是，然後鼻要沒理解完全就開嗆。醬不行~
12/12 03:01, 1F
→
12/12 03:03, 5年前 , 2F
我沒有嗆啊,我只是問聽貴藍芽耳機的大佬們都用什音源.
12/12 03:03, 2F
→
12/12 03:05, 5年前 , 3F
然後我就是查不到 sbc,aac,aptX 的傳輸差異比較表,
12/12 03:05, 3F
→
12/12 03:05, 5年前 , 4F
sbc 被限制是囿於規格太早訂，不然他理論上可以開到
12/12 03:05, 4F
→
12/12 03:05, 5年前 , 5F
1k kbps 。然後 ldac 在沒炸炸的時候，可以到 990
12/12 03:05, 5F
→
12/12 03:05, 5年前 , 6F
kbps。aptx hd 也可以到 576 kbps
12/12 03:05, 6F
→
12/12 03:06, 5年前 , 7F
所以只好來問問到底有啥不同跟音源格式分界點
12/12 03:06, 7F
→
12/12 03:07, 5年前 , 8F
我查到的資料是,雙通道時 sbc 理論上可以到 512k,但是
12/12 03:07, 8F
→
12/12 03:07, 5年前 , 9F
然後藍牙主要還是在功能性上。所有無線傳輸的東西，
12/12 03:07, 9F
→
12/12 03:07, 5年前 , 10F
都有很多干擾（ex 2.4Ghz 的吵雜環境
12/12 03:07, 10F
→
12/12 03:08, 5年前 , 11F
A2DP 限制雙通道上限是 328K,所以 sbc 無法突破 328k?
12/12 03:08, 11F
→
12/12 03:09, 5年前 , 12F
在 lineageos 16 版有實作 sbc xq https://bit.ly
12/12 03:09, 12F
→
12/12 03:09, 5年前 , 13F
/379Gon5
12/12 03:09, 13F
→
12/12 03:09, 5年前 , 14F
然後雙通道是 328k,所以只看一邊,是不是要 /2 ?
12/12 03:09, 14F
→
12/12 03:09, 5年前 , 15F
12/12 03:09, 15F
→
12/12 03:10, 5年前 , 16F
https://bit.ly/340LwaP 這篇講蠻詳細的
12/12 03:10, 16F
→
12/12 03:12, 5年前 , 17F
btw 要用有損格式的話，推薦無腦轉成 opus
12/12 03:12, 17F
→
12/12 04:07, 5年前 , 18F
BT 有 2ch、 那 MP3 有沒有 2ch，需不需要 /2 :D
12/12 04:07, 18F
→
12/12 04:13, 5年前 , 19F
有損轉有損，會比無損轉有損更有損。一般餵編碼器越精確的
12/12 04:13, 19F
→
12/12 04:13, 5年前 , 20F
數據(高碼率)會得出越好的結果，因為錯誤(有損誤差)會累積
12/12 04:13, 20F
→
12/12 04:22, 5年前 , 21F
MP3 解成 PCM 後 160/320kbps 都不再有意義，因為它會變成
12/12 04:22, 21F
→
12/12 04:23, 5年前 , 22F
44.1 or 48k、這個 PCM 跟原始無損之間的差異=失真/噪聲
12/12 04:23, 22F
→
12/12 04:23, 5年前 , 23F
這個解開後的數據再送進 MP3 壓同碼率也只會產生更多失真
12/12 04:23, 23F
→
12/12 04:23, 5年前 , 24F
送進 SBC or aptX 也是同樣，所以餵無損會比較好
12/12 04:23, 24F
推
12/12 04:38, 5年前 , 25F
樓上O大，有損>無損>有損的過程會不會產生更多失真要
12/12 04:38, 25F
→
12/12 04:38, 5年前 , 26F
看演算法，如果是同一種有損格式的話，有機會不添加更
12/12 04:38, 26F
→
12/12 04:38, 5年前 , 27F
多失真
12/12 04:38, 27F
→
12/12 06:36, 5年前 , 28F
在數學上不可能有這機率，有損解出來的數據不會＝原始無損
12/12 06:36, 28F
→
12/12 06:37, 5年前 , 29F
a 不等於 b、b 不等於 c、c不會這麼幸運等於a
12/12 06:37, 29F
→
12/12 06:37, 5年前 , 30F
編碼計算總會小數無窮盡就算是浮點也有量化問題不會無損
12/12 06:37, 30F
→
12/12 06:37, 5年前 , 31F
做個簡單實驗，Source file a 是 1 kHz 30sec 的 320k mp3
12/12 06:37, 31F
→
12/12 06:37, 5年前 , 32F
1 kHz 還是 1 kHz 但 99.74% 的採樣點數據都不同了
12/12 06:37, 32F
→
12/12 06:37, 5年前 , 33F
12/12 06:37, 33F
推
12/12 06:54, 5年前 , 34F
同樓上，網路謠傳藍牙用AAC聽AAC就沒有二度破壞絕對是錯的
12/12 06:54, 34F
推
12/12 07:00, 5年前 , 35F
另外我會把藍牙連線的取樣率設定成跟音源一樣，避免多一次S
12/12 07:00, 35F
→
12/12 07:00, 5年前 , 36F
RC的破壞，這目前就Android最方便改，加上用UAPP聽FLAC破壞
12/12 07:00, 36F
→
12/12 07:00, 5年前 , 37F
就只剩藍牙的編碼
12/12 07:00, 37F
→
12/12 08:29, 5年前 , 38F
x大，那要先看AAC編碼解碼的演算法和參數是否相同，而
12/12 08:29, 38F
→
12/12 08:29, 5年前 , 39F
走藍芽的話，編碼器的參數或演算法通常就不一樣了
12/12 08:29, 39F
→
12/12 08:36, 5年前 , 40F
回O大，先感謝實驗，但mp3實在不是一個很好的例子。 FF
12/12 08:36, 40F
→
12/12 08:36, 5年前 , 41F
T+DCT的轉換數學上也不是那麼可靠。 我猜測AAC有機會達
12/12 08:36, 41F
→
12/12 08:36, 5年前 , 42F
成我前面提到的機會，不過沒有實驗過，只是覺得數學上
12/12 08:36, 42F
→
12/12 08:36, 5年前 , 43F
有機會。
12/12 08:36, 43F
推
12/12 08:38, 5年前 , 44F
所謂的參數相同也避免不了二度破壞，因為進藍牙晶片的是整個
12/12 08:38, 44F
→
12/12 08:38, 5年前 , 45F
系統的聲音，要經過系統的混音器，不可能把AAC檔原封不動的
12/12 08:38, 45F
→
12/12 08:38, 5年前 , 46F
給藍牙接收段的AAC去解，所以我提UAPP加上取樣率配對就是盡
12/12 08:38, 46F
→
12/12 08:38, 5年前 , 47F
量避免系統混音器的負面效果
12/12 08:38, 47F
推
12/12 08:40, 5年前 , 48F
雖然聽不懂，還是先推了
12/12 08:40, 48F
推
12/12 11:49, 5年前 , 49F
藍牙轉換的鬼太多 還是建議用較高的藍牙編碼啦
12/12 11:49, 49F
→
12/12 12:22, 5年前 , 50F
沒一個有損包括 AAC 的頻率響應是平的，就是為什麼不可能啦
12/12 12:22, 50F
→
12/12 12:42, 5年前 , 51F
12/12 12:42, 51F
→
12/12 12:42, 5年前 , 52F
第一次壓完後的差異，會被第二次當成有效內容造成更多差異
12/12 12:42, 52F
→
12/12 12:45, 5年前 , 53F
這些差異會吃掉 bitrates、讓原始頻率的可用 bitrates 變低
12/12 12:45, 53F
→
12/12 12:46, 5年前 , 54F
所以有損編碼後再編碼會音質下降是肯定的
12/12 12:46, 54F
推
12/12 13:08, 5年前 , 55F
這也是為何蘋果有獨門的 Apple Digital Masters 工具，
12/12 13:08, 55F
→
12/12 13:08, 5年前 , 56F
母帶直出 AAC 上 iTunes 然後一路全家餐不用再轉 codec
12/12 13:08, 56F
→
12/12 13:08, 5年前 , 57F
一直到耳機 H1 處理器還原。
12/12 13:08, 57F
推
12/15 00:07, , 58F
還是會有果黑出來說音質差的
12/15 00:07, 58F
‣ 更多 freeunixer 的文章
文章代碼(AID): #1Vqxxy0m (Headphone)
Headphone 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 freeunixer 的文章
文章代碼(AID): #1Vqxxy0m (Headphone)