Hello,

We are in the works of making a buyout contract with a composer who has made music for us for our game. Everyone is happy with the deal, but we have a concern.

How can we uniquely identify the songs in the buyout agreement to make it absolutely clear what songs are in question?

The music isn't officially registered anywhere. It has no official copyright registration number either. We want to avoid a situation in which the music is paid for, but then the composer comes back to say "Hey, the level 1 music is not the level 1 music I sold you."

Thanks in advance.

If you can get the original files from the composer (assuming they're all digital instruments), you can print the track visualization in the contract. Otherwise, it's a little tricky to put music on paper.

If you can get the original files from the composer (assuming they're all digital instruments), you can print the track visualization in the contract. Otherwise, it's a little tricky to put music on paper.

Oh thank you! We didn't think of that. That makes a lot of sense.

Has anyone else seen something like this in a contract? Would this hold up legally?

A couple of suggestions:

If you have the final mix-down files that you'll use in your game, you can generate a SHA256 signature for each. This is a long alphanumeric value that identifies a file. It is used by several organisations.
You can use Hashdeep for this:
http://md5deep.sourceforge.net/start-hashdeep.html#basic

You can also use something like EchoNest Codegen, which generates an acoustic fingerprint. An ac. fingerprint is a collection of data that is said to identify a song even in different encodings and quality levels. This could be better for you.
You need a programmer to help you use this library:
https://github.com/echonest/echoprint-codegen
If you use this you would want your programmer to write a simple command line utility that reads an audio file and outputs its ac. fingerprint as a text file. You can then attach it to the contract or use it to identify a song in question, by generating a fingerprint for the song in question and comparing the two fingerprints for discrepancies.

EDIT: changed the recommendation from libOFA to EchoNest Codegen, a more modern and reliable solution.

Has anyone else seen something like this in a contract? Would this hold up legally?

It's the digital equivalent of sheet music. If you use the right visualization, it should be more or less human readable too, so that would probably be your strongest protection (as well, even having that file itself means a lot: It's like an artist sending a PSD). Use several visualizations of the tracks if you can.

More high-tech solutions might confuse a judge if there was ever an issue. Imagine yourself trying to explain how something works, or having to fly in an expert to testify on the matter. Also, it might confuse your musician too, and he or she could testify that he/she had no idea what it was he/she was signing away because it wasn't human readable. This makes it dangerous.

I mean, sure, add those in too if it's not inconvenient (that would arguably make it stronger), but the sheet music is your best bet.

You can also use the pieces' titles or filenames.

I've never seen a clause in a contract that went to this level of detail (and I've composed music for around 140 or so games over the past couple of decades).

It's probably much simpler to create a good chain and record of delivery. For example, when a piece is delivered, what is the mechanism by which you 'sign off' on it and accept it? Put something in that process that unambiguously makes record of what they've delivered to you.

One simple thing is that at the final stage of acceptance of a music deliverable, in addition using FTP, dropbox, etc, have them email you the same piece in mp3 format, so you have a clear record in your inbox (from their email address) of what was delivered. Make payment contingent on that.

One note on the analysis tools . it's trivially easy to make files with different SHA256 signatures for the same piece of music, since all that does is say that files are exactly the same. All the composer would have to do would be to create a slightly different 'mix' of the same piece, which would sound exactly the same, but it would have a different SHA256 sig. I'm not familiar with echoprint, but would guess that it can suffer from a similar issue.

While I understand your concern, I think the place to address this is in your delivery/acceptance mechanism, not the contract.