Global observations: avoid time/duration about jams HOT 8 OPEN

I agree it's cumbersome, but time/duration are baked into the definition of an observation:

Since @bmcfee was the main architect behind the observation tuple, he should probably chime in here.

from jams.

I agree it's cumbersome, but time/duration are baked into the definition of an observation:

Yes, the schema is written such that all observations have a time and duration (non-negative float) to validate properly.

I think the correct thing to do here is as @justinsalamon says: make the implicit quantities explicit by documenting the length of the track in the observation fields. Of course, nobody forces you to use that information, but it needs to be there to validate in the schema.

from jams.

AFAIK every observation in JAMS must have a time and duration, it's baked into the basic observation structure. The convention is that tags (track-level annotations) have a duration that matches the track duration.

If you're working with data that lives exclusively in tag space (i.e. not mixing strong labels and tags) so you could, for example, use the tag_open namespace and just assume the tag is track-level and ignore the time/duration values. Or does that not address your situation?

from jams.

That's what I thought too, but tag_open still requires time and duration with the current API (or perhaps I'm doing something wrong?). Ideally, I'd like to do something like this:

jam = jams.JAMS()
ann = jams.Annotation(namespace='tag_open', time=0, duration=total_track_dur)
ann.append(confidence=conf, value=tag1)
ann.append(confidence=conf, value=tag2)
...

from jams.

Sorry, I meant ignore the actual values of time/duration, but you must still set them because it's baked into JAMS observations.

So you could either do:

ann.append(confidence=conf, value=tag1, time=0, duration=total_track_dur)

or

ann.append(confidence=conf, value=tag2, time=0, duration=0)

And just ignore the time/duration values in the rest of your code. I'd opt for the former just because it means if you ever do need the duration of the observation it's set correctly.

from jams.

p.s - another motivation for using total_track_dur is that, if you ever end up trimming or slicing the audio/jams, if the trimmed section doesn't intersect with the start/end times of an observation, the observation will be removed from the annotation. So by setting time=0, duration=total_track_dur you guarantee that any trimming/slicing operation will still maintain all the tags.

from jams.

It still feels a bit cumbersome to having to add these values at the observation level (and have them repeated along the whole raw JSON annotation), when you just want to use the global ones that are already available at the annotation level.

Maybe something to consider for the next release?

from jams.

Sounds good. Thanks for your help!

from jams.