-
Notifications
You must be signed in to change notification settings - Fork 122
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
Audio alignment / skew detection #34
Comments
Gosh, I have zero memory of adding that function to the Matlab audfprint. No, I never added it to the python version. In principle, the same information is available, but it requires substantial additional code in the matcher. Sorry. |
Heh ;) But the relevant bits / info is present in the hashtable? Just want to make sure before I try to do anything in there. I guess the principle is relatively simple, currently we have the start time and end time (start time + length) of the query, along with the start time of the query in the source; I guess we need the end time of the query in the source, from the last pair of the matches, so we can calculate the time drift between the 2. Something like that? |
The relevant Matlab code is at: It actually performs a brute-force search for time warps in the range -2..2% in steps of 0.1% because I couldn't find a good closed-form way to estimate directly from the (time, time-offset) pairs. The basic idea is that once you have all the skew times for the matching hashes at Good luck if you dig into this! |
Thanks a lot for the info, I'll be sure to make a pull request if I achieve anything useful ;) |
@wegel were you able to make any progress here? Trying to understand the request... Given that the current code bins into windows of likely match, the skew addition (above) was to improve match timing granularity? It doesn't seem to add any robustness to actual timing skew (e.g. audio signal speed up or slow down, as sometimes employed by radio stations), right? |
My actual use case was to actually detect the (pretty small, something like 0.1%) time skew to be able to correct it; haven't worked on it though. |
@ezavesky : Let me provide a bit more detail to see if it helps you. As you mention, it's not that rare to encounter audio that is not at exactly the same timebase as the original. My first use-case was matching tracks between different masterings of the Beatles albums; it turns out the master tapes stretch by several tenths of a percent each time they are played, so the different masterings, though perceptually identical, have noticeably different durations and can't be perfectly aligned in time. I was actually trying to align chord annotations, and the errors could amount to several beats between start and end of the tracks. But it's also relatively common to deliberately change playback speed, either to squeeze in more time for commercials, or to do fine beat-matching in crossfades, etc. The fingerprint matching code finds similar landmarks (frequency peak pairs) in query and reference tracks, then calculates the difference of the absolute times within each track for each match. The assumption is that if the recordings match, even if we only identify a few common landmarks every second, over a long stretch of common material we'll see that the relative timing is consistent, indicating a non-chance match. But if the timebases have been stretched so that If we knew In the Matlab code referenced above, I tested 41 values of If you ignore this distortion of landmarks by time stretching (which was working for me), testing a range of DAn. |
Hi,
Can this python version be used for detecting / correcting audio alignment as the Matlab version (eg, from https://labrosa.ee.columbia.edu/~dpwe/resources/matlab/audfprint/#3 ) ? If so, any pointer on how to proceed? Thanks!
The text was updated successfully, but these errors were encountered: