Contact

How to Reach Us

The contact route on this page is the single entry point for everything that is not a tool: bug reports, feature requests, privacy questions, press inquiries and general feedback about the BPM key finder, the bpm finder, the key finder, the tempo finder, tap tempo, the online metronome and the bpm calculator. During the rollout phase the support mailbox is being published step by step together with the public launch — this page is updated the moment the address goes live, and every request that arrives through the official channels is answered by the small team that also builds the analysis engine behind the tools.

Because every tool on this site runs locally in your browser, there are no user accounts, no upload queues and no server-side logs of your audio. That architecture shapes what we can and cannot see when you report a problem, and it is the reason the sections below ask for a few specific details. A precise report usually leads to a fix within days; a vague one usually leads to a round of questions that costs both sides a week.

What to Include in Your Message

A useful message answers three questions in the first two sentences: what you did, what you expected, and what happened instead. Name the tool you were using — the bpm finder and the bpm calculator behave very differently, and requests that say only "the tool does not work" have to be sorted by hand before anyone can start. Then add the environment: your browser and its version, your operating system, and whether you were on a phone, a tablet or a desktop machine.

If your report involves an audio file, describe the file instead of attaching it: the format (MP3, WAV, M4A, FLAC or OGG), the approximate length, the musical style if you know it, and whether the track is a studio release, a live recording or a self-produced bounce. Files never need to be sent, because the detection runs on your device — the description alone is usually enough to reconstruct the case in our test bench. Finally, tell us the result you saw, including the BPM value and the confidence label if the tool displayed them.

Bug Reports

Bugs in a signal-processing tool come in three families, and naming the family speeds everything up. Detection bugs are wrong results: a bpm finder reading half the true tempo, a key finder reporting the relative key instead of the main key, or a confidence label that contradicts what you hear. Playback bugs involve the online metronome or tap tempo: clicks that drift, a tap sequence that resets too early, or audio that refuses to start until a second click. Interface bugs are visual: overlapping numbers on a narrow screen, a slider that jumps, or a German sentence that still shows English words.

For detection bugs, one comparison helps more than any description: if another tool or the track's official metadata gives a different BPM or key, include that reference value. Disagreements between honest tools are the most valuable reports we receive, because each one either sharpens the detector or documents a known limit. For playback bugs, mention whether other audio on the same device plays normally — that single fact separates browser audio policies from actual defects.

Feature Requests

Feature requests are welcome and read with care. The roadmap of this site follows a simple priority order: accuracy first, speed second, surface third. Requests that make an existing reading more trustworthy — better half-time handling in the bpm finder, sharper chroma matching in the key finder, steadier timing in the online metronome — always jump the queue. Requests for new export formats, playlist integrations or batch analysis are collected and scheduled around that core work.

When you propose a feature, describe the situation you are in rather than the button you want. "I sort records for a monthly radio show and need the Camelot code of forty tracks next to each other" tells us more than "add a table view". The first formulation can be served in several ways, some of them cheaper and better than the obvious one; the second can only be answered with yes or no. Include how often the situation occurs — weekly workflows beat one-off needs.

Privacy and Data Requests

All analysis on this site happens in your browser: audio files are decoded on your device, measured on your device and discarded when you load the next track. Nothing is uploaded, cached server-side or shared with third parties, which is why the privacy policy is short. Nevertheless, legal requests are honored in full. You can ask what data, if any, exists about your visit, request deletion of anything stored, object to processing, or request a machine-readable export of data covered by your rights.

For a privacy request, include the approximate date of your visit and the page you were on. Because there is no account system and no login, requests are matched by context rather than by user ID. The privacy policy page explains the technical background in plain language, including which cookies the locale selector and the theme switch use and why anonymous, aggregated statistics may be collected. Questions that the policy does not answer clearly enough are treated as documentation bugs — telling us about them improves the page for everyone.

Press and Partnerships

Editorial teams, educators and conference organizers are welcome to ask about the project: how the detection engine works, why every tool runs locally, what the accuracy benchmarks look like against reference tracks, and where the line between signal processing and machine learning sits in this particular implementation. Interviews, screenshots and test accounts are provided free of charge; the only thing we ask is that screenshots keep the tool interface intact so readers see real numbers rather than mock data.

Partnership proposals should state the audience and the use case in the first paragraph. Licensing the analysis engine for embedding, integrating the tools into teaching platforms, and translating the interface into additional languages are the three collaborations that have worked best so far. Proposals are answered within a week, even when the answer is a no with reasons.

Response Times

Requests are read daily on working days and answered in the order they arrive, with one exception: reports that a tool produces a wrong BPM or a wrong key on a specific track are triaged immediately, because accuracy is the product. Most bug reports receive a first answer within two working days, feature requests within a week, and privacy requests within the statutory time frames. If a request needs longer, you receive a short interim note instead of silence — a principle this project holds itself to.

Contact FAQ

Can I send you my audio file? There is no need to. The tools analyze audio locally on your device, so a description of the track — format, length, style, result — is enough to reproduce most cases on our own test material.

Do you answer in German? Yes. The site is bilingual by design, and requests in German and English are answered in the language they arrive in.

Who maintains the tools? A small independent team that also wrote the analysis engine. There is no call center and no ticket bot; the people who read your message are the people who can change the code.

I found a wrong BPM on a famous track — is that a bug? Sometimes. Reference values in databases are themselves estimates. Send the track name, your result and the reference; disagreements go straight into the benchmark bench either way.

Can I request a new tool? Yes, and the bar is lower than you think. The tempo finder and the bpm calculator both started as one-paragraph user requests that fit the existing engine.

How do I report a translation error? Like any other bug: name the page, quote the sentence, and if you can, suggest the correction. German and English copy are maintained in parallel, and slips happen in both.

Is there a newsletter or a status page? Not yet. Announcements appear on the about page, and major engine changes are noted there with a date so you can see how fresh your results are.