看到这篇文章很用心 但我看到一些点觉得有些似是而非
基本上不是做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的档案格式，反而应该专注在网络传输接口的稳定性上讨论