오디오 파일의 버전 관리에 대한 좋은 접근 방식은 무엇입니까?
나는 조정하고 공개 및 공유할 준비가 된 상태로 만들 수 있는 20GB의 오디오 강의 라이브러리를 가지고 있습니다. 원본 파일을 그대로 유지하고 편집하는 동안 특정 이정표를 추적하는 것이 중요합니다(모든 단일 비트 플립에 주목할 필요가 없음).
텍스트로 가능한 것처럼 통합된 diff 보기를 갖는 것이 매우 좋을 것이지만, 지금 당장은 그것이 헛된 꿈이라는 것을 알고 있습니다. 오늘날의 소프트웨어에서 중요하고 아마도 실현 가능한 것은변경 이유그리고 할 수 있는 것해당 체크인 당시 존재했던 파일을 가져옵니다..
예상되는 변화의 종류는 다음과 같습니다.
- 녹음 시작과 끝에서 죽은 공기나 관련 없는 실내 소음을 잘라냅니다.
- 선택적 볼륨 조정(예: 화자가 12~18분 내에 마이크에서 멀어지거나 청중이 마이크 밖에서 질문함)
- 테이프 히스/윙윙거림을 제거하기 위해 필터 적용
- 아티스트 이름, 녹음 날짜 등 mp3 태그를 추가하거나 변경했습니다. (이 부분이 아마도 다를 수 있을까요?)
- 등.
저는 주로 Windows 7에서 작업하지만 Linux 시스템도 사용하고 있습니다. 내 공동 작업자는 대부분 Windows이며 기술적이지는 않습니다. 분기 및 병합(분기 병합, 파일의 경우 바로 덮어쓰기) 추적은 훌륭하지만 필수는 아닙니다.
스토리지는 각 커밋의 멍청한 전체 복사본 대신 변경 델타여야 합니다. 우리는 충분한 디스크 공간을 갖고 있지만 20개만 필요할 때 100개의 공연을 복사하고 싶어하는 사람은 없으며 인터넷을 통해 일부 협력이 이루어질 가능성이 뚜렷합니다.
이 프로젝트는 아주 작은 비영리 단체를 위한 것입니다. 도구 구매는 불가능하지 않지만 가격이 저렴해야 합니다. 물론 무료 및/또는 오픈 소스가 훨씬 선호됩니다.
답변1
- 현재 사용되는 모든 VCS~할 수 있다거의 대부분의 저장소에 바이너리 파일을 저장하고 처리합니다.어느크기("저장소에 대용량 파일을 저장하지 않음"은 권장 사항이지 제한 사항은 아님) 일부 VCS는 그냥 그렇게 합니다.더 나은, 다른 것보다; 일부 VCS는 다른 VCS보다 리포지토리의 빅 데이터를 더 잘 처리합니다.
변경 이유를 기록하고 해당 체크인 시 존재했던 파일을 가져올 수 있음
~이다VCS의 핵심관리 매개변수가 될 수 없습니다.
- 새 버전을 저장하는 이진 데이터를 변경하려면차이가 없다이는 VCS에 대한 거의 일반적인 규칙입니다(스토리지의 델타를 줄이기 위해 서로 다른 VCS에 서로 다른 트릭을 적용하는 것을 제외). 따라서 어떤 VCS를 사용할지는 귀하의 선택과 책임입니다. 버전 제어 하에 있는 대용량 파일에 대한 최근 논의만 언급할 수 있습니다.StackOverflow에 참여했습니다.(상위 3개 답변) 그리고 반복내 개인적인의견 - Mercurial
예상되는 모든 종류의 변경은 VCS에 저장된 모든 데이터에 대한 일반적인 작업(콘텐츠 변경 수행, 저장)이며 오디오 파일에 고유하지 않습니다(변경은무엇이 바뀌는가)
텍스트로 가능한 것처럼 통합된 차이점 보기를 갖는 것이 매우 좋을 것입니다.
적어도 그것을 얻으려고 노력할 수 있습니다:바이너리 비교기가 있는 Foobar2000플러그인(답변을 찾았습니다.여기SU에서는 공통 주제에 매우 유용합니다) Foobar2000 형식이 지원하는 두 파일을 (GUI에서?!) 비교할 수 있습니다(?!... 시도하지도, 테스트하지도 않음). 아니면 (그렇다면일하다Win7/이전 프로젝트, 2008년부터 업데이트되지 않음/쓸 수 있는귀하의 작업에 대해서는) 다음을 참조하세요.오디오 차이 메이커의 DYF 파일(오디오 데이터를 변경하는 모든 변경 세트에 대해 저장소에 저장하기 위한 추가 개체)
외부 도구를 사용하여 MP3 태그를 추가/변경할 수 있지만~할 수 있다태그 비교(첫 번째 줄에서 빠르고 더러운 검색이 나에게 제공되었습니다.Beyond Compare 스크린샷): Beyond Compare는 Mercurial(TortoiseHG)에서 기본 diff|mergetool로 사용될 수 있으며, Foobar2000은 (아마도) mp3 파일에 대한 특수 mergetool로 할당될 수 있습니다
스토리지는 각 커밋의 멍청한 전체 복사본 대신 변경 델타여야 합니다.
불가능합니다(일반적인 경우 위의 p.2 참조). 그러나 LFS가 있는 Git 또는 LargeFiles가 있는 Mercurial의 경우 특별한 경우가 있습니다(일반적인 "all in repo"보다 요구 사항을 더 잘 충족할 수 있음): 모든 파일에 대한 모든 파일 독립적인 외부 저장소(전체 파일)에 저장된 변경 집합, 저장소의 변경 집합에는 파일에 대한 "링크"만 있고, 로컬 직장에서는 다운로드만 했습니다.하나큰 파일(DVCS 사례에 대한 저장소 복제본의 전체 기록에 대한 전체 세트가 아님)... 및 직접 비교에 필요한 모든 추가 이전 버전(Audio DiffMaker에서 DYF를 사용하는 것에 대해 다시 생각해 보세요): 하나가 있어야 합니다. 거대한 저장소이지만 "저장소에 있는 파일"의 경우에 비해 로컬 공간이 일부 "절약"됩니다.