Announcements

RadioActivity.fm: Articles

things we have written about playlist logging

On the SoundExchange "Reports of Use Delivery Specifications"

Chapter 3: Decisions, decisions

Reporting Decision #1:
The first either/or decision a station must make is whether to report each play's ISRC code or, instead, the Album Title and Label.

The ISRC code
An International Standard Recording Code (ISRC code) is a twelve digit identifying code embedded into each track. It was designed to work across various media - CD's, MD's, DVD's, VHS, MP3, etc. In the U.S., ISRC codes are administered by the RIAA - media producers request an ISRC registrant code from the RIAA and can generate ISRC codes on their own once their registrant code has been assigned.

ISRC is a standard that is, at best, spottily employed. There is no master list of ISRC codes, or even of the known and issued registrant codes. There is no known estimate of how many publishers are employing and embedding ISRC codes in their media. It is virtually guaranteed that small-market labels and self-publishers are not embedding ISRC codes in their media. ISRC codes are, by design, only readable by the media player - they do not appear anywhere on the media or packaging readable by the human eye.

So, to sum up, ISRC codes

  • only appear on media produced by someone who has negotiated with the RIAA to receive their ISRC registrant code.
  • only appear on U.S. media produced after the RIAA begin assigning ISRC registrant codes.
  • only appear on media that supports the code inclusion (i.e., no vinyl, no tape, etc)
  • are not easily human readable, and are made only so with select equipment and software.
  • It is our opinion that including ISRC codes is virtually impossible at this point in time.

    "Reporting Decision #1", then, is no decision at all - virtually all stations will be forced to report the "Album Title and Label" combination instead of an ISRC code.

    Album Title is easy to determine. Grab a handful of CD's, however, and try to quickly determine their Label. You may note the following:

  • Unlike a CD title and track name, label names are often visually difficult to locate and distinguish
  • Label names may be confused by the presence of multiple entity names - producer, distributor, and other names, leading to incorrect label reporting
  • Names for the same label can differ across packaging - even their own)
  • (SoundExchange's own 'Examples on Location of Data Elements Identifying Particular Sound Recordings' only underscore the hunt-and-find nature of locating specific elements on CD packaging.)

    With all this in mind - with the addition of Album Title and Label name, there are now a total of six mandatory variables to record per play.

    Reporting decision 2:

    The second decision stations must make is whether to report the Actual Total Performances for each track, or instead the Aggregate Tuning Hours, Channel and Play Frequency for each track.

    Unfortunately, like ISRC, "Actual Total Performances" (ATP) is virtually impossible to provide. Take a look at the definition:

    ... each instance in which any portion of a sound recording is publicly performed to a listener via a Web Site transmission or retransmission (e.g. the delivery of any portion of a single track from a compact disc to one listener) but excluding ... a sound recording that does not require a license ... a sound recording for which the service has previously obtained license from the copyright owner ... and an incidental performance
    Thus, calculating ATP would mean calculating - for each track - the number of online listeners who heard that track - including any listeners that 'tuned in' while the song was streaming. RadioActivity.fm is currently unaware of any such solution that can provide this functionality.

    Again, the choice is not ours ...

    We now find ourselves in the same situation - unable to report "Actual Total Performances", we are forced to report the Aggregate Tuning Hours, Channel, and Play Frequency, bringing the number of mandatory fields per entry to nine.

    But wait! There's more! Two of these new additions - Play Frequency and Aggregate Tuning Hours - bear even further comment.

    Play Frequency is more or leass "How many times each track was played over the period you are reporting". According to the spec, SoundExchange reports don't allow duplicate lines for tracks - stations are supposed to count the number of performances of each track and provide a summary.

    In other words, a report that contains duplicate entries like:

    DJ Shadow / Building Steam With A Grain Of Salt / Island / 1
    DJ Shadow / Building Steam With A Grain Of Salt / Island / 1
    DJ Shadow / Building Steam With A Grain Of Salt / Island / 1
    DJ Shadow / Building Steam With A Grain Of Salt / Island / 1

    ... is incorrect. It should instead be reported as ...
    DJ Shadow / Building Steam With A Grain Of Salt / Island / 4

    Why does this matter to you, the station?

    It matters because it means you must analyze the plays for your reported periods to 'count' the number of performances for each before sending them to SoundExchange. For stations using databases (even Excel or Access) or with someone on staff that can write a quick log parsing tool, this is not unthinkable. But it raises the bar yet another notch for those that do not.

    Continue to Part 4: Aggregate Tuning Hours

    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