推 djboy: elguapo網友對apple/aac的解釋是很ok的,挑啥AAC不是CODEC 01/18 17:04
→ djboy: 這種語病,就有點無聊。 最後推文中對FLAC的評論倒是頗有爭 01/18 17:05
→ djboy: 議。我也查了資料,FLAC壓縮是在數學上被認定的,所以要打 01/18 17:05
→ djboy: 破是極難。因此,那篇論文,可能要細究一下他的量測法。我 01/18 17:05
→ djboy: GOOGLE到一篇FLAC的驗證文章,就是講到其量測點的問題。 01/18 17:06
AAC應該是一種編碼格式
你是透過codec去decode成PCM,或是透過codec把PCM encode成AAC
直接說他是codec會有點奇怪而已~
推 greg7575: 喜歡這種抓出白痴的文 01/18 17:18
推 rugger5566: 你說的也是,壓縮了就是壓縮了,而且還是有損壓縮,怎 01/18 17:39
→ rugger5566: 麼都很難救回來 01/18 17:39
推 dzwei: 其實我反而比較希望在耳機板看到DSD vs PCM 大戰 01/18 18:20
→ dzwei: 這個就有很多paper了,IEEE就有幾篇了 01/18 18:22
→ dzwei: 但目前的共識是:各有優缺 這樣 01/18 18:22
→ dzwei: 抱歉歪樓了 拉回來一下 01/18 18:22
推 xoy: 幾個無損音樂格式的差異是常看到的話題沒錯,不過我覺得差異 01/18 18:25
→ xoy: 遠比蘋果所謂特調又加持的AAC檔案來的小 01/18 18:25
推 hsinggg: 因為壓了就是壓了,讓人感覺差不多是用心調整,也是一種 01/18 18:59
→ hsinggg: 做法 01/18 18:59
推 Dustdusk: 所謂的有損壓縮就是指無法還原 01/18 19:44
→ Dustdusk: 再怎麼神通廣大都只是模擬 01/18 19:45
→ Dustdusk: 當然聽起來如何又是一回事 01/18 19:45
推 elguapo: Core Audio 不支援 FLAC 合先敘明。FLAC 理論的壓縮還 01/18 20:10
→ elguapo: 原如您所說的驗證堅若磐石,但 Mac 或 iPhone 使用 FLAC 01/18 20:10
→ elguapo: 是需要轉一手的,那麼這一手會產生多少影響可能還要再 01/18 20:10
→ elguapo: 研究,第三方怎麼解釋 FLAC 怎麼放入 Core Audio 我也 01/18 20:10
→ elguapo: 很好奇是否如 FLAC 宣告般完整,故我個人在 Mac 應用上 01/18 20:10
→ elguapo: 是走向保守認為是或許有損的。 01/18 20:10
這倒是不用懷疑
他在PCM data的部分就是完全無損
如果不是早就被踢爆了
沒有什麼在mac上面就會走向有損這種事情
FLAC解壓縮後 他就是有一塊可以直接丟給codec轉換的PCM buffer
當然這塊pcm buffer也能在壓縮成AAC餵給後端的airpods之類的
但沒有什麼保守不保守 蘋果沒有這麼偉大
→ elguapo: 2Az6n相關文件都在 Developer 網頁能找到。 01/18 20:13
→ elguapo: 對不起推文 URL 跑掉 01/18 20:14
推 elguapo: kb大您是對的。AAC是data type並非codec。 01/18 20:18
→ elguapo: 對不起我才疏學淺 Orz 01/18 20:19
XD 沒事沒事
推 elguapo: 另外... @greg7575 請您去查閱我寫的東西跟蘋果相關文 01/18 20:30
→ elguapo: 件寫不一樣的地方,找出來批評指教我會很高興接受,但 01/18 20:30
→ elguapo: 如果您的留言是針對我罵我白痴的話,我也只能請版主處 01/18 20:30
→ elguapo: 理了。 01/18 20:30
https://tinyurl.com/yagn9mrm
他應該是說你貼的這篇研究是白癡文吧 冷靜冷靜
推 rickylin: 很有興趣H1到底有否Core Audio架構在裡面?就靠大家解密 01/18 20:34
這沒什麼好研究的
應該是根本不需要....
→ rugger5566: 大家火氣小一點啊QQ 01/18 20:38
推 WiLLSTW: 幹嘛要另外弄個晶片再處理一次Core Audio 01/18 20:42
→ WiLLSTW: 我覺得有些人根本就是邏輯問題 01/18 20:43
→ WiLLSTW: 每個藍芽耳機因為要解碼都有晶片 只是Apple取個酷炫潮的 01/18 20:44
→ WiLLSTW: 名字吸引人掏錢買而已 01/18 20:44
到也不是 要能做那些空間音效,或是套EQ
H1這顆DSP應該是功能滿強大的沒錯~
※ 編輯: kblover (111.240.116.58 臺灣), 01/18/2021 20:46:54
→ elguapo: ifixit 有 Max 的拆解圖,也有推估那張晶片在做什麼事 01/18 20:53
→ elguapo: 。基本上 H1 是 SoC,解碼轉 PCM 不是大問題。 01/18 20:53
推 WiLLSTW: 恩 還有降噪也要用那顆H1跟一些感應器之類的 基本上每間 01/18 20:53
→ WiLLSTW: 產品都有類似的東西 功用多跟少的問題 01/18 20:54
推 rugger5566: 用2顆的好處是?降噪嗎? 01/18 20:55
→ WiLLSTW: 果粉講成甚麼萬能的科技就不必了 01/18 20:55
→ WiLLSTW: Airpods 也有兩顆 可能設計就是要兩顆分開處理(?) 01/18 20:56
推 WiLLSTW: 畢竟這晶片用了好幾款了 如果沒大改設計大概大同小異 01/18 20:59
推 rickylin: 可以參照一下Dolby Dimension那顆Snapdragon做了什麼 01/18 21:15
→ rickylin: 或許可以了解跟一般無線藍芽降噪耳機晶片功能有何差別 01/18 21:17
→ bben900911: oh my god........死灰復燃 01/18 22:00
推 good151617: 不妨由r大整理回文讓大家知道差異跟基準點呢? 01/19 00:10
推 good151617: 不然回覆都是可能、有機會、或許可以,造福版友也不 01/19 00:12
→ good151617: 錯 01/19 00:12
推 rattrapante: 果粉都喜歡叫人study 嘻嘻 01/19 02:20
推 greg7575: @elguapo 抱歉喔,我不是說你白痴。 01/19 09:12
→ greg7575: 如果你覺得自己被形容成白痴,那是你的感覺而非我本意 01/19 09:12
→ greg7575: 如果你覺得我的推文讓你變成白痴,那我未免也太強大了 01/19 09:13
→ greg7575: 我指的是過份腦補的人,跟白痴一樣。 01/19 09:14
推 greg7575: 果粉每個都大師,這樣子你會不會生氣? 01/19 09:16
推 greg7575: 蘋果沒有說的東西,果粉自己腦補說有 01/19 09:18
→ greg7575: 還要求別人要絕對認同他的腦補。還要別人拿出證據 01/19 09:18
→ greg7575: 這種討論的方式真的是齁,越講越累啦 01/19 09:18
→ greg7575: 沒有獨角獸,果粉要求別人拿出沒有獨角獸的證明 01/19 09:20
→ greg7575: 否則就是有獨角獸。這裡有馬,這裡有角,摻一起就有了 01/19 09:20
推 lovez04wj06: 搞惡魔的證明真的是論述之恥 01/19 09:27
推 greg7575: 還有一種人叫槓精,人家在講a他要扯b 01/19 10:00
→ greg7575: 把b講得頭頭是道,然後他的a就一定是對的 01/19 10:00
→ greg7575: 指出他的a錯,他就說可是我b沒錯 01/19 10:01
→ greg7575: 小心邏輯殺手:槓精 01/19 10:01
推 djboy: 我不覺得elguapo的回文有啥問題,尤其他又自己做實驗,還 01/19 10:29
→ djboy: 找了PAPER來證明自己的觀點。 01/19 10:29
→ djboy: 倒是greg7575,除了講人白痴、酸人與無營養的推文,才是 01/19 10:30
→ djboy: 真的讓人看不下去。 01/19 10:30
那篇後來多看了一下只是一家音響雜誌自己亂寫的文
那種東西稱為論文真的是污辱了論文這兩字
推 lovez04wj06: 腦補文的營養價值可能比較高 01/19 10:57
推 rgbff: 我封面圖片都放阿爾卑斯山雪山,聽起來會有一種空靈感 01/19 11:02
我都不放 聽起來有飄渺虛無感
※ 編輯: kblover (122.147.213.24 臺灣), 01/19/2021 11:04:15
→ m9172250: 垃圾食物比較可怕(? 01/19 11:25
推 greg7575: 嘻嘻 01/19 11:46
→ greg7575: djboy 你超強的 01/19 11:47
推 greg7575: 分析精準,邏輯通暢。小失誤也不影響大局 01/19 11:51
推 rattrapante: 我封面都要放4k解析的圖片 01/19 13:58
→ rattrapante: 這樣音樂的線條感還有分離度才會好 01/19 13:58
→ rattrapante: 聽大編制音樂效果尤其顯著 01/19 13:58
推 rattrapante: free lossless audio codec 01/19 14:15
→ rattrapante: 我以為這是常識,就算不知道也可以估狗 01/19 14:15
推 penguinfuko: 說什麼 flac 是有損的…… 自己去 hash 轉檔好不 01/20 10:52
推 elguapo: 我個人不會去挑戰 FLAC 的壓縮解壓縮的理論,但還是要 01/20 14:14
→ elguapo: 提一下,即便是 ZIP 也都還有 CRC error 而導致無法正 01/20 14:14
→ elguapo: 確解壓縮;FLAC 官方自己也說了 FLAC 也會有 CRC error 01/20 14:14
→ elguapo: 問題,只是他們認為只不過幾秒鐘可以無視,這個說是 10 01/20 14:14
→ elguapo: 0% 保證完全無損我就會打問號了。“Because of FLAC's f 01/20 14:14
→ elguapo: raming, stream errors limit the damage to the frame 01/20 14:14
→ elguapo: in which the error occurred, typically a small fract 01/20 14:14
→ elguapo: ion of a second worth of data.” 01/20 14:14
→ elguapo: 要使用 FLAC 作為串流格式 CRC 就會存在。 01/20 14:16
你的觀念錯誤
有CRC error代表的是會還原失敗
那就是代表這個flac檔是毀損的
但如果能還原成功就是正確的資料
你不要一直把不同的事情混在一起講
然後說雖然是無損 但是我相信他有損這種謬論
※ 編輯: kblover (60.251.61.121 臺灣), 01/20/2021 16:58:53
推 elguapo: FLAC之所以可以拿來串流,係格式特色是 01/20 17:49
→ elguapo: 類同MPEG可以在任何一點開始播放,串流如果有封包被丟掉 01/20 17:49
→ elguapo: ,播放程式可以找最近的下一個正確的資料繼續播放。我想 01/20 17:49
→ elguapo: 指出的是,串流時這段被丟掉的封包如果有重傳恢復該有的 01/20 17:49
→ elguapo: 內容,那麼就是100%還原沒話說,但事實上接受端是選擇跳 01/20 17:49
→ elguapo: 到下一個正確的資料再開始播放。 01/20 17:49
→ elguapo: 或許您會認為我觀念有誤拿張飛打岳飛強詞奪理,但我只問 01/20 17:49
→ elguapo: ,這樣串流到播放端即使只掉了0.1%個封包,還能說是完全 01/20 17:49
→ elguapo: 無損嗎?檔案傳輸的損壞也是損壞啊,我們只專注壓縮解壓 01/20 17:49
→ elguapo: 縮的無損,缺很少挑戰傳輸是否無損(還是丟掉的封包在客 01/20 17:49
→ elguapo: 戶端有黑科技可以補回?) 01/20 17:49
→ elguapo: Local檔案無損我不會存疑(感謝教導指正我也去再看了幾 01/20 17:49
→ elguapo: 次相關編碼和運用),但對於串流過程播放器也不會告訴你 01/20 17:49
→ elguapo: 有沒有封包不見直接跳下一個正確的資料,除非是檔案archi 01/20 17:49
→ elguapo: ve下載這樣的FLAC才是真正無損吧。 01/20 17:49
你要搞清楚掉封包跟轉換的資料錯誤是不同一件事情
你講的CASE跟FLAC是不是無損 是不同的議題
你要搞清楚你懷疑的事情跟FLAC的關聯性是什麼
而不是一直拿其他部分的error來跳針說這樣FLAC還算不算有損這種問題
※ 編輯: kblover (60.251.61.121 臺灣), 01/20/2021 17:54:47
推 elguapo: FLAC 規範是可串流的格式,那麼傳輸 error 的修正也會 01/20 18:55
→ elguapo: 被檢視啊?怎麼會是兩回事呢? 01/20 18:55
→ Oswyn: 串流的網路傳輸有沒有出錯跟檔案有無損是兩碼子事 01/20 19:34
→ Oswyn: 要是同件事,這世上就沒有所喟的"無損"串流了 01/20 19:35
推 greg7575: 看吧,就是這樣 01/20 20:21
→ greg7575: 講a跟你b 01/20 20:21
→ greg7575: 一直腦補一直腦補一直腦補 01/20 20:21
推 lovez04wj06: 檔案無損跟傳輸後有損混為一談,是不是太可笑? 01/20 20:22
推 greg7575: 越看越好笑,這種還會有人護航。噗滋 01/20 20:27
推 greg7575: 大師連"無損"這兩個字的定義都有獨特的見解 01/20 20:33
→ greg7575: 看著看著,彷彿我變成了白痴。欣喜啊 01/20 20:34
→ greg7575: 大師的buffer想必也與凡人不同 01/20 20:35
推 greg7575: 串流還想重傳什麼?噗哇哈哈今年最好笑 01/20 20:39
→ elguapo: 反正都被笑成這樣,我就臉皮再厚一點。請樓上為我解釋 F 01/20 20:52
→ elguapo: LAC 的 frame 結構為何,如果 frame CRC 錯誤會怎麼處 01/20 20:52
→ elguapo: 理。再説一次,這是 FLAC 的「檔案結構」,我也不跟你 01/20 20:52
→ elguapo: 扯傳輸了,就「檔案結構」而已。A 和 B 我分得很清楚。 01/20 20:52
推 rattrapante: 說個笑話 flac有損 01/20 21:07
→ rattrapante: 自己先在那邊跳針串流掉包 01/20 21:08
→ rattrapante: 還要另闢戰場喔 是有沒有那麼辛苦 01/20 21:08
→ elguapo: 我知道我臉腫,也承認我錯,FLAC 在壓縮解壓縮是無損, 01/20 21:34
→ elguapo: 而且前面推文我也再三強調這件事,您要繼續這樣笑我, 01/20 21:34
→ elguapo: 我也只能坦然接受,讓自己永遠記得 FLAC 是無損,這件 01/20 21:34
→ elguapo: 事就當大家的閒嗑牙可以笑的事,我 ok,錯就要有勇氣承 01/20 21:34
→ elguapo: 認和承擔被笑被酸。但是我不解的是,當我知道我的不足 01/20 21:34
→ elguapo: 去真的好好的看了幾遍 FLAC 的規範文件,發現串流應用 01/20 21:34
→ elguapo: 上仍是有信號損失的可能,再拿出來請教這樣也有錯?就 01/20 21:35
→ elguapo: 像前面某人說我是 A B 分不清,但我認為 A 已經結案也 01/20 21:35
→ elguapo: 承認我的認知有錯,現在是真正讀了技術文件後的新問題 01/20 21:35
→ elguapo: ,如果有人也能告訴我 FLAC 在串流時能 100% 還原的理 01/20 21:35
→ elguapo: 論在哪裡我會自己去看,有錯也會自己掌嘴。 01/20 21:35
你自己都回答你自己的問題了
flac檔案就是無損
串流的時候丟封包是介面的事情
跟flac一點關聯都沒有
推 rattrapante: 哇塞 大師真的與眾不同 01/20 22:11
推 elguapo: 好吧 kb 大既然還是這麼認為我就此打住,no more questio 01/20 22:13
→ elguapo: n at all。期待您哪天能理解我的問題再闢新樓討論好了。 01/20 22:13
我早就理解你的問題了
然後我可以直接告訴你 你問的問題根本不是問題
是你對檔案跟傳輸的觀念沒有釐清
你從頭到尾都在你自己的錯誤邏輯打轉 所以沒什麼好回的...
推 rugger5566: 串流不是收音機,都會有buffer的,不然為何tidal播放 01/20 22:30
→ rugger5566: 檔案前都會有點延遲但開始播就不會有呢? 01/20 22:30
※ 編輯: kblover (111.240.126.80 臺灣), 01/20/2021 22:38:37
→ llw116: 串流漏封包就不是無損的話,那就沒有無損的串流了。 01/21 00:37
推 piyopiyolee: 每次回來看這串都很開心 01/21 02:05
→ greg7575: bro u make my day 01/21 09:49
推 e04su307: 整串看下來,最簡單的理解就是,串流封包的遺失是介面 01/23 14:01
→ e04su307: 、網路的鍋,你不能因為這個原因直接認為串流FLAC不是 01/23 14:01
→ e04su307: 無損格式,而去質疑FLAC的檔案格式,反而應該專注在網 01/23 14:01
→ e04su307: 路傳輸介面的穩定性上討論 01/23 14:01