Tatsh / smlab / 32615134396

100%

push

github

warp: fit one unbroken line, draw the grid over the audio, and say what is left

The tempi were read off stretches fitted independently, and that is wrong in a
way that made warping worse than not warping. Independent lines each pick their
own starting height, so every boundary silently carries a jump in phase, and a
tempo cannot jump. Reconstructing the grid from the tempi that were written out
therefore drifted away from the phase they were fitted to: on Feinak, 234 ms by
the end of the song, against a song whose beat actually returns to where it
started. Fitting one line that bends at those boundaries makes the fitted phase
and the phase the chart will have the same object, and the same song now lands
within 43 ms throughout with three sane segments instead of four wrong ones.

Reweighting that fit towards the furthest-out measurements, to chase the
smallest worst miss rather than the smallest total one, was implemented and
measured and made every case worse, so it is not here. What is left is reported
instead: a grid that still misses by more than the tolerance says the beat moves
in ways no tempo describes, which is worth knowing before placing warps.

Edits spliced into the audio are now called out during tempo detection, not only
when warping, because they say the grid is unreliable there and no warp will
repair it. Everything warp-related says it is experimental.

drift --image writes the whole song in eight second rows with the grid drawn
over the waveform: bars full height and numbered, beats ticked, and the audio
coloured by how much low end it carries so kicks stand out against the lines.
--offset places the grid where beat zero really is, which is worth supplying,
because the automatic answer comes from an onset envelope and an envelope peaks
after the attack rather than on it. This is what found the bug above.

warp becomes a package so the drawing sits beside the measuring, as chart and
writer already do.

Signed-off-by: Andrew Udvare <... (continued)

766 of 796 branches covered (96.23%)

Branch coverage included in aggregate %.

114 of 184 new or added lines in 4 files covered. (61.96%)

3745 of 3818 relevant lines covered (98.09%)

2.94 hits per line