The following is a guest post by Carl Fleischhauer, a Digital Initiatives Project Manager in NDIIPP.
In mid-October, BMS/Chace of Nashville, Tennessee, released the “first generation version” of a software tool to support the collection of metadata for the multi-track, multi-session sound recordings being produced in the music industry today. The Metadata for Recorded Sound project was one of the NDIIPP Preserving Creating America partnerships, carried out from 2006 to 2010. As part of the project, BMS/Chace developed the Content Creator Data (CCD) tool, as well as the data dictionary and XML schema that it implements, in cooperation with the Recording Academy (the Grammy award folks), and representatives of major record labels.
Workflow diagram for the production of a commercial sound recording today. The row of red boxes in this diagram highlight the main segments in the life cycle: tracking, overdubbing, mixing, mastering, linkage of metadata, and archiving. The distribution segment follows mastering but is omitted from this diagram. The four blue boxes at the bottom indicate the types of metadata collected in each segment. These are illustrative examples; the full data dictionary defines hundreds of elements. Courtesy BMS/Chace.
What is at stake here? In part, the metadata is intended to facilitate business relationships within the recording industry. Producers are contractually required to deliver certain materials to the record labels (a charmingly quaint term in this digital age). In turn, the labels or their agents put the recorded music into commerce as physical CDs, downloadable files, generally sold by third parties. At every turn, there is a need for descriptive, administrative, and technical metadata.
As the diagram shows, some metadata is best collected in the tracking and overdubbing segments of the content life cycle. Later, additional administrative metadata can be collected in the mixing segment. Toward the end of the production cycle, when the release is mixed, mastered and prepared for distribution, there is a need to collect and link additional administrative metadata (this might be where the working title turns into the for-release title), and to describe the final technical formats (where is the final multi-track and how is it configured, is this the stereo or the surround mix and, if surround, which flavor, etc?). The masters and derivatives also need to be linked with the identifiers used in commerce and long-term preservation, e.g., the International Sound Recording International Standard Recording Code (ISRC) and the Digital Data Exchange (DDEX) identifiers and associated metadata.
“Before” CCD: a track-sheet from the container for the 24-track tape from a major artist recording session in 1990. In order to document all of the information, the engineers had to add boxes to the boxes on the form. Any additional needed metadata would be scribbled on plain paper and enclosed in the tape storage container.
What is the Library of Congress stake in all of this? The recordings are part of our cultural heritage and standardized metadata will support archiving and preservation by the labels and also by memory institutions. For their owners, the sound recordings are assets that have (they hope!) multi-year cash value. Meanwhile, copies are acquired by the Library of Congress (via copyright processes) as well as by other libraries, e.g., those that serve university music departments. The metadata associated with the content will help all parties manage it and provide access over the long term. Only through effective metadata capture and linkage can we hope for creators, performers, and content owners to be accurately credited and compensated for their work.
“After” CCD: some of the data from a (hypothetical) session that covers some of the same ground as the paper label above. The full CCD record has dozens more data elements than are shown here. This is the graphical user interface; the underlying data can also be output as XML.
It is too soon to say how well this tool will catch on. Two major labels conferred with BMS/Chace as the project moved forward and representatives of those companies are making trial runs with the application. Meanwhile, Maureen Droney, Senior Executive Director of the Recording Academy’s Producers & Engineers Wing, says, “We once had systems in place for documenting the recording process, but with our transition from analog to digital recording and distribution there is now a huge void where those systems used to be. The CCD application is a huge step in the right direction to help recording professionals gather and archive important information at the source—where music is being created.”
Comments (4)
Fascinating news, coming when it does at a time when I am personally considering my own approaches to my own independently-produced music.
It will be interesting to see how this is embraced by other independent producers who face all of the very same issues but utilize Creative Commons licensing for their outputs.
The CCD EULA says “The software and documentation accompanying this License are licensed, not given, to you. You acknowledge that you may not copy, decompile, reverse engineer, disassemble, modify, or create derivative works of the CCD Collection Tool software or any part thereof nor may you rent, lease, lend, redistribute or sublicense the CCD Collection Tool software.”
If the Library of Congress is involved, I think it’s a shame that this project isn’t freely modifiable by anyone. But as usual, the labels are trying to maintain a tight control over everything they do. This will be their downfall.
The EULA wording for the proof-of-concept CCD Collection Tool now available is intended to create some degree of “lock-down” while we continue to get beta feedback. This language will not apply to the as yet unreleased CCD schema, which is the primary thrust of the LOC work.
In order to provide maximum functionality and ease of use in the Collection Tool, a proprietary application (Adobe Air) was used in its development. Internally, the Collection Tool uses its own field names and structures that are then mapped to the schema. The internal data structure of this particular Collection Tool is not directly relevant to any future interoperability. Ultimately, anyone will be able to build whatever type of collection application best suits their needs, using the published CCD Schema.
We have not published the CCD Schema under any license at this point – but when we do, our desire will be to make it as open and freely useable as possible while staying in sync with DDEX, undoubtedly the group most able to align CCD participant metadata with the rest of the food chain. DDEX uses an “implementation license”, freely available to anyone, but still allowing them to continue development without “forking” the standards process. This way, anyone can implement DDEX XML messaging suites without cost, but DDEX is still able to keep the development path on the straight and narrow. We believe this is the best approach.
It is our goal to have the CCD work incorporated into the DDEX implementation process, because with no on-going oversight, we will potentially see versions that won’t communicate with a number of other global standards, such as ISNI and GRid (both ISO specifications), that are essential to identify and “connect” performers and their work.
Contrary to any perceived intent to limit use of the CCD Schema to major record labels, quite the opposite is true. The scope of DDEX members (and potential CCD users) is extremely broad – they include the “majors”, but also PROs, Harry Fox, Apple, aggregators, publishers, content resellers, independent labels, and many others. A complete list of DDEX members can be found here (http://www.ddex.net/members_list.htm).
Uniformity and compatibility are our goals – to provide a platform that serves major labels, indie labels and artists, DIY artists and anyone creating music. Because the amount of money for a single stream or download is so small, the payment processes have to be automated – and available to all parties.
We want to see global compatibility in as many areas as possible, and quite simply, some parts are not yet ready. I hope this helps in how you view the project.
Hello John Spencer. As it turns out I actually run a digital distribution company for music and I am very interested in a software that can compile metadata of tracks and generate a DDEX compliant XMl file thereof. I’d be interested in testing the BETA or having some type of access to the software.
I have ran into several bumps in the road when dealing with new retailers such as Google Play and am finding it hard to find any type of documentation, help, or any type of software that can make this transistion easier. My e-mail is [email protected] Is there a way I can reach you?