看到這篇文章很用心 但我看到一些點覺得有些似是而非
基本上不是做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

elguapo網友對apple/aac的解釋是很ok的，挑啥AAC不是CODEC這種語病，就有點無聊。 最後推文中對FLAC的評論倒是頗有爭議。我也查了資料，FLAC壓縮是在數學上被認定的，所以要打破是極難。因此，那篇論文，可能要細究一下他的量測法。我GOOGLE到一篇FLAC的驗證文章，就是講到其量測點的問題。

喜歡這種抓出白痴的文

你說的也是，壓縮了就是壓縮了，而且還是有損壓縮，怎麼都很難救回來

其實我反而比較希望在耳機板看到DSD vs PCM 大戰這個就有很多paper了，IEEE就有幾篇了但目前的共識是：各有優缺 這樣抱歉歪樓了 拉回來一下

幾個無損音樂格式的差異是常看到的話題沒錯，不過我覺得差異遠比蘋果所謂特調又加持的AAC檔案來的小

因為壓了就是壓了，讓人感覺差不多是用心調整，也是一種做法

所謂的有損壓縮就是指無法還原再怎麼神通廣大都只是模擬當然聽起來如何又是一回事

Core Audio 不支援 FLAC 合先敘明。FLAC 理論的壓縮還原如您所說的驗證堅若磐石，但 Mac 或 iPhone 使用 FLAC是需要轉一手的，那麼這一手會產生多少影響可能還要再研究，第三方怎麼解釋 FLAC 怎麼放入 Core Audio 我也很好奇是否如 FLAC 宣告般完整，故我個人在 Mac 應用上是走向保守認為是或許有損的。另外，蘋果的確稱 AAC 為「codec」https://imgur.com/CM2Az6n相關文件都在 Developer 網頁能找到。對不起推文 URL 跑掉https://imgur.com/CM2Az6n.jpgkb大您是對的。AAC是data type並非codec。對不起我才疏學淺 Orz另外... @greg7575 請您去查閱我寫的東西跟蘋果相關文件寫不一樣的地方，找出來批評指教我會很高興接受，但如果您的留言是針對我罵我白痴的話，我也只能請版主處理了。

很有興趣H1到底有否Core Audio架構在裡面？就靠大家解密

大家火氣小一點啊QQ

幹嘛要另外弄個晶片再處理一次Core Audio我覺得有些人根本就是邏輯問題每個藍芽耳機因為要解碼都有晶片 只是Apple取個酷炫潮的名字吸引人掏錢買而已

https://tinyurl.com/yykmwl4xifixit 有 Max 的拆解圖，也有推估那張晶片在做什麼事。基本上 H1 是 SoC，解碼轉 PCM 不是大問題。

恩 還有降噪也要用那顆H1跟一些感應器之類的 基本上每間產品都有類似的東西 功用多跟少的問題

用2顆的好處是？降噪嗎？

果粉講成甚麼萬能的科技就不必了Airpods 也有兩顆 可能設計就是要兩顆分開處理(?)畢竟這晶片用了好幾款了 如果沒大改設計大概大同小異

可以參照一下Dolby Dimension那顆Snapdragon做了什麼或許可以了解跟一般無線藍芽降噪耳機晶片功能有何差別

oh my god........死灰復燃

不妨由r大整理回文讓大家知道差異跟基準點呢？不然回覆都是可能、有機會、或許可以，造福版友也不錯

果粉都喜歡叫人study 嘻嘻

@elguapo 抱歉喔，我不是說你白痴。如果你覺得自己被形容成白痴，那是你的感覺而非我本意如果你覺得我的推文讓你變成白痴，那我未免也太強大了我指的是過份腦補的人，跟白痴一樣。果粉每個都大師，這樣子你會不會生氣？蘋果沒有說的東西，果粉自己腦補說有還要求別人要絕對認同他的腦補。還要別人拿出證據這種討論的方式真的是齁，越講越累啦沒有獨角獸，果粉要求別人拿出沒有獨角獸的證明否則就是有獨角獸。這裡有馬，這裡有角，摻一起就有了

搞惡魔的證明真的是論述之恥

還有一種人叫槓精，人家在講a他要扯b把b講得頭頭是道，然後他的a就一定是對的指出他的a錯，他就說可是我b沒錯小心邏輯殺手：槓精

我不覺得elguapo的回文有啥問題，尤其他又自己做實驗，還找了PAPER來證明自己的觀點。倒是greg7575，除了講人白痴、酸人與無營養的推文，才是真的讓人看不下去。

腦補文的營養價值可能比較高

我封面圖片都放阿爾卑斯山雪山，聽起來會有一種空靈感

垃圾食物比較可怕(？

嘻嘻djboy 你超強的分析精準，邏輯通暢。小失誤也不影響大局

我封面都要放4k解析的圖片這樣音樂的線條感還有分離度才會好聽大編制音樂效果尤其顯著free lossless audio codec我以為這是常識，就算不知道也可以估狗

說什麼 flac 是有損的…… 自己去 hash 轉檔好不

我個人不會去挑戰 FLAC 的壓縮解壓縮的理論，但還是要提一下，即便是 ZIP 也都還有 CRC error 而導致無法正確解壓縮；FLAC 官方自己也說了 FLAC 也會有 CRC error問題，只是他們認為只不過幾秒鐘可以無視，這個說是 100% 保證完全無損我就會打問號了。“Because of FLAC's framing, stream errors limit the damage to the framein which the error occurred, typically a small fraction of a second worth of data.”要使用 FLAC 作為串流格式 CRC 就會存在。FLAC之所以可以拿來串流，係格式特色是類同MPEG可以在任何一點開始播放，串流如果有封包被丟掉，播放程式可以找最近的下一個正確的資料繼續播放。我想指出的是，串流時這段被丟掉的封包如果有重傳恢復該有的內容，那麼就是100%還原沒話說，但事實上接受端是選擇跳到下一個正確的資料再開始播放。或許您會認為我觀念有誤拿張飛打岳飛強詞奪理，但我只問，這樣串流到播放端即使只掉了0.1%個封包，還能說是完全無損嗎？檔案傳輸的損壞也是損壞啊，我們只專注壓縮解壓縮的無損，缺很少挑戰傳輸是否無損（還是丟掉的封包在客戶端有黑科技可以補回？）Local檔案無損我不會存疑（感謝教導指正我也去再看了幾次相關編碼和運用），但對於串流過程播放器也不會告訴你有沒有封包不見直接跳下一個正確的資料，除非是檔案archive下載這樣的FLAC才是真正無損吧。

串流的網路傳輸有沒有出錯跟檔案有無損是兩碼子事要是同件事，這世上就沒有所喟的"無損"串流了

看吧，就是這樣講a跟你b一直腦補一直腦補一直腦補

檔案無損跟傳輸後有損混為一談，是不是太可笑？

越看越好笑，這種還會有人護航。噗滋大師連"無損"這兩個字的定義都有獨特的見解看著看著，彷彿我變成了白痴。欣喜啊大師的buffer想必也與凡人不同串流還想重傳什麼？噗哇哈哈今年最好笑

反正都被笑成這樣，我就臉皮再厚一點。請樓上為我解釋 FLAC 的 frame 結構為何，如果 frame CRC 錯誤會怎麼處理。再説一次，這是 FLAC 的「檔案結構」，我也不跟你扯傳輸了，就「檔案結構」而已。A 和 B 我分得很清楚。

說個笑話 flac有損自己先在那邊跳針串流掉包還要另闢戰場喔 是有沒有那麼辛苦

我知道我臉腫，也承認我錯，FLAC 在壓縮解壓縮是無損，而且前面推文我也再三強調這件事，您要繼續這樣笑我，我也只能坦然接受，讓自己永遠記得 FLAC 是無損，這件事就當大家的閒嗑牙可以笑的事，我 ok，錯就要有勇氣承認和承擔被笑被酸。但是我不解的是，當我知道我的不足去真的好好的看了幾遍 FLAC 的規範文件，發現串流應用上仍是有信號損失的可能，再拿出來請教這樣也有錯？就像前面某人說我是 A B 分不清，但我認為 A 已經結案也承認我的認知有錯，現在是真正讀了技術文件後的新問題，如果有人也能告訴我 FLAC 在串流時能 100% 還原的理論在哪裡我會自己去看，有錯也會自己掌嘴。

哇塞 大師真的與眾不同

好吧 kb 大既然還是這麼認為我就此打住，no more question at all。期待您哪天能理解我的問題再闢新樓討論好了。

串流不是收音機，都會有buffer的，不然為何tidal播放檔案前都會有點延遲但開始播就不會有呢？

串流漏封包就不是無損的話，那就沒有無損的串流了。

每次回來看這串都很開心

bro u make my day

整串看下來，最簡單的理解就是，串流封包的遺失是介面、網路的鍋，你不能因為這個原因直接認為串流FLAC不是無損格式，而去質疑FLAC的檔案格式，反而應該專注在網路傳輸介面的穩定性上討論