☰

音频文件的版本控制

tag-icon • tag-icon audio version-control binary-files
音频文件的版本控制

对音频文件进行版本控制的良好方法是什么？

我有一个 20GB 的音频讲座库需要调整，以便发布和共享。保持原始文件完好无损以及在编辑过程中跟踪某些里程碑（无需注意每个位翻转）非常重要。

虽然拥有一个统一的差异视图（就像文本一样）会非常好，但我知道这现在只是一个白日梦。对于今天的软件来说，重要且可能可行的是记录变更的原因并能够获取当时签入时存在的文件。

预期的变化类型包括：

  • 从录音的开始和结束时剪切死气沉沉的空气或不相关的房间噪音
  • 选择性音量调节（例如，演讲者在第 12 到 18 分钟时离开麦克风，或者观众在麦克风外提问）
  • 应用过滤器消除磁带的嘶嘶声/嗡嗡声
  • 添加或更改了 mp3 标签 - 例如艺术家姓名、录制日期......（这可能是一个不同的部分？）
  • ETC。

我主要在 Windows 7 上工作，但也有 Linux 机器。我的合作者大多使用 Windows，而不是技术人员。跟踪分支和合并（合并分支，对于文件来说，这将是直接覆盖）会很棒，但不是必需的。

存储应该是更改增量，而不是每次提交的愚蠢批量副本。我们的磁盘空间绰绰有余，但当只需要 20 GB 时，没人愿意复制 100 GB，而且很有可能某些协作将通过互联网进行

该项目是为一家非常小的非营利组织开发的。购买工具并非不可能，但必须价格低廉，当然，免费和/或开源工具更受欢迎。

答案1

  1. 现在使用的所有 VCS能在存储库中存储和处理二进制文件几乎任何大小（“不要在 repo 中存储大文件”是建议，而不是限制）。有些 VCS 就是这么做的更好的与其他 VCS 相比，有些 VCS 能更好地处理 repo 中的大数据

    记录变更的原因，并能够获取当时签入时存在的文件

是VCS 的核心并且不能成为管理参数

  1. 对于将二进制数据存储为新版本没有区别对于 VCS 来说，这几乎是通用规则（除了在不同的 VCS 中应用不同的技巧来减少存储中的差异），因此 - 使用哪个 VCS 是您的选择和责任，我只能记录一些最近关于版本控制下的大文件的讨论，其中我参加了 StackOverflow（前三个答案）并重复我个人的意见 - Mercurial

所有预期的更改都是任何存储在 VCS 中的数据的常见任务（执行内容更改，存储它），并且对于音频文件来说并不是独一无二的（无论什么，更改都是更改）。有什么变化）

虽然有一个统一的差异视图会非常好，就像文本一样

你至少可以尝试去获取它：Foobar2000 带二进制比较器插件（找到答案这里在 SU 上，在常见主题中非常有用）可以（？！...没有尝试过，没有测试过）比较（在 GUI 中？！）Foobar2000 支持的两个文件格式。或者（如果它工作在 Win7 /旧项目，从 2008 年起未更新/并且将会可用的为您的任务）请参阅音频差异生成器的 DYF 文件（用于在 repo 中存储任何变更集的附加对象，用于更改音频数据）

虽然您可以通过任何外部工具添加/更改 MP3 标签，但您能比较标签（快速和肮脏的搜索给了我第一行Beyond Compare 的屏幕截图): Beyond Compare 可以用作 Mercurial (TortoiseHG) 中的默认 diff|mergetool，Foobar2000 可以（可能）被指定为 mp3 文件的特殊合并工具

存储应该是变化的增量，而不是每次提交的愚蠢的批发副本。

这是不可能的（在常见情况下，参见上文第 2 页），但对于带有 LFS 的 Git 或带有 LargeFiles 的 Mercurial，我们有特殊情况（可以比通常的“全部在仓库中”更好地满足您的需求）：所有变更集的所有文件都存储在独立的外部存储中（完整文件），仓库中的变更集只有指向文件的“链接”，在本地工作场所您只下载了一大文件（对于 DVCS 情况，不是你从仓库克隆的整个完整历史记录）... 以及直接比较所需的所有其他旧版本（再次考虑使用 Audio DiffMaker 中的 DYF）：你必须有一个巨大的存储空间，但与“仓库中的文件”情况相比，可以“节省”一些本地空间

相关内容