Add has_bleed annotations to stems

[rabitt]

After discussing with @lostanlen, it makes sense to have has_bleed annotations at the stem level.

Open questions

• do we leave the multitrack level has_bleed annotations, and if so, what is the criterion (at least one stem with bleed, majority of stems with bleed, etc.)
• Can we make a reliable semi-automatic method to estimate for the database which stems have bleed? (@lostanlen, any ideas here?)

[lostanlen]

Thank you for opening this issue.
1.
If we are to have stem-level has_bleed annotations, then I cannot find a use case for keeping it at the track level as well. However, removing it breaks backwards compatibility. So my advice would be to listen to what users really need, and you make the final decision.

Yes, I think we can. Here is how:

• stack up all N stems in a multitrack of duration T. This yields a matrix M of size (N * T).
• compute the SVD of the matrix M = U * S * V', where U is unitary of size (N * N), S is of size (N * T), and V is unitary of size (T * T).
• Stems with bleed correspond to off-diagonal nonzeroes of U. Since U is unitary, they can be detected with a fixed threshold.

[carlthome]

For many applications a little bleed might be acceptable, but in some any bleed at all might screw up the results. I'd prefer if the has_bleed boolean was clearly defined by some signal-to-interference ratio threshold (these for example, which are basically the state-of-the-art measurements for source separation problems) and that the metric was added to the metadata so we could do our own thresholding as needed. I'm currently using mir_eval on top of MedleyDB to select tracks with low bleed manually.

[rabitt]

@carlthome: I agree that the has_bleed label should be based on a clear quantitative measurement. If I understand correctly, you suggesting creating the has_bleed label by thresholding something like SIR, and you have an implementation that does it. If so, could you point me to your code and/or submit a pull request?