最新

嗨，HN， 我大概有 2000 多个永远不会读的书签。可能你们也有。我一直在收集新的东西来阅读，列表每天都在增长，但我几乎没有时间去阅读它们，我意识到，问题更多的是关于要读什么而产生的分析瘫痪。有点像我们花很多时间在 Netflix 上琢磨要看什么电影一样。 所以我做了一个简单的 Chrome 扩展程序：它随机选择一个书签，把你带到页面上，并在一个浮动工具栏上给你两个按钮——“Stumble”（下一个随机书签）或“Done”（标记为已读并移至下一个随机书签）。就这么简单。它完全消除了选择的负担，并且由于接下来加载的内容的多样性（和新颖性），参与其中也很有趣，同时仍然在我想阅读的范围内。此外，我还添加了每日目标和连胜记录，以激励我完成列表并将它变成一个日常习惯。 你可以简单地右键单击 -> 添加到 Stumbleback 来保存新的内容，否则它只会读取你现有的 Chrome 书签，或者你也可以粘贴 URL，不需要单独的数据库。 它是免费的。欢迎任何尝试过但未能完成阅读列表的人提供反馈。

Speakrs 用 Rust 实现了完整的 pyannote community-1 风格的说话人分割流程：分割、幂集解码、重叠相加聚合、二值化、嵌入、PLDA 和 VBx 聚类。 该库路径中没有 Python 运行时。推理在 ONNX Runtime 或原生 CoreML 上运行，流程的其余部分则保留在 Rust 中。 在 macOS 上，它的速度快 20-30 倍，但在 linux/cuda 上仅快 2-3 倍（取决于 CPU）。 速度更快的几个原因： 1. Speakrs 使用了 CoreML 版本的模型。我专门导出了这些模型以在 CoreML 上运行。PyAnnote 只是通过 MPS (Metal) 在 macOS 上运行相同的 PyTorch 版本。 2. PyAnnote 不是单个模型，而是在一个流程中组合在一起的几个不同模型，自述文件中有关于完整流程的一些信息。 3. Speakrs 优化了流程，因此不同的部分可以在 CPU、神经引擎和 GPU 上运行。 Speakrs 具有批量模式，您可以在其中同时处理多个文件，这样做也可以让 CPU/GPU/ANE 都得到充分利用。 这就是为什么在 linux/cuda 上它没有那么快的原因，PyAnnotate 已经针对在 cuda 上运行进行了优化，我们在 cuda 上获得的加速是通过在 GPU 运行某些内容的同时在 CPU 上运行一些内容实现的。linux 上的加速将取决于 CPU 的性能。 还有一个快速模式，它牺牲了一些速度来换取准确性，速度可以提高 50 倍，并且对于某些类型的音频，不会牺牲太多准确性。基准测试对此有更多信息。