Precomputed technique gives same start time for different snippets when using larger data sets about audfprint HOT 1 CLOSED

Most likely it's a time aliasing issue. In order to keep the database
small, the time offsets for each landmark are held in fixed-size integers;
by default, it's 14 bits (controlled by --maxtimesize 16384). Any time
offsets within tracks that exceed this value wrap back to the range
0..16383. This doesn't (much) affect the fingerprint comparison, since the
time differences are the same as long as both times being compared are
wrapped into the same interval. But it can drastically affect the absolute
times reported.

The units of the time differences are 256 sample frames, or 23 ms at 11 kHz
sampling, meaning that times larger than ~6 min will be aliased (your time
is smaller than this, maybe your sampling rate is higher?). In any case,
increasing --maxtimesize to 65536 should help (you'll have to recompute the
whole database). Using more bits for the timing information steals bits
from the item ID, so that will reduce the maximum number of reference items
to 65536 also; hopefully, this doesn't affect your application.

This has come up before, so I think it's correct to class it as a bug. I
guess the solution is to have some noisy warning when ingesting items whose
time duration causes a wrap of the timing info. It's only a problem when
reporting time ranges, but the program shouldn't be reporting flat-out
wrong times without warning.

DAn.

On Wed, Jan 20, 2016 at 10:34 AM, eamonnkenny [email protected]
wrote:

Actually turns out that the first set of start times are correct, but its
only the penultimate and ultimate values that are always the same even
though they should be different. The last value show have a start time of
3.5 secs instead of 275.7 secs. I tried running it with ncores=1 to see if
it was some sort of multithreading issue but I still obtain the same
results.

—
Reply to this email directly or view it on GitHub
#17 (comment).

from audfprint.