You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some applications call for non-uniform time sampling, eg, beat-synchronous features.
This is fairly involved to implement, since it requires both an estimator (beat tracker) and a post-processing of all dynamic observations, including both features and task outputs.
I think this can all be implemented with the following:
Introduce a new base class, Timing, which processes audio like a FeatureExtractor, but returns an array of non-overlapping time intervals.
In the FeatureExtractor and TaskTransformer objects, implement the following methods:
time_to_frames(times) which wraps librosa's implementation with the object's frame rate
resample(data, times) which resamples all of the entries of data generated by that object according to the specified time intervals. The results are returned as a new dict with the resampled data. In general, different analyzers will have different methods of summarizing observations within an interval, which is why each object needs to implement its own resampler.
In the pump object, add a new method to add a timing object. During transform, the timing is applied to each output as it is generated. The resampled versions are scoped under {timing.name}/ORIGNAL_SCOPE. A flag in the pump object can be set to retain the original analyses, or discard them in favor of the resampled ones. The timing intervals are stored as {timing.name}/_intervals.
Inverse transforms get tricky. I think the easiest way to accomplish this is to add a times= or intervals= parameter to the task inverters, which can bypass the frame-rate conversions when generating the jams annotation times.
The text was updated successfully, but these errors were encountered:
Some applications call for non-uniform time sampling, eg, beat-synchronous features.
This is fairly involved to implement, since it requires both an estimator (beat tracker) and a post-processing of all dynamic observations, including both features and task outputs.
I think this can all be implemented with the following:
Timing
, which processes audio like aFeatureExtractor
, but returns an array of non-overlapping time intervals.FeatureExtractor
andTaskTransformer
objects, implement the following methods:time_to_frames(times)
which wraps librosa's implementation with the object's frame rateresample(data, times)
which resamples all of the entries ofdata
generated by that object according to the specified time intervals. The results are returned as a new dict with the resampled data. In general, different analyzers will have different methods of summarizing observations within an interval, which is why each object needs to implement its own resampler.timing
object. Duringtransform
, the timing is applied to each output as it is generated. The resampled versions are scoped under{timing.name}/ORIGNAL_SCOPE
. A flag in thepump
object can be set to retain the original analyses, or discard them in favor of the resampled ones. The timing intervals are stored as{timing.name}/_intervals
.times=
orintervals=
parameter to the task inverters, which can bypass the frame-rate conversions when generating the jams annotation times.The text was updated successfully, but these errors were encountered: