Satelli

Satelli

V2EX 第 33817 号会员,加入于 2013-02-07 11:33:36 +08:00
今日活跃度排名 4903
根据 Satelli 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
Satelli 最近回复了
是的楼主,单核性能上 M3 是第一梯队,M4 已经一骑绝尘。

回 @luckykong
日常使用通常都是偶发少数核突发性能需求。打开文件/网页、滚动页面(触发事件响应)、切换软件(触发生命周期),甚至普通开发里开多个浏览器页面、跑多个容器、编辑器代码补全/类型推导/自动测试等,这些工况不是核越多越好,而是需要少数几个极强的核心满足需求。

而高效率的多线程计算例如
并行编译:Firefox 、Chrome 等大规模项目,
视频转码(编码器优化良好情况下),
CPU 渲染:Cinebench 、激光/声呐 3D 扫描建模、点云优化,
游戏刚开始时的着色器编译之类,这种情况是核越多越好。

M3 和 13 代 Intel 桌面 CPU 单核性能相差无几,但是 M3 的 4 个大核是不降频的。
作为对比,Intel 笔记本 CPU 单核就跑不到 5.5+ GHz ,而且也只有 1 个核能跑到最高的频率(散热允许下),2 个核就开始降频,6 核满载降频更多。

实际要看你的需求,观察一下在做事情的时候任务管理器 CPU 负载是怎样的,这样能更好的判断是买核心多的好还是核心强的好。
11 天前
回复了 DokiDokiSophon 创建的主题 耳机 EarPods TypeC 口转传统 3.5mm 无效
是指 EarPods (USB-C) 吗? https://www.apple.com.cn/shop/product/MTJY3FE/A
这个耳机以及苹果的 USB-C 转 3.5mm 转换器 https://www.apple.com.cn/shop/product/MU7E2FE/A
本质上都是一个 USB-C 接口的声卡。接在正常设备上都是没有问题的,本人已测试过苹果 USB-C 的 iPhone, iPad, Mac 、几台 Android 手机、两台 PC 。

我的理解是你买了一个转换头把 3.5mm 转换成 USB-C 接在电脑上,然后再把 EarPods 接在 USB-C 上,这种情况下请检查你的转换器。转换器需要将音频信号转回数字信号,并提供正常的 USB 协议。

在早期 Android 手机刚刚切换到 USB-C 接口时部分手机输出音频的做法是通过复用 USB-C 的引脚来输出模拟音频信号,部分 USB-C 耳机支持这种工作方式。你买的转换器也应该只是这种将 3.5mm 的引脚转换到 USB-C 的引脚,没有做模数转换。
@DjangoPan M1 只能“物理”输出 2 个显示器,笔记本内建屏幕占用一条后只剩一条。没有任何“硬件”解决方案。

DisplayLink 是软件方案,虚拟出一个显示器,私有协议,USB 传输,私有转换器转回 DisplayPort 信号。

类似的还有官方的 Sidecar 随航或者 Duet Display 等。

这些都是软件实现虚拟显示器,通过 USB 、无线等方式传输压缩后的视频流再解码。不是无损的信号了。
23 天前
回复了 gklll 创建的主题 Apple MacBook Pro 购买求教
@gklll 能用就继续用吧,年底换 M4 基础款 MacBook Pro 不是更好?肯定会默认支持盒盖输出 2 台显示器的。
如果不换双层 OLED 继续沿用 miniLED 的话,M4 更新的显示引擎是不是可以输出 2 + 1 呢😀。毕竟 M1 到 M3 是 SoC 的显示引擎物理限制,只有 2 条 DisplayPort 。
* 以上是瞎猜。
23 天前
回复了 gklll 创建的主题 Apple MacBook Pro 购买求教
正好有一台 M3 MacBook Pro (灰色)。以及上一台也是 M1 Pro 的 MacBook Pro (银色)。
M3 的 MacBook Pro 盒盖输出 2 台显示器的更新还没有实装。

以前 M1 Pro 的续航确实不太满意。
现在 M3 的情况是每天晚上 7 点到 11 点用 2 - 3 小时,大多数是看 YouTube 刷推聊天或者轻量级写点代码之类的。
电池是真的顶。一个星期都不用充电。用 Chrome 看 YouTube 时候的整机功耗 4W ,70W 的电池差不多能看 17 个小时。

性能上,单核比 M1 系列强 40-50%,多核和 6+2 的 M1 Pro 差不多。所以干重活两台差不多,干轻活、刷网页之类的,比 M1 系列要更流畅。
GPU 的话 M3 10 核比 M1 Pro 14 核弱 5% - 10% 左右。不过你也基本用不到。

本地轻度写代码 + debug 这个简直是高性能单核的强项,4 个大核全开都不降频,IDE 界面、切换软件等操作是会非常流畅的。
@inhzus
@YongXMan
苹果平台支持 EDR 的屏幕上激活 HDR 内容时会动态调整 headroom (即该区域逐渐变亮的过程)导致页面重绘吃满 CPU 。
https://issues.chromium.org/issues/329479347

典型触发时机就是网页中 HDR 内容刚开始移入时或刚好完全移出后。
该问题仅影响苹果自己的能显示 HDR 内容的屏幕,不影响外接的有独立 HDR 开关的屏幕。

Safari 的受此影响较小。Chrome 重绘中会直接把基础款 CPU (如 M3 )打趴下,过程中甚至导致 Activity Monitor 刷新卡住/变慢。
@intinatsu 附个图。


TLDR.
1. “上传无损曲目”不正确。
如果没有匹配到苹果的音源,对于无损文件,iTunes 或 Apple Music 会先用自带的 CoreAudio AAC 编码器转换成 256 Kbps (iTunes+) 音质,再上传。不是“「未匹配」的无损曲目再下回来会变为 AAC”,而是上传前就已经转换成有损 AAC 。

2. “本地的文件是不会被修改的... 但是不可以删除本地文件只保留云端”是对 iCloud 云端资料库理解有误。对于已匹配,其不关心本地是什么文件。在当前设备上播放的是本地 iTunes/Apple Music 资料库 xml 里指向的文件。
可以理解为把无损文件添加进本地资料库,iTunes/Apple Music 进行 match 并根据结果更改云端资料库,然后本地资料库将这个文件视作“已下载”的文件。当删除这个“已下载”的文件时,iTunes/Apple Music 会使用已匹配的音源来播放。

3. “如果上传 AAC 的话,源文件会不会被修改还真说不准”混淆了上传/匹配。
对于 320 Kbps 以下的有损文件会直接上传。下载回来的是一模一样的。
对于已匹配的有损文件来讲,下载回来的和原本的文件在绝大多数情况是不一样的(从 bit-perfect 角度来讲)。
在其他渠道获取到(即使是正版)的音源是母带➡️无损➡️渠道的编码器转换成有损(即使都为 AAC ,各渠道编码器质量也千差万别),而苹果这边是母带/Apple 数字母带或者更早期的 Mastered by Apple➡️无损➡️CoreAudio AAC 转换成 256 Kbps AAC 。除了本身就在 iTunes Store 购买的 AAC 有损或者从分享网站下载的 iTunes 音源外,匹配到的和本地文件是不一样的。

4. “可能会加上歌词”是正确的。
前提是在本地删掉元数据中的自定义歌词。部分刮削软件比如 MusicBrainz Picard 会添加 LRC 格式的歌词作为文本。删掉后已匹配的歌曲在播放时也会使用 Apple Music 的动态歌词。

5. 原 po 没有提到 DRM 。
“「已匹配」的无损曲目下回来有概率会带上 DRM”是有误的。对于 Apple Music ,所有已匹配的曲目,在清除本地文件后下载的,或者在其他设备上下载的都带 DRM 。iTunes Match 服务匹配的不带 DRM ,所以才叫“洗白”。
看到 @drainlin 的回复,意识到可能是接地/静电原因。
在公司,我用过的 M1 Pro 、M3 以及一台 Windows 笔电都出现过这种情况,给笔记本接电一瞬间一台显示器黑掉。或者人站起来走两步(地毯)又回座位坐着然后碰了下笔记本外壳(金属)。
因为这个问题长期下来显示器都被打坏 2 台,一台我的一台同事的。
37 天前
回复了 shutongxinq 创建的主题 Apple M4 单核 GB6: 3767,多核 14677
Apple Music 的 iCloud Library 是这样的。
自己的歌先 match ,match 后是苹果的音源,但是元数据还是你自己的。这点和 iTunes Match 是不一样的。
match 不了的,320 Kbps 以下的有损 MP3 或 AAC 是直接上传。无损的 ALAC 是要转换成 iTunes+AAC 音质,即 256 Kbps AAC 。
题外话,Apple CoreAudio AAC 编码器质量是极高的。绝大部分人是听不出无损和 CoreAudio AAC 编码器的 256 Kbps 的区别的。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1028 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 19:24 · PVG 03:24 · LAX 12:24 · JFK 15:24
Developed with CodeLauncher
♥ Do have faith in what you're doing.