Global observations: avoid time/duration

[urinieto]

Is there any way I could add an observation without the fields time and duration, such that it becomes a track-level observation (e.g., track-level tag)?

[justinsalamon]

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?

[urinieto]

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)
...

[justinsalamon]

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.

[justinsalamon]

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.

[urinieto]

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?

[justinsalamon]

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

jams/jams/core.py

Lines 597 to 599 in 255a5ee

	Observation = namedtuple('Observation',
	['time', 'duration', 'value', 'confidence'])
	'''Core observation type: (time, duration, value, confidence).'''

I may be wrong but I believe that supporting observations both with and without time/duration would require a major overhaul that would impact a significant number of lines (apart from the core structure, think validation and every operation currently supported on annotations), if it's even feasible under the current design.

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

[bmcfee]

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.

[urinieto]

Sounds good. Thanks for your help!