1

Каков хороший подход для контроля версий аудиофайлов?

У меня есть библиотека аудиозаписей объемом 20 ГБ, чтобы настроить и привести в состояние, готовое к выпуску и обмену. Важно сохранить исходные файлы в целости, а также отслеживать определенные этапы во время редактирования (каждый щелчок по биту не нужно замечать).

Хотя было бы очень хорошо иметь унифицированное представление различий, как это возможно с текстом, я знаю, что сейчас это несбыточная мечта. Что важно и возможно осуществимо с сегодняшним программным обеспечением, так это записать причину изменения и возможность получить файл, который существовал на момент регистрации.

Виды ожидаемых изменений:

  • отсечение мертвого воздуха или неуместного комнатного шума с начала и конца записи
  • выборочное выравнивание громкости (например, динамик отошел от микрофона через 12–18 минут, или участник задал вопрос вне микрофона)
  • применил фильтр для удаления шипения / шума
  • добавлен или изменен тег mp3 - например, имя исполнителя, дата записи, ... (возможно, это та часть, которую можно найти?)
  • и т.п.

Я работаю в основном на Windows 7, но у меня тоже есть машины с Linux. Мои сотрудники в основном Windows, а не технические. Отслеживание ветвления и слияния (слияние ветвей, для файлов это будет просто прямая перезапись) было бы здорово, но не обязательно.

В хранилище должны быть измененные дельты, а не тупые оптовые копии каждого коммита. У нас более чем достаточно дискового пространства, но никто не хочет копировать сотни концертов, когда нужны только 20, и есть определенная вероятность того, что какое-то сотрудничество будет через Интернет

Проект для очень небольшой некоммерческой организации. О покупке инструмента не может быть и речи, но она должна быть недорогой, хотя, конечно, бесплатный и / или открытый исходный код гораздо предпочтительнее.

1 ответ1

3
  1. Любой из всех используемых в настоящее время VCS может хранить и обрабатывать двоичные файлы в репозиториях практически любого размера («не храните гигантские файлы в репо» - это рекомендация, а не ограничение). Некоторые VCS просто делают это лучше, чем другие; и некоторые VCS обрабатывают большие данные в репо лучше, чем другие

    запишите причину изменения и возможность получить файл, существовавший на момент регистрации

является ядром VCS и не может регулировать параметры

  1. Для изменения хранения новой версии бинарных данных как не diff это почти обычное правило для VCS (за исключением применения разных приемов в разных VCS для уменьшения дельты в хранилищах), поэтому - какую VCS использовать, по вашему выбору и ответственности, я могу только отметить некоторые недавние обсуждения больших файлов под контролем версий, в которых я принимал участие в StackOverflow (первые три ответа) и повторяю свое личное мнение - Mercurial

Все ожидаемые изменения являются общими задачами для любых данных, которые хранятся в VCS (выполняют изменение содержимого, сохраняют его) и не являются уникальными для аудиофайлов (изменение меняется независимо от того, какие изменения)

Хотя было бы очень хорошо иметь унифицированное представление различий, как это возможно с текстом

Вы можете, по крайней мере, попытаться получить его: Foobar2000 с плагином Binary Comparator (ответ найден здесь на SU, в очень полезной общей теме) может (?! ... не пробовал, не тестировал) сравнивать (в GUI?!) два файла поддерживаемых форматов Foobar2000. Или (если он будет работать над Win7 / старым проектом, не обновленным с 2008 года / и будет использоваться для ваших задач), посмотрите в DYF -файлах Audio DiffMaker (дополнительный объект для хранения в репозитории для любого набора изменений, который изменяет аудио -данные)

Хотя вы можете добавлять / изменять MP3-теги с помощью любого внешнего инструмента, вы можете сравнивать теги (быстрый и грязный поиск дал мне на скриншоте первых строк Beyond Compare): Beyond Compare может использоваться как стандартное diff | mergetool в Mercurial (TortoiseHG) , Foobar2000 (вероятно) можно назначить как специальный mergetool для mp3-файлов

В хранилище должны быть измененные дельты, а не тупые оптовые копии каждого коммита.

Это невозможно (в общем случае, см. Выше стр. 2), но для Git с LFS или Mercurial с LargeFiles у нас есть особый случай (может удовлетворить ваши потребности лучше, чем обычное "все в репо"): все файлы для всех наборы изменений хранятся в независимом внешнем хранилище (полные файлы), наборы изменений в репозиториях имеют только "ссылку" на файлы, на локальном рабочем месте вы скачали только один большой файл (не весь набор для полной истории в вашем клоне репо для случая DVCS)... и все дополнительные старые версии, необходимые для прямого сравнения (подумайте еще раз об использовании DYF из Audio DiffMaker): у вас должно быть одно гигантское хранилище, но будет некоторая "экономия" локального пространства по сравнению с "файлами в репо" " дело

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .