Version control for audio files

Question

What is a good approach for version control of audio files?

I have a 20GB library of audio lectures to tune up and bring in to a state ready for releasing and sharing. It's important to keep the original files intact, as well as track certain milestones during editing (every single bit flip doesn't need noting).

While it would be super nice to a have a unified diff view like is possible with text, I know that is a pipe dream right now. What is important and perhaps feasible with today's software is to record the reason for the change and being able to fetch the file as it existed at that check-in.

The kinds of changes anticipated are:

• clipping dead air or irrelevant room noise from beginning and end of recordings
• selective volume levelling (e.g. speaker moved away from mic in minutes 12 to 18, or audience member asked question off-mic)
• applied filter to remove tape hiss/hum
• added or changed mp3 tag - such as artist name, recording date, ... (this is the one part that could be diffed perhaps?)
• etc.

I work primarily on Windows 7 but have linux machines too. My collaborators are mostly Windows and not technical. Tracking branching and merging (merging of branches, for the files it would be just straight overwriting) would be be great but not essential.

Storage should be of change deltas instead of dumb wholesale copies of each commit. We have more than adequate diskspace, but no one wants to copy 100s of gigs when only 20 are needed, and there's distinct possibility some collaboration will be over the internet

The project is for a very small non-profit organization. Tool purchase is not out of the question but would need to be inexpensive, though of course free and/or open source is much preferred.

Answer 1

1. Any and all of used now VCS can store and handle binary-files in repositories for almost any size ("don't store giant files in repo" is recommendation, not limitation). Some VCS just do it better, than another; and some VCS handle Big Data in repo better, than another

   record the reason for the change and being able to fetch the file as it existed at that check-in

is core of VCS and can't be governing parameters

2. For changing binary-data storing new version as not diff is almost common rule for VCSes (except applying different tricks in different VCSes for reducing deltas in storages), thus - which VCS to use it your choice and responsibility, I can only note some recent discussions about large files under version control, in which I participated on StackOverflow (top three answers) and repeat my personal opinion - Mercurial

All the kinds of changes anticipated are common tasks for any data, stored in VCS (perform change of content, store it) and aren't unique for audio-files (changing is changing regardless of what changes)

While it would be super nice to a have a unified diff view like is possible with text

You can at least try to get it: Foobar2000 with Binary Comparator plugin (answer found here on SU, in very useful in common topic) can (?!... not tried, not tested) compare (in GUI?!) two files of supported by Foobar2000 formats. Or (if it'll work on Win7 /old project, not updated from 2008/ and and will be usable for your tasks) see at Audio DiffMaker's DYF-files (additional object for storing in repo for any changeset, which change audio-data)

While you can add/change MP3-tags by any external tool, you can compare tags (fast and dirty search gave me at the first lines screenshot of Beyond Compare): Beyond Compare can be used as default diff|mergetool in Mercurial (TortoiseHG), Foobar2000 can be (probably) assigned as special mergetool for mp3-files

Storage should be of change deltas instead of dumb wholesale copies of each commit.

It isn't possible (in common case, see above p.2), but for Git with LFS or Mercurial with LargeFiles we have special case (can meet your needs better, than usual "all in repo"): all files for all changesets stored in independent external storage (full files), changesets in repos have only "link" to files, on local workplace you have downloaded only one big file (not the whole set for full history in your clone of repo for DVCS-case)... and all additional old versions needed for direct diffing (think again about using DYF from Audio DiffMaker): you'll must to have one giant storage, but will have some "saving" of local space, compared to "files in repo" case