Repository navigation
Server tempo: Mixxx's beat tracker instead of the envelope estimator - #116
Merged
Merged
Conversation
Deezer publishes no bpm for nearly all of a hard-dance library (2 of 3 462 files here), so the envelope estimator was what every track got: rounded to a whole BPM and often 2-4 off (154 for 150), the wrong octave on half the non-club records — and the player now locks to it. deezer/beats.py ports Mixxx's default analyser to numpy: qm-dsp's complex spectral difference onsets and TempoTrackV2 (comb filter bank + Viterbi for the period, dynamic programming for the beats), then Mixxx's BeatUtils constant-tempo pass and rounding (GPL-2.0-or-later, credited). On top: hardcore tracked at half is doubled when the half beats strike as hard as the beats (kick band and whole spectrum, 0.85-1.3); no tempo without attacks and on-beat salience; Deezer's figure only witnesses the octave. tools/tempo_eval.py: 17/26 within 3.5% -> 23/26 exact, 26/26 with Deezer as witness, 0 phantoms. ~0.4 s and ~100 MB a track. ANALYSIS_VERSION 5, and a stale library is re-measured on boot (webui/analysis.reanalyse_if_stale). Without numpy the envelope estimator still answers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
||
| import logging | ||
| import math | ||
| import subprocess |
| "ffmpeg", "-v", "error", "-nostdin", "-t", str(seconds), "-i", path, | ||
| "-vn", "-ac", "1", "-ar", str(SR), "-f", "f32le", "-", | ||
| ] | ||
| proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) |
Comment on lines
+271
to
+272
| except Exception: | ||
| pass |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deezer publishes no bpm for nearly all of a hard-dance library (2 of 3 462 files here), so the envelope estimator was what every track got: rounded to a whole BPM and often 2-4 off (154 for 150), the wrong octave on half the non-club records — and the player now locks to it.
deezer/beats.py ports Mixxx's default analyser to numpy: qm-dsp's complex spectral difference onsets and TempoTrackV2 (comb filter bank + Viterbi for the period, dynamic programming for the beats), then Mixxx's BeatUtils constant-tempo pass and rounding (GPL-2.0-or-later, credited). On top: hardcore tracked at half is doubled when the half beats strike as hard as the beats (kick band and whole spectrum, 0.85-1.3); no tempo without attacks and on-beat salience; Deezer's figure only witnesses the octave.
tools/tempo_eval.py: 17/26 within 3.5% -> 23/26 exact, 26/26 with Deezer as witness, 0 phantoms. ~0.4 s and ~100 MB a track. ANALYSIS_VERSION 5, and a stale library is re-measured on boot (webui/analysis.reanalyse_if_stale). Without numpy the envelope estimator still answers.