Какой подход к контролю версий аудиофайлов является наилучшим?
У меня есть библиотека аудиолекций на 20 ГБ, которую нужно настроить и привести в состояние, готовое к выпуску и распространению. Важно сохранить исходные файлы нетронутыми, а также отслеживать определенные этапы во время редактирования (не нужно отмечать каждый отдельный битовый переворот).
Хотя было бы очень здорово иметь унифицированный вид различий, как это возможно с текстом, я знаю, что это несбыточная мечта прямо сейчас. Что важно и, возможно, осуществимо с сегодняшним программным обеспечением, так это записыватьпричина измененияи быть в состоянииизвлечь файл в том виде, в котором он существовал на момент регистрации.
Ожидаются следующие виды изменений:
- обрезка мертвого воздуха или ненужного шума помещения в начале и конце записи
- выборочное выравнивание громкости (например, говорящий отошел от микрофона на 12-й или 18-й минуте или кто-то из аудитории задал вопрос не в микрофон)
- применен фильтр для удаления шипения/гула ленты
- добавлен или изменен mp3-тег - например, имя исполнителя, дата записи, ... (возможно, это единственная часть, которая может отличаться?)
- и т. д.
Я работаю в основном на Windows 7, но у меня есть и машины с Linux. Мои коллеги в основном работают на Windows и не являются техническими специалистами. Отслеживание ветвления и слияния (слияние ветвей, для файлов это будет просто прямая перезапись) было бы здорово, но не обязательно.
Хранилище должно быть дельтами изменений, а не тупыми оптовыми копиями каждого коммита. У нас более чем достаточно дискового пространства, но никто не хочет копировать сотни гигов, когда нужно всего 20, и есть явная вероятность, что некоторое сотрудничество будет через интернет
Проект для очень маленькой некоммерческой организации. Покупка инструмента не исключена, но она должна быть недорогой, хотя, конечно, бесплатный и/или с открытым исходным кодом гораздо предпочтительнее.
решение1
- Любые и все используемые сейчас VCSможетхранить и обрабатывать двоичные файлы в репозиториях почтилюбойразмер ("не хранить гигантские файлы в репозитории" - это рекомендация, а не ограничение). Некоторые VCS просто делают этолучше, чем другие; и некоторые VCS обрабатывают большие данные в репозитории лучше, чем другие
записать причину изменения и иметь возможность извлечь файл в том виде, в котором он существовал на момент регистрации
являетсяядро VCSи не могут быть управляющими параметрами
- Для изменения двоичных данных, сохраняющих новую версию какне отличаетсяэто почти общее правило для систем контроля версий (за исключением применения различных приемов в разных системах контроля версий для уменьшения дельт в хранилищах), таким образом, какую систему контроля версий использовать, это ваш выбор и ваша ответственность, я могу только отметить некоторые недавние обсуждения больших файлов под контролем версий, в которыхЯ участвовал в StackOverflow(три лучших ответа) и повторитемой личныймнение - Mercurial
Все виды предполагаемых изменений являются обычными задачами для любых данных, хранящихся в VCS (выполнение изменения содержимого, его сохранение) и не являются уникальными для аудиофайлов (изменение является изменением независимо откакие изменения)
Хотя было бы очень здорово иметь единое представление различий, как это возможно с текстом
По крайней мере, вы можете попытаться это сделать:Foobar2000 с двоичным компараторомплагин (ответ найденздесьна SU, в очень полезной в общей теме) может (?!... не пробовал, не тестировал) сравнить (в GUI?!) два файла поддерживаемых Foobar2000 форматов. Или (если это будетработана Win7 /старый проект, не обновлялся с 2008 года/ и будетпригодный к использованиюдля ваших задач) см. наАудио DiffMakerDYF-файлы (дополнительный объект для хранения в репозитории для любого набора изменений, изменяющего аудиоданные)
Хотя вы можете добавлять/изменять MP3-теги с помощью любого внешнего инструмента, выможетсравнить теги (быстрый и грязный поиск дал мне в первых строкахскриншот Beyond Compare): Beyond Compare можно использовать как средство сравнения по умолчанию в Mercurial (TortoiseHG), Foobar2000 можно (вероятно) назначить как специальное средство сравнения для mp3-файлов
Хранилище должно содержать дельты изменений, а не оптовые копии каждого коммита.
Это невозможно (в общем случае, см. выше п.2), но для Git с LFS или Mercurial с LargeFiles у нас есть особый случай (может удовлетворить ваши потребности лучше, чем обычное «все в репозитории»): все файлы для всех наборов изменений хранятся в независимом внешнем хранилище (полные файлы), наборы изменений в репозиториях имеют только «ссылки» на файлы, на локальном рабочем месте вы загрузили толькоодинбольшой файл (не весь набор для полной истории в вашем клоне репозитория для случая DVCS)... и все дополнительные старые версии, необходимые для прямого сравнения (подумайте еще раз об использовании DYF из Audio DiffMaker): вам понадобится одно гигантское хранилище, но будет некоторая «экономия» локального пространства по сравнению со случаем «файлов в репозитории»