Due Date for Q3 2010 Data (July 1 - September 30): Friday, October 8, 2010


Archive for July, 2009

Deadline for Submitting Q3 SoundExchange Data – 10/16/09!

Wednesday, July 29th, 2009

Having now officially submitted Q2 reports to SoundExchange – big thanks again to all those who got, or tried to get us, data! – we are now already looking towards the next set of SoundExchange reports, for Q3 (July, August, September).

The fun just won’t end, will it?!

Recall that the vast majority of stations can pick any two 7-day-consecutive periods within the calendar quarter to report on. Once you pick your two weeks and have your data ready, we will take it! We are glad to get data early to help us spread out the report generation workload.

For those of you choosing two weeks late in the quarter – or for those of you procrastinators – we have set a  deadline for getting your data to us for the Q3 reports of Friday, October 16, 2009!! We will need your two weeks worth of data to us by then – and in the requested data formats (more on that in a second) – or we will not be able to generate reports on your behalf to submit to SoundExchange, and you will be considered non-compliant!

That would be bad. You don’t want to be non-compliant.

Again, to be crystal clear, that deadline for getting data to Public Interactive for Q3 SoundExchange reports is Friday, October 16, 2009! Please make a note and share this date with the appropriate folks at your station.

As I mentioned, we have now formulated file formatting guidelines for both playlists and streaming log files and have posted them on this here blog:

Click here for our playlist log file guidelines and to see a sample playlist log file.

Click here for our streaming log files guidelines and to see sample streaming log files.

As mentioned above, we need your data files to conform to these basic requirements or we cannot process them and hence cannot generate and submit reports on your behalf to SoundExchange! While we were quite flexible in taking data for Q2 reports, since the turnaround time for all involved was so quick, and relatively few stations were prepared to give us data, we now have to be more restrictive going forward in order to be able to process data from several hundred stations.

We appreciate your station’s efforts to meet these requirements.

Now, once you’ve chosen your two week reporting period and have obtained or generated playlist and streaming log files that meet our requirements, you’ll need to get us that data. How should you do that, you’re wondering?

Good question!

Depends on your situation and the timing. Here’s how:

  • Stations that are existing Public Interactive clients who use both Composer and have their streams hosted with us won’t need to do anything! We’ll have all of your data. Just make sure your playlist data is complete and up-to-date.
  • Stations that aren’t PI clients (or don’t use both Composer and our streaming services) will need to get us data files. As of right now, we provide stations with FTP accounts (one per content stream) on our servers to push the data to us. If I’ve already given you yours, use that. If you have data ready to give to us but don’t have a PI FTP account, contact me and I will provide one (or more).

Those who attended one of our SoundExchange reporting webinars will recall that we are building out a tool (based on our Composer product) called Composer Basic to allow stations to input their schedule data and upload playlist and streaming log files to us, all via the web. That tool is not yet availabl, but we’re hoping to have it ready for use before Q3 data is due. Once it is ready and available I will announce it here first!

OK, that’s the latest. Again, just to drive it into the ground, that deadline for getting data to Public Interactive for Q3 SoundExchange reports is Friday, October 16, 2009!

Don’t forget.

Please.

Thanks!

More SoundExchange Reporting Webinars!

Wednesday, July 22nd, 2009

I gave another webinar on SoundExchange reporting under the CPB-SX agreement this past Monday to the Public Radio Program Directors Association (PRPD). It was the best attended webinar yet (80+ people) and lots of questions were asked and (hopefully) answered. Thanks to Arthur Cohen for setting it up, MCing it and also recording the event.

Here are my slides from the presentation.

You can downloaded the video of the recording right here (Windows Media file).

I also did another webinar for NPR stations yesterday, the third of three. Here are the slides from that webinar, which are almost identical to those used for PRPD. That webinar, unfortunately, was not recorded.

I’ll be doing one more of these introductory webinars (whew!) for IMA member stations next Tuesday, 7/28, at 3:00pm ET – then that’s it!

Music Licensing and SoundExchange Reporting Webinar

Tuesday, July 21st, 2009

Last Friday an excellent webinar was hosted by our friends at the National Federation of Community Broadcasters (NFCB), for whom I gave a webinar on SoundExchange reporting at the end of June. Last Friday’s webinar was organized to answer to lingering legal questions about what can and can’t be streamed under the SoundExchange license, and also on what needs to be reported to SoundExchange via Public Interactive. The panelists were John Crigler and Melodie Virtue, two lawyers who were involved in crafting the agreement between the CPB and SoundExchange.

John and Melodie provided some excellent information on some of the legal issues around streaming music, and more details on the agreement between the CPB and SX. They were able to provide a lot of information that I can’t, not being a lawyer. It is recommended viewing for all stations. Pass the word.

You can download the entire video of the webinar here (Windows Media format).

It’s worth time to check it out.

First Round of SX Reports Done (Just About)!

Wednesday, July 15th, 2009

Earlier this week we closed the books on accepting Q2 data for SoundExchange reports from stations and compiled the reports for delivery. Technically, we’re still dotting a few i’s and crossing some t’s before final FINAL report delivery, but you get the idea.

Thanks to all the stations we gave us data – or made an attempt to get us data – in a very short amount of time, under very foggy circumstances. Some of you really helped us to blaze some trails along the way that will help other stations on down the line. You know who you are. Thanks especially to everyone for their patience as we (and I) figure out how this process will work. It will get smoother for all involved going forward, that much I promise.

Now that Q2 reports are (almost) done and delivered, that, of course, means that we’re already planning for Q3 reports! While the reports will be due to SoundExchange in late October, we will be looking to get data from all stations covered by the CPB-SX agreement as soon as they are ready to give it to us. Recall that almost all stations can choose two 7-day-consecutive periods within the quarter to report on (stations that need to report on the whole quarter already know who they are). So if your station feels that two weeks in July are representative of the music you play all during the months of July, August and September, then you can get us your data early and be done with it!

In any case, we will soon announce a specific (and hard) deadline for getting us Q3 data for inclusion in the reports delivered to SoundExchange.

We are working now on an online tool (Comnposer Basic) and process for stations to use to give us guide/schedule data, and to push playlist and streaming log files to us. Once that tool is ready for general use I will announce it here. If, in the meantime, you are ready to give us your Q3 data, contact me and we will work out a method for data delivery.

I recently posted a couple of pages outlining the formatting guidelines for both playlist and raw streaming access log files. These will probably change somewhat over time (we may go to a single, required file format for playlist logs, but that is still TBD), but for now follow these guidelines when preparing your data files for upload to us.

Finally, as I mentioned above and before, in order to be covered by the CPB-SoundExchange agreement you must register with the CPB, accept the terms of the CPB-SX agreement and then register with us. If you do not do this, you are not covered and we cannot generate and submit reports to SoundExchange on your behalf, even if you give us data!

As a reminder (from our FAQ page), here’s how all that registration works:

Q: How do I register my station for Internet Music Rights Coverage?

A: Follow this link on the CPB website to register.

Once you’ve registered with the CPB you will receive an email from them with a login to a web site to review and accept the terms of the SPB-SX agreement. You must accept the agreement in order to be a covered entity! PI can not submit reports on your behalf to SX until your station accepts the agreement!

I’ve registered on the CPB website and accepted the agreement. Now what?

Sign up with Public Interactive using this form.

In order to get started, we’ll need to gather some information about you and verify that you’ve registered with CPB. The PI Sound Exchange Project Manager will contact you directly to ask for data samples.

There you have it! Isn’t this fun?

Log File Guidelines

Monday, July 13th, 2009

I’ve just whipped up a couple of pages outlining the formatting guidelines for both playlist and raw streaming access log files.

I’ve include some sample files to download and use as guides.

Please take a look and feel free to contact me with any questions.

NPR Webinar Slides/Reporting Incidental Music

Wednesday, July 8th, 2009

I gave a webinar about SoundExchange reporting to NPR stations this past Tuesday, which was well attended. Many questions were asked and answered. Thanks to all who participated and my apologies to those whose questions I didn’t have time to get to.

The slides from my presentation can be viewed here.

Also, an important clarification has been made to an FAQ about how long a song recording can be played before it has to be reported. After further consultation with the legal eagles here is our official answer from the revised FAQs:

Q: Is there a threshold length for how long we can play a sound recording before we have to report it?

A: There is no simple threshold length to determine whether a song/recording needs to be reported. In short, all recordings play should be reported. However, there is an exception for performances that are brief AND incidental to the other program content. “Brief” means playing any one recording for less than 30 seconds (as long as it isn’t played in its entirety). “Incidental” is much more vague, but generally refers to musical transitions, performances during news, talk and sports programming and background performances. Again, both conditions must be met to meet the exception; simply playing less than 30 seconds of a recording is not enough; it has to also be incidental or secondary to the main program content. This leaves lots of room for grey areas. When in doubt, report it. For further clarification or questions, refer to your own legal counsel.

More Questions Answered

Thursday, July 2nd, 2009

Public Interactive and the CPB recently met with SoundExchange to clarify a few outstanding and quite frequently asked questions about SoundExchange reporting. A number of these were related to reporting on classical music. Here are some answers:

Q: Classical recordings often don’t have album titles. What should we report in those cases?

A: Report whatever title is on the physical CD or album from which it came (i.e. what’s on the spine). Whatever it says there is what is to be reported.

Q: How are we supposed to report song titles for classical pieces? Is a Beethoven symphony 4 tracks or 1?

A: However the label divides up the album tracks, that’s what to go on. So, if they split a Beethoven symphony into four tracks, each one is to be reported as a separate song title.

Q: What does “artist” mean for a classical performance? Is this the composer?

A: For classical music the Featured Artist/Group/Orchestra should be the soloist, orchestra or conductor that is featured prominently on the album.

In addition, many stations still have questions about the specific data that Public Interactive needs to collect in order to generate SoundExchange compliant reports. Here are a couple of the most popular and my answers:

Q: What pieces of information about songs do we need to track and report to Public Interactive for SoundExchange reporting?

A: For each song played on each stream, please provide the following data:

  1. Song title
  2. Featured artist/group/orchestra
  3. Album title
  4. Marketing label
  5. Start date and time of song play
  6. End date and time of play or duration of song

Q: Why does Public Interactive need to know the start times and end times or duration of each song?

A: Start and end times/duration are needed to calculate (1) the number of people who heard a given song (in order to match song play time with stream access during that time from your streaming logs) and (2) your station’s music Aggregate Tuning Hours (music ATH), which is the total hours of music streamed times the number of people listening at the time music was played.

Q: What type of data should be included in raw streaming logs?

A: Usually stations don’t have control over what is logged by their streaming server. In general, most streaming server applications (e.g. Shoutcast, Icecast) log similar information. Basically, in order to create SX-compliant reports Public Interactive needs raw streaming access logs that capture the following information:

    1. IP Address of requester (for filtering our requests from outside the United States)
    2. URL requested
    3. Status of request
    4. Start date and time of request
    5. End date and time or duration or request

      Q: Why does Public Interactive need to know the IP address of users accessing our streams?

      A: SoundExchange pays royalties based on music streamed to listeners in the United States. They have asked us to filter out requests from users outside of the country. In order to do this (as best as possible) PI needs to know the user’s IP address.

      I have updated the FAQ page on this site to include all of these new questions and answers.

      Please keep those questions coming!