Announcements Articles

things we have written about playlist logging

On the SoundExchange "Reports of Use Delivery Specifications"

Chapter 5: The SoundExchange reporting specs

SoundExchange has provided extensive reporting format specifications at:

The document states that they are SoundExchange's own understanding of the Copyright Royalty Board's regulations for the delivery of reports of use. The intent is to 'help Services in the reporting of data to SoundExchange' and indeed they are an excellent technical resource for anyone trying to create these reports.

In the course of our implementing the Reports of Use, we ran into a couple of glitches and questions, documented here to save others the same experience:

Issue #1: Minor Ambiguity with the filename naming convention

In sections 2.2.2, the report file naming conventions are specified, in the form of

ServiceNameSTARTDATE-ENDDATE_(transmission category abbreviation).txt
.. for example ..
Section 2.2.3 then notes
Each report of use should be compressed ... The zipped file should follow the same naming convention described above. However, instead of the ".txt" file extension, the file extension should be one of the three described immediately above' (.zip, .Z, or .gz)
This raises the question - should the resulting filename that is submitted to SoundExchange appear as:
... or ...
Because the default file naming behavior differs according to compression utility, operating system and platform ....
What SoundExchange told us: - use the second option, KFAKE20070115_20070121_H.gz. SoundExchange also noted that "compression was not explicitly mandated by the Federal regulations .. and was intended for people sending large reports over email" - in order to make sure the email didn't bounce due to size restrictions.

SoundExchange did not clarify upon their verbiage in section 2.2.3, which states "Each report of use should be compressed in one of the following formats". (Or, for that matter, section, which states "Services must compress their files using the data compression methods described above.")

For now, we're compressing everything we send them.

Issue #2: Contradiction in preferred artist names and sample data in 'Report Data Format'

From section 4.2.2:

All featured performers that are individuals (other than single-named artists such as STING), shall be reported as First_Name Last_Name, where the name of the featured performer is the name of an individual... Abbreviations are never permitted. All data shall be reported as the data appears on the physical or electronic product from which the Service obtains the sound recording, and not in any colloquial manner (e.g., "THE BEATLES" and "EAGLES" are the correct names for these two well-known artists, not "BEATLES" and "THE EAGLES"). SoundExchange prefers to receive all text fields in UPPER CASE.

The PDF 'File and Reports of Use Delivery Specifications Examples' provided by SoundExchange and linked to in the following section (4.3.1) begins with a reference to "THE EAGLES" - an incorrect, colloquial name, according to section 4.2.2.

Our opinion: This probably isn't a big deal, but it underlines the point. All names can probably be considered 'colloquial names', and this is an unrealistic request.

Issue #3: Error in report samples PDF

In section 4.3.1, the sample PDF mentioned above, 'File and Reports of Use Delivery Specifications Examples', contains several errors in the first example.

As shown in the image to the right, the Featured Artist and Sound Recording Title are swapped in the 2nd through 5th rows.

Our opinion: Disregard lines 2-5 in example 1, or at least until they fix their sample PDF.

As you can see, there's nothing totally critical, but there were certainly a few places we found ourselves scratching our heads - so we thought we'd point them out here.

Continue to Part 6: Conclusions

Part 1: Introduction
Part 2: Key concepts and issues
Part 3: Decisions, decisions
Part 4: Aggregate Tuning Hours
Part 5: The SoundExchange reporting specs
Part 6: Conclusions