Re: [心得] AirPods Max 不專業心得

[kblover (聖貓天使)]

看到這篇文章很用心  但我看到一些點覺得有些似是而非

基本上不是做apple底層的人是看不到他的系統架構的

但基本上audio的東西殊途同歸  這裡我一點一點來看

※ 引述《elguapo (HPHT Synthesized)》之銘言：
:   不好意思這篇並未引用前面的文，僅概略說明 Apple AAC 在製作這端的相關
:   流程，希望再看到 AAC 能有比較正確的認知。
:   關鍵字：Apple Digital Masters, Core Audio, AAC
:   蘋果在家族系統都有建置 Core Audio，從 iOS、macOS、tvOS 到 watchOS
:   都有 Core Audio。這個東西能吃的音樂檔案蠻多類型的，不一一贅述，但要
:   提的地方是，無論什麼音檔，進了 Core Audio 都會藉系統底層的服務轉為
:   Core Audio File（縮寫是 CAF），AAC 音檔進入 Core Audio 也是如此，會
:   成為 CAF 再播放。
:   這個 CAF 基本屬性是「線性 PCM」，最大優點是檔案可以理論無限制的大，
:   所以長時間錄音不會受限制。當音訊處理作業完成之後，CAF 會再依使用者
:   需求轉成特定格式（這也是系統底層的功能），例如 AAC。

Core Audio查了一下就是apple的audio framework

基本上這種東西他能decode/encode什麼檔案
就是看cpu這端有做什麼sw decoder，或是他的hw decoder有support什麼格式

然後你整篇都在講CAF  這東西資料不多  基本上只看到一個不同
就是他沒有單一檔案限制大小4GB以下  這是他跟AIFF/WAV格式不同

但內容我怎麼看他就是PCM   沒有任何不同
然後可能再處理的時候用float而不是int

這裡就跟android framework是一樣的  套用effect的時候會用float處理
所以說穿了也沒什麼神力

:   AAC 到底好不好？這讓人爭論已久，我就針對錄音製作這一端解釋一下為何
:   這個 codec 可以在蘋果全家餐通行而能有一致的音質。

AAC不是codec
應該說  你不會稱呼AAC是codec.......他是一種編碼方式

:   蘋果在 2019 把原來 Mastered for iTunes 改為 Apple Digital Masters。
:   如果製作完成的音檔要送上 iTunes Music Store 或是 Apple Music 服務，
:   要掛上 Apple Digital Masters 的專屬標籤的話，基本要求是 24-bit 音源。
:   要如何確認自己的送件的音樂能在 256kbps 的頻寬下有接近母帶的品質呢？
:   在 macOS 底層服務中，有工具可以分析經 AAC 轉換之後有無發生 clipping
:   （信號爆高 >0dB），另外也有工具可以直接比對 AAC 轉換前和轉換後的 CAF
:   檔案，看差異狀況然後再回到 DAW 調整混音或是用外掛修正，儘可能在製作
:   端去讓 CAF 壓縮前後差異不大；這是作品送件前很重要的一個步驟，來確保
:   上傳給蘋果之後、在其他設備的 Core Audio 呈現的 CAF 接近原始，這是
:   Apple Digital Masters 的眉角。

你講的這東西跟AAC本身無關

你講的事情  代表上傳給APPLE的AAC檔案不可以很懶惰隨便轉就傳上去

你必須把你初步壓縮過的AAC抓下來聽聽看
如果不好  還可以針對原始檔調整一下，再轉AAC

簡單講...就是母帶->預處理->轉AAC file

就是多一個預處理的步驟  目的是調整聽感

但他不會改變你是有損壓縮這件事情

:   蘋果耳機的 H1 晶片，相信是為了跑一個迷你的 Core Audio 而設，在耳機
:   恢復成 CAF 再播放出來，而這個 CAF 基本上就是原製作 submit 出去的東西，
:   在播放端可以再用一些適應性 EQ 去調整聽感。

我有點懷疑這件事情
H1要做的事情應該不用把整套audio framework port上去

這太浪費了

:   如果只看 AAC 只有 256kbps 就說她爛，我想這是很大的誤會，或是認為音檔
:   一下 AAC 一下 PCM 一下 AAC 會讓音檔品質更爛，但實際上蘋果給您的 Apple
:   Digital Masters 的 AAC 自始至終就那麼一個，中間除非人為刻意，否則呈現
:   的 CAF 是跟源頭一樣的（或應正名為是「傳輸無損」而非「壓縮音損」）。

256kbps AAC decode出來的PCM就不是原始檔的PCM了

不然AAC的演算法寫假的喔

你再怎麼調預處理都還是一樣  最多調到聽感類似而已

你說母帶的PCM會跟AAC decode出來的PCM一樣

這個齁
我是覺得不知道你怎麼得出來的結論拉....

之所以要用AAC  目的就是節省儲存空間  代價就是損失原始資料

:   以上解釋希望能幫助大家了解 Apple Digital Masters，謝謝大家撥冗觀看。
:   下台一鞠躬 Orz

最後你說FLAC是有損壓縮會影響聽感

怎麼看到都覺得不會  FLAC自己專案都寫人家是每一個 PCM bit都可以還原

然後該文太長我懶得看完  我去看一下分析的圖表跟結論我快暈倒

To summarize, we have found at least four different
reasons why the lossless FLAC compression format
degrades the SQ when compared with uncompressed WAV
files. These are:
1. The pixel size and file size of the cover art
attached to the metadata (MDA);

看到第一點我就笑到看不下去

翻譯:壓縮後的封面照片檔會影響音質
這種有夠白癡的結論虧他寫的出來....

根本不同區塊的東西是要怎麼互相影響拉 XD

這文組做的實驗吧

好啦，以上是一點討論

做一點總結  AAC終究是AAC  他的目的就是犧牲品質換取空間....

做串流本來就是方便第一  花這麼多時間去討論這東西

你還不如花時間去改善傳輸介面  讓介面可以直接快速穩定傳原始檔就好 XD

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.251.61.121 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1610959728.A.EFA.html
推 djboy: elguapo網友對apple/aac的解釋是很ok的，挑啥AAC不是CODEC
→ djboy: 這種語病，就有點無聊。 最後推文中對FLAC的評論倒是頗有爭
→ djboy: 議。我也查了資料，FLAC壓縮是在數學上被認定的，所以要打
→ djboy: 破是極難。因此，那篇論文，可能要細究一下他的量測法。我
→ djboy: GOOGLE到一篇FLAC的驗證文章，就是講到其量測點的問題。
AAC應該是一種編碼格式
你是透過codec去decode成PCM，或是透過codec把PCM encode成AAC
直接說他是codec會有點奇怪而已~

推 greg7575: 喜歡這種抓出白痴的文
推 rugger5566: 你說的也是，壓縮了就是壓縮了，而且還是有損壓縮，怎
→ rugger5566: 麼都很難救回來
推 dzwei: 其實我反而比較希望在耳機板看到DSD vs PCM 大戰
→ dzwei: 這個就有很多paper了，IEEE就有幾篇了
→ dzwei: 但目前的共識是：各有優缺 這樣
→ dzwei: 抱歉歪樓了 拉回來一下
推 xoy: 幾個無損音樂格式的差異是常看到的話題沒錯，不過我覺得差異
→ xoy: 遠比蘋果所謂特調又加持的AAC檔案來的小
推 hsinggg: 因為壓了就是壓了，讓人感覺差不多是用心調整，也是一種
→ hsinggg: 做法
推 Dustdusk: 所謂的有損壓縮就是指無法還原
→ Dustdusk: 再怎麼神通廣大都只是模擬
→ Dustdusk: 當然聽起來如何又是一回事
推 elguapo: Core Audio 不支援 FLAC 合先敘明。FLAC 理論的壓縮還
→ elguapo: 原如您所說的驗證堅若磐石，但 Mac 或 iPhone 使用 FLAC
→ elguapo:  是需要轉一手的，那麼這一手會產生多少影響可能還要再
→ elguapo: 研究，第三方怎麼解釋 FLAC 怎麼放入 Core Audio 我也
→ elguapo: 很好奇是否如 FLAC 宣告般完整，故我個人在 Mac 應用上
→ elguapo: 是走向保守認為是或許有損的。
這倒是不用懷疑
他在PCM data的部分就是完全無損

如果不是早就被踢爆了
沒有什麼在mac上面就會走向有損這種事情

FLAC解壓縮後  他就是有一塊可以直接丟給codec轉換的PCM buffer
當然這塊pcm buffer也能在壓縮成AAC餵給後端的airpods之類的

但沒有什麼保守不保守  蘋果沒有這麼偉大

推 elguapo: 另外，蘋果的確稱 AAC 為「codec」https://imgur.com/CM
→ elguapo: 2Az6n相關文件都在 Developer 網頁能找到。
→ elguapo: 對不起推文 URL 跑掉
→ elguapo: https://imgur.com/CM2Az6n.jpg
推 elguapo: kb大您是對的。AAC是data type並非codec。
→ elguapo: 對不起我才疏學淺 Orz
XD  沒事沒事

推 elguapo: 另外... @greg7575 請您去查閱我寫的東西跟蘋果相關文
→ elguapo: 件寫不一樣的地方，找出來批評指教我會很高興接受，但
→ elguapo: 如果您的留言是針對我罵我白痴的話，我也只能請版主處
→ elguapo: 理了。
https://tinyurl.com/yagn9mrm

他應該是說你貼的這篇研究是白癡文吧 冷靜冷靜

推 rickylin: 很有興趣H1到底有否Core Audio架構在裡面？就靠大家解密
這沒什麼好研究的

應該是根本不需要....

→ rugger5566: 大家火氣小一點啊QQ
推 WiLLSTW: 幹嘛要另外弄個晶片再處理一次Core Audio
→ WiLLSTW: 我覺得有些人根本就是邏輯問題
→ WiLLSTW: 每個藍芽耳機因為要解碼都有晶片 只是Apple取個酷炫潮的
→ WiLLSTW: 名字吸引人掏錢買而已
到也不是 要能做那些空間音效，或是套EQ
H1這顆DSP應該是功能滿強大的沒錯~
※ 編輯: kblover (111.240.116.58 臺灣), 01/18/2021 20:46:54
→ elguapo: https://tinyurl.com/yykmwl4x
→ elguapo: ifixit 有 Max 的拆解圖，也有推估那張晶片在做什麼事
→ elguapo: 。基本上 H1 是 SoC，解碼轉 PCM 不是大問題。
推 WiLLSTW: 恩 還有降噪也要用那顆H1跟一些感應器之類的 基本上每間
→ WiLLSTW: 產品都有類似的東西 功用多跟少的問題
推 rugger5566: 用2顆的好處是？降噪嗎？
→ WiLLSTW: 果粉講成甚麼萬能的科技就不必了
→ WiLLSTW: Airpods 也有兩顆 可能設計就是要兩顆分開處理(?)
推 WiLLSTW: 畢竟這晶片用了好幾款了 如果沒大改設計大概大同小異
推 rickylin: 可以參照一下Dolby Dimension那顆Snapdragon做了什麼
→ rickylin: 或許可以了解跟一般無線藍芽降噪耳機晶片功能有何差別
→ bben900911: oh my god........死灰復燃
推 good151617: 不妨由r大整理回文讓大家知道差異跟基準點呢？
推 good151617: 不然回覆都是可能、有機會、或許可以，造福版友也不
→ good151617: 錯
推 rattrapante: 果粉都喜歡叫人study  嘻嘻
推 greg7575: @elguapo 抱歉喔，我不是說你白痴。
→ greg7575: 如果你覺得自己被形容成白痴，那是你的感覺而非我本意
→ greg7575: 如果你覺得我的推文讓你變成白痴，那我未免也太強大了
→ greg7575: 我指的是過份腦補的人，跟白痴一樣。
推 greg7575: 果粉每個都大師，這樣子你會不會生氣？
推 greg7575: 蘋果沒有說的東西，果粉自己腦補說有
→ greg7575: 還要求別人要絕對認同他的腦補。還要別人拿出證據
→ greg7575: 這種討論的方式真的是齁，越講越累啦
→ greg7575: 沒有獨角獸，果粉要求別人拿出沒有獨角獸的證明
→ greg7575: 否則就是有獨角獸。這裡有馬，這裡有角，摻一起就有了
推 lovez04wj06: 搞惡魔的證明真的是論述之恥
推 greg7575: 還有一種人叫槓精，人家在講a他要扯b
→ greg7575: 把b講得頭頭是道，然後他的a就一定是對的
→ greg7575: 指出他的a錯，他就說可是我b沒錯
→ greg7575: 小心邏輯殺手：槓精
推 djboy: 我不覺得elguapo的回文有啥問題，尤其他又自己做實驗，還
→ djboy: 找了PAPER來證明自己的觀點。
→ djboy: 倒是greg7575，除了講人白痴、酸人與無營養的推文，才是
→ djboy: 真的讓人看不下去。
那篇後來多看了一下只是一家音響雜誌自己亂寫的文
那種東西稱為論文真的是污辱了論文這兩字

推 lovez04wj06: 腦補文的營養價值可能比較高
推 rgbff: 我封面圖片都放阿爾卑斯山雪山，聽起來會有一種空靈感
我都不放  聽起來有飄渺虛無感
※ 編輯: kblover (122.147.213.24 臺灣), 01/19/2021 11:04:15
→ m9172250: 垃圾食物比較可怕(？
推 greg7575: 嘻嘻
→ greg7575: djboy 你超強的
推 greg7575: 分析精準，邏輯通暢。小失誤也不影響大局
推 rattrapante: 我封面都要放4k解析的圖片
→ rattrapante: 這樣音樂的線條感還有分離度才會好
→ rattrapante: 聽大編制音樂效果尤其顯著
推 rattrapante: free lossless audio codec
→ rattrapante: 我以為這是常識，就算不知道也可以估狗
推 penguinfuko: 說什麼 flac 是有損的…… 自己去 hash 轉檔好不
推 elguapo: 我個人不會去挑戰 FLAC 的壓縮解壓縮的理論，但還是要
→ elguapo: 提一下，即便是 ZIP 也都還有 CRC error 而導致無法正
→ elguapo: 確解壓縮；FLAC 官方自己也說了 FLAC 也會有 CRC error
→ elguapo:  問題，只是他們認為只不過幾秒鐘可以無視，這個說是 10
→ elguapo: 0% 保證完全無損我就會打問號了。“Because of FLAC's f
→ elguapo: raming, stream errors limit the damage to the frame
→ elguapo: in which the error occurred, typically a small fract
→ elguapo: ion of a second worth of data.”
→ elguapo: 要使用 FLAC 作為串流格式 CRC 就會存在。
你的觀念錯誤

有CRC error代表的是會還原失敗
那就是代表這個flac檔是毀損的

但如果能還原成功就是正確的資料
你不要一直把不同的事情混在一起講

然後說雖然是無損  但是我相信他有損這種謬論
※ 編輯: kblover (60.251.61.121 臺灣), 01/20/2021 16:58:53
推 elguapo: FLAC之所以可以拿來串流，係格式特色是
→ elguapo: 類同MPEG可以在任何一點開始播放，串流如果有封包被丟掉
→ elguapo: ，播放程式可以找最近的下一個正確的資料繼續播放。我想
→ elguapo: 指出的是，串流時這段被丟掉的封包如果有重傳恢復該有的
→ elguapo: 內容，那麼就是100%還原沒話說，但事實上接受端是選擇跳
→ elguapo: 到下一個正確的資料再開始播放。
→ elguapo: 或許您會認為我觀念有誤拿張飛打岳飛強詞奪理，但我只問
→ elguapo: ，這樣串流到播放端即使只掉了0.1%個封包，還能說是完全
→ elguapo: 無損嗎？檔案傳輸的損壞也是損壞啊，我們只專注壓縮解壓
→ elguapo: 縮的無損，缺很少挑戰傳輸是否無損（還是丟掉的封包在客
→ elguapo: 戶端有黑科技可以補回？）
→ elguapo: Local檔案無損我不會存疑（感謝教導指正我也去再看了幾
→ elguapo: 次相關編碼和運用），但對於串流過程播放器也不會告訴你
→ elguapo: 有沒有封包不見直接跳下一個正確的資料，除非是檔案archi
→ elguapo: ve下載這樣的FLAC才是真正無損吧。
你要搞清楚掉封包跟轉換的資料錯誤是不同一件事情

你講的CASE跟FLAC是不是無損  是不同的議題

你要搞清楚你懷疑的事情跟FLAC的關聯性是什麼

而不是一直拿其他部分的error來跳針說這樣FLAC還算不算有損這種問題
※ 編輯: kblover (60.251.61.121 臺灣), 01/20/2021 17:54:47
推 elguapo: FLAC 規範是可串流的格式，那麼傳輸 error 的修正也會
→ elguapo: 被檢視啊？怎麼會是兩回事呢？
→ Oswyn: 串流的網路傳輸有沒有出錯跟檔案有無損是兩碼子事
→ Oswyn: 要是同件事，這世上就沒有所喟的"無損"串流了
推 greg7575: 看吧，就是這樣
→ greg7575: 講a跟你b
→ greg7575: 一直腦補一直腦補一直腦補
推 lovez04wj06: 檔案無損跟傳輸後有損混為一談，是不是太可笑？
推 greg7575: 越看越好笑，這種還會有人護航。噗滋
推 greg7575: 大師連"無損"這兩個字的定義都有獨特的見解
→ greg7575: 看著看著，彷彿我變成了白痴。欣喜啊
→ greg7575: 大師的buffer想必也與凡人不同
推 greg7575: 串流還想重傳什麼？噗哇哈哈今年最好笑
→ elguapo: 反正都被笑成這樣，我就臉皮再厚一點。請樓上為我解釋 F
→ elguapo: LAC 的 frame 結構為何，如果 frame CRC 錯誤會怎麼處
→ elguapo: 理。再説一次，這是 FLAC 的「檔案結構」，我也不跟你
→ elguapo: 扯傳輸了，就「檔案結構」而已。A 和 B 我分得很清楚。
推 rattrapante: 說個笑話 flac有損
→ rattrapante: 自己先在那邊跳針串流掉包
→ rattrapante: 還要另闢戰場喔  是有沒有那麼辛苦
→ elguapo: 我知道我臉腫，也承認我錯，FLAC 在壓縮解壓縮是無損，
→ elguapo: 而且前面推文我也再三強調這件事，您要繼續這樣笑我，
→ elguapo: 我也只能坦然接受，讓自己永遠記得 FLAC 是無損，這件
→ elguapo: 事就當大家的閒嗑牙可以笑的事，我 ok，錯就要有勇氣承
→ elguapo: 認和承擔被笑被酸。但是我不解的是，當我知道我的不足
→ elguapo: 去真的好好的看了幾遍 FLAC 的規範文件，發現串流應用
→ elguapo: 上仍是有信號損失的可能，再拿出來請教這樣也有錯？就
→ elguapo: 像前面某人說我是 A B 分不清，但我認為 A 已經結案也
→ elguapo: 承認我的認知有錯，現在是真正讀了技術文件後的新問題
→ elguapo: ，如果有人也能告訴我 FLAC 在串流時能 100% 還原的理
→ elguapo: 論在哪裡我會自己去看，有錯也會自己掌嘴。
你自己都回答你自己的問題了

flac檔案就是無損

串流的時候丟封包是介面的事情

跟flac一點關聯都沒有

推 rattrapante: 哇塞  大師真的與眾不同
推 elguapo: 好吧 kb 大既然還是這麼認為我就此打住，no more questio
→ elguapo: n at all。期待您哪天能理解我的問題再闢新樓討論好了。
我早就理解你的問題了

然後我可以直接告訴你  你問的問題根本不是問題
是你對檔案跟傳輸的觀念沒有釐清

你從頭到尾都在你自己的錯誤邏輯打轉  所以沒什麼好回的...

推 rugger5566: 串流不是收音機，都會有buffer的，不然為何tidal播放
→ rugger5566: 檔案前都會有點延遲但開始播就不會有呢？
※ 編輯: kblover (111.240.126.80 臺灣), 01/20/2021 22:38:37
→ llw116: 串流漏封包就不是無損的話，那就沒有無損的串流了。
推 piyopiyolee: 每次回來看這串都很開心
推 to19880428: https://www.youtube.com/watch?v=qfXMkt67mqM
→ greg7575: bro u make my day
推 e04su307: 整串看下來，最簡單的理解就是，串流封包的遺失是介面
→ e04su307: 、網路的鍋，你不能因為這個原因直接認為串流FLAC不是
→ e04su307: 無損格式，而去質疑FLAC的檔案格式，反而應該專注在網
→ e04su307: 路傳輸介面的穩定性上討論