Определитель BPM
Бросьте трек. Получите темп и точное время каждой доли — посчитано на вашей машине, без загрузки куда-либо.
Файл читает и перекодирует ваш собственный браузер. Ни один запрос никуда его не отправляет — у этой страницы просто нет сервера, куда его загружать.
Вопросы
Мой звук куда-то загружается?
Нет. Анализ выполняется внутри браузера как WebAssembly. Файл читается с диска в память и никогда не уходит по сети — это можно проверить, открыв вкладку сети или отключив интернет после загрузки страницы.
Насколько это точно?
Используется анализ силы атак с отслеживанием долей методом динамического программирования — тот же подход, что в устоявшихся инструментах music information retrieval, и тот же код, что движет монтажным движком Life2Film. На музыке с ровным пульсом попадание в пределах доли. На рубато, живых записях без клика и сильно синкопированном материале считайте результат отправной точкой.
Что значит «половинный или двойной темп»?
Темп двусмыслен по своей природе: трек на 140 BPM — это одновременно и корректные 70 BPM в половинном счёте. Детекторы выбирают то, что сильнее в сигнале. Если число ощущается ровно вдвое не тем, произошло именно это, и обе трактовки показаны, чтобы вы взяли нужную.
Можно использовать доли в монтажной программе?
Ради этого экспорт и сделан. EDL — то, что нужно для DaVinci Resolve или Premiere: каждая доля приходит именованным маркером на таймлайн. Final Cut принимает FCPXML. OTIO работает и в Resolve, и в Avid, и в Premiere, и подходит, если доли идут в пайплайн, а не прямо на таймлайн. Audacity читает экспорт меток, а CSV и JSON закрывают таблицы и скрипты.
Почему важна частота кадров?
Доли попадают на доли секунды, а таймлайн считает целые кадры. Каждый маркер округляется к ближайшему кадру того проекта, куда он идёт, поэтому сетка, экспортированная в 25 fps, окажется до 20 мс мимо в тридцатикадровой секвенции. Поставьте частоту своего проекта — и маркеры лягут ровно туда, где доля. На CSV и JSON это не влияет: там есть и сырые секунды.
Другие инструменты
Build this into your own project
Finding the tempo and beat grid of a track — the same way this page does it, on the user's machine, with no server. Take the code, or hand the prompt to a coding agent.
const engine = await import('https://life2film.com/wasm/va_wasm.js');
await engine.default({ module_or_path: 'https://life2film.com/wasm/va_wasm_bg.wasm' });
const ctx = new AudioContext();
const buffer = await ctx.decodeAudioData(await file.arrayBuffer());
// Down-mix to mono at 22050 Hz first (OfflineAudioContext), then:
const { bpm, beats } = JSON.parse(engine.detect_beats(mono, 22050, null)); Add beat detection to my project. It must run in the browser with no upload and no API key.
Requirements:
- Use the "life2film-engine" npm package (WebAssembly). detect_beats takes mono f32 PCM, which is
exactly what AudioContext.decodeAudioData gives you.
- Down-mix to mono at 22050 Hz with an OfflineAudioContext before analysing. The onset envelope lives
far below that, so the source rate costs several times the memory and time for an identical answer.
- Tempo is genuinely ambiguous: 140 BPM is also 70 in half time. Show both readings rather than
treating a 2x difference as an error.
- Draw the beats over a waveform so the user can check them, but show a WINDOW of a few seconds, not
the whole track — 400 beats across 1000 pixels is a solid block that proves nothing.
- Let the user play the track with a click on every beat. It is the fastest way to verify a grid.
- Export the grid for editors: EDL for Resolve and Premiere, FCPXML for Final Cut, OTIO for
pipelines, Audacity labels, CSV, JSON. Markers land on whole frames, so ask for the project frame
rate — a grid at 25 fps sits up to 20 ms off in a 30 fps sequence.
Reference implementation: https://life2film.com/tools/bpm-detector/
The engine is documented for agents, and every tool page is available as
markdown by adding .md to its address.