Controle de versão para arquivos de áudio

Question

Qual é uma boa abordagem para controle de versão de arquivos de áudio?

Tenho uma biblioteca de 20 GB de palestras em áudio para ajustar e deixar pronta para lançamento e compartilhamento. É importante manter os arquivos originais intactos, bem como rastrear certos marcos durante a edição (cada mudança de bit não precisa ser anotada).

Embora fosse muito bom ter uma visão de comparação unificada como é possível com o texto, eu sei que isso é um sonho agora. O que é importante e talvez viável com o software atual é registrar omotivo da mudançae ser capaz debuscar o arquivo como ele existia naquele check-in.

Os tipos de mudanças previstas são:

• cortando o ar morto ou ruído irrelevante da sala no início e no final das gravações
• nivelamento seletivo de volume (por exemplo, o alto-falante se afastou do microfone nos minutos 12 a 18 ou um membro da audiência fez uma pergunta fora do microfone)
• filtro aplicado para remover chiado/zumbido da fita
• tag mp3 adicionada ou alterada - como nome do artista, data de gravação, ... (esta é a única parte que poderia ser diferenciada, talvez?)
• etc.

Eu trabalho principalmente no Windows 7, mas também tenho máquinas Linux. Meus colaboradores são principalmente Windows e não técnicos. Rastrear ramificações e mesclagens (mesclagem de ramificações, para os arquivos seria apenas uma substituição direta) seria ótimo, mas não essencial.

O armazenamento deve ser de deltas de alteração em vez de cópias idiotas de atacado de cada commit. Temos espaço em disco mais do que adequado, mas ninguém quer copiar centenas de shows quando apenas 20 são necessários, e há uma possibilidade distinta de alguma colaboração ser feita pela Internet.

O projeto é para uma organização sem fins lucrativos muito pequena. A compra de ferramentas não está fora de questão, mas precisaria ser barata, embora, é claro, o código aberto e/ou gratuito seja muito preferido.

Answer 1

1. Todo e qualquer VCS usado agorapodearmazenar e manipular arquivos binários em repositórios por quasequalquersize ("não armazene arquivos gigantes no repositório" é uma recomendação, não uma limitação). Alguns VCS simplesmente fazem issomelhorar, do que outro; e alguns VCS lidam melhor com Big Data em repositórios do que outros

   registrar o motivo da alteração e poder buscar o arquivo como ele existia naquele check-in

énúcleo do VCSe não pode governar parâmetros

2. Para alterar dados binários armazenando nova versão comonão difereé uma regra quase comum para VCSes (exceto aplicar truques diferentes em diferentes VCSes para reduzir deltas em armazenamentos), portanto - qual VCS usar é de sua escolha e responsabilidade, só posso observar algumas discussões recentes sobre arquivos grandes sob controle de versão, nas quaisParticipei do StackOverflow(três principais respostas) e repitameu pessoalopinião - Mercurial

Todos os tipos de mudanças previstas são tarefas comuns para quaisquer dados, armazenados em VCS (realizar alteração de conteúdo, armazená-lo) e não são exclusivas para arquivos de áudio (mudar é mudar independentemente deO que muda)

Embora fosse muito bom ter uma visualização de diferenças unificada como é possível com texto

Você pode pelo menos tentar obtê-lo:Foobar2000 com comparador binárioplugin (resposta encontradaaquino SU, é muito útil em tópicos comuns) pode (?!... não tentei, não testei) comparar (na GUI?!) dois arquivos de formatos suportados pelo Foobar2000. Ou (se fortrabalharno Win7 /projeto antigo, não atualizado desde 2008/ e seráutilizávelpara suas tarefas) veja emCriador de diferenças de áudioArquivos DYF do (objeto adicional para armazenamento no repositório para qualquer conjunto de alterações, que altera dados de áudio)

Embora você possa adicionar/alterar tags de MP3 por qualquer ferramenta externa, vocêpodecompare tags (a pesquisa rápida e suja me deu nas primeiras linhascaptura de tela do Beyond Compare): Beyond Compare pode ser usado como diff|mergetool padrão no Mercurial (TortoiseHG), Foobar2000 pode ser (provavelmente) atribuído como mergetool especial para arquivos mp3

O armazenamento deve ser de deltas de alteração em vez de cópias idiotas de atacado de cada commit.

Não é possível (no caso comum, veja a página 2 acima), mas para Git com LFS ou Mercurial com LargeFiles temos um caso especial (pode atender melhor às suas necessidades, do que o normal "all in repo"): todos os arquivos para todos conjuntos de alterações armazenados em armazenamento externo independente (arquivos completos), conjuntos de alterações em repositórios possuem apenas "link" para arquivos, no local de trabalho você baixou apenasumarquivo grande (não o conjunto completo para o histórico completo em seu clone do repositório para o caso DVCS)... e todas as versões antigas adicionais necessárias para comparação direta (pense novamente em usar DYF do Audio DiffMaker): você precisará ter um armazenamento gigante, mas terá alguma "economia" de espaço local, em comparação com o caso "arquivos em repositório"