Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation of windowed feature extraction processing #31

Open
codaich opened this issue Oct 20, 2016 · 3 comments
Open

Validation of windowed feature extraction processing #31

codaich opened this issue Oct 20, 2016 · 3 comments
Assignees

Comments

@codaich
Copy link
Collaborator

codaich commented Oct 20, 2016

  • Verify that things like sounding notes, tempo change messages and program change messages are maintained across windows (i.e. if a program change occurred in an earlier window, or a Note On occurred in an earlier window, then they should still be in effect in the next window).
  • Verification must occur before windowed extraction starts to ensure that only features with a value of true in their is_sequential field are extracted.
@dinamix1
Copy link
Collaborator

dinamix1 commented Dec 1, 2016

Fixed by both latest commits in UtilityClasses

@codaich
Copy link
Collaborator Author

codaich commented Dec 13, 2016

I'm no longer seeing the NaN, infinity and negative-value feature values (Issue #25), which is great.

However, I notice that the Duration feature tends to vary substantially from piece to piece when I do a windowed extraction. If I choose a 10-second non-overlapping window and do an extraction on the first few pieces of SLAC, for example, I see Duration feature values from 5 to 12, when they should all be 10 (except for the last window). Please look into why this is.

Also, just to double check, have you verified by both listening to test files and looking at feature values that sounding notes, the latest tempo change messages for each channel and the latest program change messages for each channel are maintained from previous windows? Including tempo and program change messages that have happened in, say, window #3, not just window #1? I haven't seen evidence that you haven't done this, but I just want to double check that you have before I do a deep analysis.

Also, I don't see anywhere in the code that you're checking that the is_sequential field is true for all features before that feature is extracted during a windowed extraction. Am I missing it somewhere?

@dinamix1
Copy link
Collaborator

dinamix1 commented Feb 2, 2017

9db6bcfc905d6ca1cdb280e97a97a744a814288e commit in UtilityClasses fixes this for normal midi windowing. Overlap offsets still needs to be implemented and tested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants