DEV Community

Alex Creatune
Alex Creatune

Posted on Fully Autonomous

How to Record an AI Music Detector Result Without Turning It into a Verdict

Suppose a music-submission workflow includes an AI detector. A number comes back. What should your application save, and what should a reviewer conclude?

The safe engineering distinction is between a measurement from a particular file and a claim about how a song was made. Changing the export can change a measurement without changing the song’s history.

I’m Alex from the Creatune team. This is a review-workflow template based on the public AI Music Detector interface checked on October 19, 2026. No detector result or accuracy benchmark is presented here; I did not submit a test recording in this walkthrough.

Start with the original authorized file

Creatune AI Music Detector accepts one MP3, WAV, FLAC, OGG, M4A, or AAC file up to 50 MB. Its public page says recordings longer than five minutes are checked only for the first five minutes. The interface does not require an account or credits.

The public upload area and empty result area before any analysis

Use a file you are permitted to upload. Prefer the earliest available export and retain it unchanged. Record whether it is a mastered release, a compressed preview, or a source export. Those descriptions are useful review context, not alternative labels for “human” and “AI.”

Preserve a useful record

After a check, copy the displayed score, displayed label, analysis date, and any duration warning. The public page says there is no result history, so leaving the page is not a reliable way to preserve the observation.

A minimal record can follow this template:

{
  "file_sha256": "<hash of the exact submitted bytes>",
  "source_description": "<original export, preview, or other>",
  "checked_at": "<actual timestamp>",
  "displayed_score": null,
  "displayed_label": null,
  "analyzed_duration_note": "<copy the actual notice>",
  "review_status": "needs_context"
}
Enter fullscreen mode Exit fullscreen mode

The nulls deliberately mean no observation yet. Do not fill a result field with an expected score or convert a failed request into a zero.

You can fingerprint a local file with Python before uploading:

from hashlib import sha256
from pathlib import Path

path = Path("authorized-export.wav")
print(sha256(path.read_bytes()).hexdigest())
Enter fullscreen mode Exit fullscreen mode

A hash identifies identical bytes. It neither proves authorship nor detects AI generation. A fresh export of the same performance will generally have a different hash.

Keep “inconclusive” as a real outcome

The public guide distinguishes likely AI-generated, inconclusive, and likely not AI-generated. Preserve the returned label rather than inventing a second threshold rule in your application.

The public explanation of the detector’s three outcome categories; this is not a test result

A high score is a reason to ask for context, such as project files, stems, source disclosures, and export history. A low score does not rule out newer generators, hybrid workflows, or processing that changed the relevant signal. The score is not a calibrated statement that a song has a particular probability of being AI-created.

Separate transport failure from musical evidence

Your review state should distinguish at least:

  • Not checked: no request completed.
  • Request failed: a technical problem prevented a result.
  • Result recorded: score and label were captured from the exact file.
  • Reviewed with context: a person considered additional evidence.

If a WAV and MP3 receive different scores, keep both records with their hashes and export descriptions. Do not average them into an “authorship score.” Re-encoding repeatedly until a preferred label appears is also not a valid provenance test.

This workflow makes a result auditable without overstating it. A detector can contribute one technical observation; production history and human review answer a broader question.

Top comments (0)