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
Possible minor refactoring to improve the recognition rate.
Observation
A test against a set of audio tracks found that the PanakoStrategy.mostCommonDeltaTforHitList method will return the most common delta dependent on the number of occurrences. However, when more than one delta time has the same number of occurrences, the delta time returned is dependent on where it is stored in the HashMap, rather than a mathematical decision.
For example, for delta times x, y and z:
x with 1 occurrence
y with 2 occurrences
z with 3 occurrences
z is returned, but if x, y, and z delta times all have the same number of occurrences, which one is returned is dependent on chance - their position in the HashMap.
Suggestion
I don't know what mathematical decision is most suitable, but I tried taking the lowest delta time and this improved the recognition rate of the query. This is my quickly written alternative implementation of mostCommonDeltaTforHitList:
vartimeDeltas = newArrayList<TimeDeltaInfo>();
for(varqueryMatch : queryMatches) {
varfoundTimeDelta = false;
for(vartimeDelta : timeDeltas) {
if(timeDelta.timeDelta == queryMatch.getTimeDelta()) {
timeDelta.count ++;
foundTimeDelta = true;
break;
}
}
if(!foundTimeDelta) {
timeDeltas.add(newTimeDeltaInfo(queryMatch.getTimeDelta()));
}
}
// Get the time deltas with the highest number of occurrences at the toptimeDeltas.sort((a, b) -> b.count - a.count);
// Don't know what to do if we have no time deltas, so just return zero for nowif(timeDeltas.size() == 0) {
return0;
}
vartopTimeDelta = timeDeltas.get(0);
vartopTimeDeltas = newArrayList<TimeDeltaInfo>();
topTimeDeltas.add(topTimeDelta);
for(vari = 1; i < timeDeltas.size(); i++) {
if(timeDeltas.get(i).count == topTimeDelta.count) {
topTimeDeltas.add(timeDeltas.get(i));
}
}
// Get the smallest time delta as it seems to work better than taking the average or the largest time delta.topTimeDeltas.sort((a, b) -> a.timeDelta - b.timeDelta);
returntopTimeDeltas.get(0).timeDelta;
The text was updated successfully, but these errors were encountered:
For a 'real hit' I would expect one time delta to be much more common than any other time delta. So much so that the problem of having the same amount of time deltas should be relatively uncommon (but I did not test this thoroughly).
In any case, the the current (relatively random, based on hashmap position) behaviour for when the same amount of occurrences are present is indeed not ideal.
The smallest time delta might be a reasonable heuristic I am considering if there are others which might be reasonable.
Possible minor refactoring to improve the recognition rate.
Observation
A test against a set of audio tracks found that the PanakoStrategy.mostCommonDeltaTforHitList method will return the most common delta dependent on the number of occurrences. However, when more than one delta time has the same number of occurrences, the delta time returned is dependent on where it is stored in the HashMap, rather than a mathematical decision.
For example, for delta times x, y and z:
x with 1 occurrence
y with 2 occurrences
z with 3 occurrences
z is returned, but if x, y, and z delta times all have the same number of occurrences, which one is returned is dependent on chance - their position in the HashMap.
Suggestion
I don't know what mathematical decision is most suitable, but I tried taking the lowest delta time and this improved the recognition rate of the query. This is my quickly written alternative implementation of mostCommonDeltaTforHitList:
The text was updated successfully, but these errors were encountered: