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

看板Headphone (耳機)作者 (聖貓天使)時間3年前 (2021/01/18 16:48), 3年前編輯推噓47(470105)
留言152則, 21人參與, 3年前最新討論串6/6 (看更多)
看到這篇文章很用心 但我看到一些點覺得有些似是而非 基本上不是做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

01/18 17:04, 3年前 , 1F
elguapo網友對apple/aac的解釋是很ok的,挑啥AAC不是CODEC
01/18 17:04, 1F

01/18 17:05, 3年前 , 2F
這種語病,就有點無聊。 最後推文中對FLAC的評論倒是頗有爭
01/18 17:05, 2F

01/18 17:05, 3年前 , 3F
議。我也查了資料,FLAC壓縮是在數學上被認定的,所以要打
01/18 17:05, 3F

01/18 17:05, 3年前 , 4F
破是極難。因此,那篇論文,可能要細究一下他的量測法。我
01/18 17:05, 4F

01/18 17:06, 3年前 , 5F
GOOGLE到一篇FLAC的驗證文章,就是講到其量測點的問題。
01/18 17:06, 5F
AAC應該是一種編碼格式 你是透過codec去decode成PCM,或是透過codec把PCM encode成AAC 直接說他是codec會有點奇怪而已~

01/18 17:18, 3年前 , 6F
喜歡這種抓出白痴的文
01/18 17:18, 6F

01/18 17:39, 3年前 , 7F
你說的也是,壓縮了就是壓縮了,而且還是有損壓縮,怎
01/18 17:39, 7F

01/18 17:39, 3年前 , 8F
麼都很難救回來
01/18 17:39, 8F

01/18 18:20, 3年前 , 9F
其實我反而比較希望在耳機板看到DSD vs PCM 大戰
01/18 18:20, 9F

01/18 18:22, 3年前 , 10F
這個就有很多paper了,IEEE就有幾篇了
01/18 18:22, 10F

01/18 18:22, 3年前 , 11F
但目前的共識是:各有優缺 這樣
01/18 18:22, 11F

01/18 18:22, 3年前 , 12F
抱歉歪樓了 拉回來一下
01/18 18:22, 12F

01/18 18:25, 3年前 , 13F
幾個無損音樂格式的差異是常看到的話題沒錯,不過我覺得差異
01/18 18:25, 13F

01/18 18:25, 3年前 , 14F
遠比蘋果所謂特調又加持的AAC檔案來的小
01/18 18:25, 14F

01/18 18:59, 3年前 , 15F
因為壓了就是壓了,讓人感覺差不多是用心調整,也是一種
01/18 18:59, 15F

01/18 18:59, 3年前 , 16F
做法
01/18 18:59, 16F

01/18 19:44, 3年前 , 17F
所謂的有損壓縮就是指無法還原
01/18 19:44, 17F

01/18 19:45, 3年前 , 18F
再怎麼神通廣大都只是模擬
01/18 19:45, 18F

01/18 19:45, 3年前 , 19F
當然聽起來如何又是一回事
01/18 19:45, 19F

01/18 20:10, 3年前 , 20F
Core Audio 不支援 FLAC 合先敘明。FLAC 理論的壓縮還
01/18 20:10, 20F

01/18 20:10, 3年前 , 21F
原如您所說的驗證堅若磐石,但 Mac 或 iPhone 使用 FLAC
01/18 20:10, 21F

01/18 20:10, 3年前 , 22F
是需要轉一手的,那麼這一手會產生多少影響可能還要再
01/18 20:10, 22F

01/18 20:10, 3年前 , 23F
研究,第三方怎麼解釋 FLAC 怎麼放入 Core Audio 我也
01/18 20:10, 23F

01/18 20:10, 3年前 , 24F
很好奇是否如 FLAC 宣告般完整,故我個人在 Mac 應用上
01/18 20:10, 24F

01/18 20:10, 3年前 , 25F
是走向保守認為是或許有損的。
01/18 20:10, 25F
這倒是不用懷疑 他在PCM data的部分就是完全無損 如果不是早就被踢爆了 沒有什麼在mac上面就會走向有損這種事情 FLAC解壓縮後 他就是有一塊可以直接丟給codec轉換的PCM buffer 當然這塊pcm buffer也能在壓縮成AAC餵給後端的airpods之類的 但沒有什麼保守不保守 蘋果沒有這麼偉大

01/18 20:13, 3年前 , 26F
另外,蘋果的確稱 AAC 為「codec」https://imgur.com/CM
01/18 20:13, 26F

01/18 20:13, 3年前 , 27F
2Az6n相關文件都在 Developer 網頁能找到。
01/18 20:13, 27F

01/18 20:14, 3年前 , 28F
對不起推文 URL 跑掉
01/18 20:14, 28F

01/18 20:14, 3年前 , 29F

01/18 20:18, 3年前 , 30F
kb大您是對的。AAC是data type並非codec。
01/18 20:18, 30F

01/18 20:19, 3年前 , 31F
對不起我才疏學淺 Orz
01/18 20:19, 31F
XD 沒事沒事

01/18 20:30, 3年前 , 32F
另外... @greg7575 請您去查閱我寫的東西跟蘋果相關文
01/18 20:30, 32F

01/18 20:30, 3年前 , 33F
件寫不一樣的地方,找出來批評指教我會很高興接受,但
01/18 20:30, 33F

01/18 20:30, 3年前 , 34F
如果您的留言是針對我罵我白痴的話,我也只能請版主處
01/18 20:30, 34F

01/18 20:30, 3年前 , 35F
理了。
01/18 20:30, 35F
https://tinyurl.com/yagn9mrm 他應該是說你貼的這篇研究是白癡文吧 冷靜冷靜
還有 80 則推文
還有 6 段內文
01/20 19:35, 3年前 , 116F
要是同件事,這世上就沒有所喟的"無損"串流了
01/20 19:35, 116F

01/20 20:21, 3年前 , 117F
看吧,就是這樣
01/20 20:21, 117F

01/20 20:21, 3年前 , 118F
講a跟你b
01/20 20:21, 118F

01/20 20:21, 3年前 , 119F
一直腦補一直腦補一直腦補
01/20 20:21, 119F

01/20 20:22, 3年前 , 120F
檔案無損跟傳輸後有損混為一談,是不是太可笑?
01/20 20:22, 120F

01/20 20:27, 3年前 , 121F
越看越好笑,這種還會有人護航。噗滋
01/20 20:27, 121F

01/20 20:33, 3年前 , 122F
大師連"無損"這兩個字的定義都有獨特的見解
01/20 20:33, 122F

01/20 20:34, 3年前 , 123F
看著看著,彷彿我變成了白痴。欣喜啊
01/20 20:34, 123F

01/20 20:35, 3年前 , 124F
大師的buffer想必也與凡人不同
01/20 20:35, 124F

01/20 20:39, 3年前 , 125F
串流還想重傳什麼?噗哇哈哈今年最好笑
01/20 20:39, 125F

01/20 20:52, 3年前 , 126F
反正都被笑成這樣,我就臉皮再厚一點。請樓上為我解釋 F
01/20 20:52, 126F

01/20 20:52, 3年前 , 127F
LAC 的 frame 結構為何,如果 frame CRC 錯誤會怎麼處
01/20 20:52, 127F

01/20 20:52, 3年前 , 128F
理。再説一次,這是 FLAC 的「檔案結構」,我也不跟你
01/20 20:52, 128F

01/20 20:52, 3年前 , 129F
扯傳輸了,就「檔案結構」而已。A 和 B 我分得很清楚。
01/20 20:52, 129F

01/20 21:07, 3年前 , 130F
說個笑話 flac有損
01/20 21:07, 130F

01/20 21:08, 3年前 , 131F
自己先在那邊跳針串流掉包
01/20 21:08, 131F

01/20 21:08, 3年前 , 132F
還要另闢戰場喔 是有沒有那麼辛苦
01/20 21:08, 132F

01/20 21:34, 3年前 , 133F
我知道我臉腫,也承認我錯,FLAC 在壓縮解壓縮是無損,
01/20 21:34, 133F

01/20 21:34, 3年前 , 134F
而且前面推文我也再三強調這件事,您要繼續這樣笑我,
01/20 21:34, 134F

01/20 21:34, 3年前 , 135F
我也只能坦然接受,讓自己永遠記得 FLAC 是無損,這件
01/20 21:34, 135F

01/20 21:34, 3年前 , 136F
事就當大家的閒嗑牙可以笑的事,我 ok,錯就要有勇氣承
01/20 21:34, 136F

01/20 21:34, 3年前 , 137F
認和承擔被笑被酸。但是我不解的是,當我知道我的不足
01/20 21:34, 137F

01/20 21:34, 3年前 , 138F
去真的好好的看了幾遍 FLAC 的規範文件,發現串流應用
01/20 21:34, 138F

01/20 21:35, 3年前 , 139F
上仍是有信號損失的可能,再拿出來請教這樣也有錯?就
01/20 21:35, 139F

01/20 21:35, 3年前 , 140F
像前面某人說我是 A B 分不清,但我認為 A 已經結案也
01/20 21:35, 140F

01/20 21:35, 3年前 , 141F
承認我的認知有錯,現在是真正讀了技術文件後的新問題
01/20 21:35, 141F

01/20 21:35, 3年前 , 142F
,如果有人也能告訴我 FLAC 在串流時能 100% 還原的理
01/20 21:35, 142F

01/20 21:35, 3年前 , 143F
論在哪裡我會自己去看,有錯也會自己掌嘴。
01/20 21:35, 143F
你自己都回答你自己的問題了 flac檔案就是無損 串流的時候丟封包是介面的事情 跟flac一點關聯都沒有

01/20 22:11, 3年前 , 144F
哇塞 大師真的與眾不同
01/20 22:11, 144F

01/20 22:13, 3年前 , 145F
好吧 kb 大既然還是這麼認為我就此打住,no more questio
01/20 22:13, 145F

01/20 22:13, 3年前 , 146F
n at all。期待您哪天能理解我的問題再闢新樓討論好了。
01/20 22:13, 146F
我早就理解你的問題了 然後我可以直接告訴你 你問的問題根本不是問題 是你對檔案跟傳輸的觀念沒有釐清 你從頭到尾都在你自己的錯誤邏輯打轉 所以沒什麼好回的...

01/20 22:30, 3年前 , 147F
串流不是收音機,都會有buffer的,不然為何tidal播放
01/20 22:30, 147F

01/20 22:30, 3年前 , 148F
檔案前都會有點延遲但開始播就不會有呢?
01/20 22:30, 148F
※ 編輯: kblover (111.240.126.80 臺灣), 01/20/2021 22:38:37

01/21 00:37, 3年前 , 149F
串流漏封包就不是無損的話,那就沒有無損的串流了。
01/21 00:37, 149F

01/21 02:05, 3年前 , 150F
每次回來看這串都很開心
01/21 02:05, 150F

01/21 08:21, 3年前 , 151F

01/21 09:49, 3年前 , 152F
bro u make my day
01/21 09:49, 152F
文章代碼(AID): #1W1Kjmxw (Headphone)
文章代碼(AID): #1W1Kjmxw (Headphone)