SoundExchange Reporting Blog

A new year has begun which, aside from meaning that we’re all little bit older (as my kids enjoy reminding me of frequently), also means that anther calendar quarter has ended for which SoundExchange reporting data are soon due.

What better way to begin a new year than by meeting legal requirements? I don’t know about you but nothing better comes to mind for me.

As you should know by now, the mechanics of reporting to SoundExchange through PI changed a bit from Q3 to Q4, mainly with the release of Composer Basic (and the renamed and revamped Composer Pro for our previous Composer clients). Here are the main points to keep in mind:

1. All reporting data from Q4 2009 (that is data from between the dates of October 1 – December 31, 2009) must be in the required format and submitted to Public Interactive  by COB Friday January 15, 2010, in order for us to guarantee that we can generate and submit reports to SoundExchange on your station’s behalf.

2. Playlist log files that meet our formatting requirements are required from all stations that are not PI Composer Pro clients. Also, streaming log files are required from all stations that do not host their streams through Public Interactive.

3. Composer Basic users must accept the Terms of Service before we can officially accept your data and generate reports.

4. Every station (both Composer Pro and Basic users) must specify their chosen reporting dates using the SoundExchange Dashboard in Composer Pro or Basic.

5. Stations that stream Classical 24 – again whether you are a Composer Pro or Basic user – must  update the guide information for each of your streams in Composer to properly reflect when you streamed C24 during your reporting period, so that we can integrate those playlists into your reports. IMPORTANT NOTE: When adding the Classical 24 program in your guide, be sure to set the Program Format to Classical: C24.

All stations that have registered with Public Interactive for SoundExchange reporting should now have a login to either Composer Pro or Composer Basic. If you do not, contact me and I’ll send you your login.

If you have already uploaded files to us, whether via FTP or Composer Pro/Basic and have not yet confirmed with me that we got them and they are in the correct format LET ME KNOW ASAP! We’re still working out the kinks in the new tools and don’t want anybody to fall through the cracks.

OK, let’s all start the year by being fully compliant! Thanks as always for your efforts.

It used to be that two things in life were certain: death and taxes. For those streaming music on the web, add one more thing: quarterly SoundExchange reporting.

To that end, this is a reminder to you public radio stations that have chosen to be covered by the CPB-SoundExchange agreement that we’re a little more than three weeks away from the deadline to get us at Public Interactive your reporting data on music streaming for the third quarter of 2009. That deadline is Friday, October 16, 2009!

A number of stations have already given us their data for processing (thanks!) and many, many more have told me they are working on it. We’re happy to take your data as soon as you have it ready. But October 16 is really – honestly, truly – the latest that we’ll be able to take your data for inclusion in Q3 reports that will be submitted to SoundExchange. We submit all station reports in one big batch to SX, so we cannot grant extensions.

I won’t rehash the basics of registration and reporting here; you can read about those particulars in this post.

Let me use this space to answer a few common questions and highlight some other things to keep in mind:

1. Your chosen 14 day reporting period must indeed be fully contained within Q3 (July 1 – September 30). SoundExchange will not accept reports containing data outside those three months.

2. Composer Basic (which includes the SoundExchange Reporting Dashboard) – which will be used to transfer your data files to us – is not yet ready for public consumption. For now, data transfers will continue to be done via FTP.

3. Your playlist files must be in the proper file format, described here, or we cannot process them and, hence, will not be able to file reports on your station’s behalf.

4. If you submitted files to us for Q2 in a different format you still need to submit Q3 files (and beyond) in the required format! For Q2 we accepted just about whatever data we could get, due to the time constraints, but we are requiring the new format going forward.

In other matters, last week in Cleveland I took part in an excellent panel discussion (with lengthy Q&A) on SoundExchange reporting at the PRPD conference. You can access the presentation slides and handouts here. I’ll be participating in a similar session at the upcoming WSPR conference in Portland, OR on Wednesday November 4. If you’re going to be there, be sure to drop by and introduce yourself.

As always, please feel free to contact me with any questions or when you are ready to send us your data files.

As I have mentioned here before, we have posted guidelines for the formatting of playlist and streaming log files to be submitted to Public Interactive for SoundExchange reporting on this here blog. With the deadline for getting us your Q3 SoundExchange reporting data really not all that far off (seven weeks from Friday, but who’s counting?) – and since these guidelines have been tweaked a bit since first posted, I figured it was worth it to revisit these guidelines.

Streaming Access Log File Guidelines

Since, in general, streaming log files are produced by software applications (e.g. Windows Media, SHOUTcast, Icecast, Real, etc.) these really are just guidelines to make sure your server is logging the required data, since stations won’t generally have control over the formatting. We’re ready to work with the various formats produced by these tools, since there are only a handful of them that most stations use.

Playlist Log File Guidelines

Playlist log files, however, are another matter. These really are requirements, not just guidelines, in that we must have your data in a fairly specific format in order to make automated processing possible. Many stations track playlist data using a homegrown application or a spreadsheet, so it’s just not possible for us to try and accommodate the near infinite variety of possible data formats that could arise. For those that use commercial applications (e.g. Spinitron, MusicMaster, Liquid Compass, etc.) we have been working with the vendors where possible to communicate our formatting needs.

Please be sure to review our playlist file formatting requirements if you haven’t recently! If the data is not given to us in the required format we will not process it and won’t be able to submit reports on your behalf to SoundExchange.

Some of the finer points of the formatting to bear in mind:

• Files must be tab-delimited, text files (i.e. no spreadsheets, Word documents, PDFs, etc.)
• Please use the following exact field identifiers: Title, Artist, Album, Label, Start Time, End Time, Duration. Field ordering within the file doesn’t matter, so long as your are consistent throughout.
• Please do not include any other data in the playlist file, other than the header row and playlist entries (i.e. no schedule data)
• Start Time must include the date (i.e. one field for the start date and time, not two separate fields); same for End Time.
• Times must be in 24-hour format

If your station will be entering playlist data by hand, we have prepared an empty, sample spreadsheet that you could use as a starting point.

Download this sample playlist entry spreadsheet here.

It has all of the required fields (though remember that we only need either End Time OR Duration, not both), including the proper field headers, and formatting for start and end times. Once you enter your data you would simply choose to Save As a Tab Delimited text (.txt) file, which you can then send to Public Interactive. Voila!

These requirements are pretty well set now, but it’s possible we may tweak things if the need arises in the future. When and if that happens I will be sure to note it here in the blog. Thanks to everyone for your patience as we work the kinks out of this whole process.