I don’t enter song durations, for a few reasons, 1) not all songs are played as long as the signified duration 2) I include DJ talk at the end duration of a song. 3) I pre-record the show, so it is much easier just to use the time stamp feature. Thus, there is no duration on the playlist. Although, it seems that on earlier shows, the duration was entered automatically ( I remember it doing this also). So if I wanted the actual duration to be included on the playlist, how can I get that without actually entering it… can´t the spinitron software do the math from the beginning of one song to the beginning of the next?
Hi Julie, thanks for joining the forum.
Spinitron does the math, if it has the song duration.
Spinitron’s autocomplete, “Did you mean?” search, and recognition all will usually find nominal song duration.
Take a look at this video. And there are others here.
Hi Tom, I think what Julie wants is for it to go the other way, calculate duration from the timestamps. I have had part of that problem, usually with EDM shows I get from other stations. When I manually enter the playlist they give me, they are way too long according to autocomplete or “Did you mean…” , part of the Mixing Artistry don’t ya know. On the other hand, I enter some playlists with chatterbox hosts and the music times out 10- 20 minutes short. The real answer to this is to use Cue instead of Submit and press now when the song actually starts but I have other things to do so I will fudge numbers to make it fit, but that’s not really an answer. For Julie I would suggest the durations aren’t as important as the timestamps for regulatory compliance (ie keeping your written logs in line with your audio transcript). Unless there is another reason for needing durations to be accurate that I am unaware of?
Hi Arbie, thanks for chiming in. I really hadn’t understood what Julie was asking.
I need to ask you and Julie and anyone else who would like to help me, why do you care about spin duration?
I believe listeners are typically uninterested in spin duration. NPR requires either duration/end time in webcast playlist logs. SoundExchange does not. SX isn’t interested in when or for how long you play a song, rather they care about the number of performances during the report period.
So in order to suggest a workflow, or to discuss possible changes in Spinitron that might assist, it would help to know what you want durations for? Iow: What purpose is served by them? Iyow: What are you trying to accomplish?
For myself, the “duration” is useful when I’m prerecording a program. Duration helps me to more accurately guesstimate when the song will actually play.
​​I agree, listeners probably don’t care about spin durations. I have three reasons.
-
Particularly during covid, hosts/producers are sending me hour-long files and a playlist, often just artist-track. When I enter them in Spinitron, mainly I care that they all fit within the hour. As I am unlikely to sit through shows with my finger on the “now” buttons, I enter with “submit” instead of “cue” and timestamp automation set to “Last song start time + duration”. This works fine for standard music shows as most play the whole track, the only inaccuracy is from talk time and occasionally from not knowing whether they played the extended version or the radio edit. It’s when they get all fancy with editing down songs, playing with tempo and all that stuff that playlists can get all whacky.
-
People will call or email and ask “what was that song at 10:45 am yesterday”. It helps if the log is relatively accurate. Related to that, we use Radio Rethink’s Airpocket player on our website and send people there to see “what’s playing now”, it will never be that accurate, but close is better.
-
In the unlikely event that the CRTC asks to audit us, my understanding is that our written log should, as accurately as possible, reflect the audio log so that they can find what they are looking for (they are reactive, someone has probably complained you did something wrong and they want to cut to the chase)
Hopefully Julie can enlighten us as to what her reasons are, I have a feeling she has at least one reason I haven’t thought of
Thanks Arbie. I interpret your points as follows:
-
Song duration is useful to the DJ when preparing a show in advance. That’s true if you play all of the recording and Spinitron knows which one you’re playing and knows its duration.
-
Point taken. But since it’s usually not hard to estimate the song in question given only their timestamps, I’m not sure duration is pulling its weight here.
-
This seems like a general “just in case” kind of thing. I think it’s hard to estimate if this justifies making DJs log accurate spin duration.
I feel no closer to understanding why one might want Spinitron to assign spin duration by subtracting its timestamp from that of the subsequent spin. My only guess is that you might want this feature if for bureaucratic reasons the station requires a duration value for every spin. Such reasons might be derived from NPR’s reporting requirement. But in this case I believe its better for everyone if we automate this calculation when we generate the report and not burden DJs with the task for every spin.
I agree that time accuracy, however one derives it, is much less important than having all the songs listed. If the CRTC or FCC want more specifics there are plenty of ways to come up with any details they might require. For DJs creating shows, there are easier tools than Spinitron for timing a show. If I am creating their Spinitron listing (as I do for syndicated shows) and they don’t give me a list with durations to work from, then I am stuck with what auto-complete comes up with unless I want to sit and preview the show with a stopwatch. As I said, this is particularly noticeable in EDM shows, which are essentially an hour-long medley of tunes and part tunes and mashups. If the main need is to keep “what’s playing now” more or less accurate, the easiest solution would be to require DJs to list durations. I am sure you could invest a lot of time crafting a solution but why when the solution is more simple to implement elsewhere. Spinitron’s strength is in the ease of real time entry during a live show and duration is a simple matter of clicking “now” at the right time. IMHO and YMMV.
Arbie has it right… what I was trying to convey, the opposite of what Tom was saying. I don’t care about song duration and I’m sure listeners don’t care either. And I do not believe that ASCAP, BMI, SoundExchange, etc… require song durations… And… my radio station has not required that in the past… but now… for some reason… they think that they need that information and are demanding that we include it for licensing purposes. I just think it is a waste of time and a p.i.t.a.
(I usually enter the time stamps or click “now” when cued… rather than enter the song durations because they don’t always add up 1) due to silence at beginning and or end of song 2) due to overlap/segue 3) due to fading song out 4) due to dj talk… which I usually don’t enter separately, but let it add on to the previous song… the following song starting on cue).
That’s correct. The only external requirement comes from NPR, which requires it for their own reasons. NPR aggregates webcast reports of use to sound exchange for all stations that operate under the rates and terms agreed between CPB and SoundExchange. So stations that report to NPR have to include duration or end-time in those reports.
However, most stations that use Spinitron and report to NPR do not report year-round. They report for only two-weeks per calendar quarter. These stations could, if they choose, disable the requirement for duration or even disable the duration field altogether outside of those report periods. Admins can do this in Spinitron as shown below.
Agreed. When this requirement was promulgated, we objected as best we could, unsuccessfully.
But, given the requirement, we do what we can to mitigate the burden on stations and DJs. To that end, your suggestion is a good one and we’ll see if we can do it in a future update to the software.
Another idea I had is to hide the duration/end-time fields in Spinitron and fudge spin durations during NPR report generation. In other words, for each spin that we export when we generate an NPR report, we make up something plausible up and fill that in for duration. If we do that carefully then, for the purpose of calculating royalty payments, I think the results would be satisfactory and not much worse than the current allocations based on sample reporting. We don’t do this because Spinitron doesn’t have the authority to make stuff up copyright compliance reports. If stations want this feature and took responsibility for using it then it’s easy enough for us to implement. In this case, DJs would not need to deal with duration/end-time at all.
Note: your suggestion is a kind of fudge similar to what we could do during report generation. The difference is that it would be under the interactive control and responsibility of the DJ.
One quick thing to add for Canadian radiobroadcasters. It’s my understanding that SOCAN requests duration times during their quarterly audits as they pay artists based on plays, but also on the duration if songs are only partially played.
I don’t think they do partial payments but they don’t consider anything under a minute to be a play (or any song under a minute to be a song…I remember protest shows of only songs under a minute making that a point)
I thought that comp was for CRTC to count songs under a minute as counting toward cancon. I’m pretty sure SOCAN will count any backing tracks in ads, etc. which is also important for syncing dues for tv commercials, excerpts on tv, etc.
for the record:
Hmmm. I appear to have mixed my CRTC and SOCAN issues up. In my experience SOCAN has relaxed their “must have” demands and increased their “if you can, please do” requests. And that includes duration, record company, CD title. The demands are song title, artist, if it’s a theme song or background, and if it’s an instrumental. Maybe song start time, back when we wrote the report it out by hand they did but I think they dropped it back to optional.