wavbee Technologies

Release QC

Quality control that asks a question instead of sending a rejection.

Metadata, artwork and audio checked before delivery. Clean releases approved automatically with a full audit trail; ambiguous ones resolved with the uploader while they are still in the upload flow.

MetadataArtworkAudioContent match

One verdict

Five outcomes

The uploader is asked, mid-upload

Something is ambiguous rather than wrong: a featured artist in the title but not in the credits, a version tag that might be a remix, a language that does not match the lyrics. Instead of rejecting it, the run asks — in plain language, in the upload session, with the correction already written out and one click away.

Answer accepted → only the affected checks re-run. Unanswered → held, never failed.

Four of these outcomes exist in every distributor’s quality control. The third one is the reason artists stop resenting it.

A look inside

What it looks like when the checks ask instead of refuse.

Needs clarification · while you are still uploading

The title says “Slow Monsoon (feat. Osei)”, but Osei is not in the contributor list. Stores reject a feature that the credits do not carry — which is it?

release.title · release.contributors

Pick an answer. Both are valid releases — that is the point.

Neither answer was a rejection, and neither cost the artist a day. Answering re-runs only the checks the answer touched; leaving it unanswered holds the release rather than failing it.

Where each part standsLiveIn buildRoadmap

Metadata rule engine

In build

Deterministic rules run first and cost nothing. Titles, versions, casing, featuring conventions, explicit flags, language and script consistency, identifier validity — checked against a published catalogue rather than a reviewer's memory.

  • A 112-rule catalogue drawn from the store style guides that actually reject releases
  • The Apple Music Style Guide as the worldwide baseline, with per-store profiles on top
  • Per-account overrides — your standards can be stricter than the baseline, never looser than the store's
  • Severity per rule, so a warning does not block what a failure should
  • Deterministic checks run before anything expensive is called

Artwork inspection

In build

Resolution and format are the easy half. The half that gets releases rejected is the content — social handles, store logos, URLs, explicit imagery, a face that belongs to somebody else. Those need to be looked at.

  • Dimensions, colour space, format and compression against store specifications
  • Text and logo detection — URLs, social handles and store marks that stores reject
  • Explicit-content classification with a review path rather than an automatic refusal
  • Likeness and impersonation signals routed to a human
  • Every verdict carries the evidence that produced it

Audio defect analysis

In build

One analysis pass over the master produces every measurement the checks need. The defects that get a release taken down after delivery are exactly the ones that are cheap to catch before it.

  • Leading and trailing silence measured against a published threshold
  • Clipping, true-peak and integrated loudness
  • Dropouts, digital silence mid-track and channel anomalies
  • Fake hi-res detection — spectral analysis against the declared sample rate
  • Browser-side pre-checks so the obvious problems never reach the queue

Content matching

In build

The checks that protect you from delivering something you do not have the right to deliver. Matching runs asynchronously and returns as an addendum, so it never holds up the fast verdict on a clean release.

  • Content identification against commercial reference databases
  • Cover and sample detection, reported honestly as a signal rather than a conviction
  • AI-generated-music detection
  • Artist impersonation checks against the claimed profile
  • Asynchronous — the fast verdict lands first, the matching addendum follows

Clarification loop

In build

The difference between quality control and rejection. When something is ambiguous rather than wrong, the run asks — in the upload session, in plain language, with a proposed correction the uploader can accept in one click.

  • Questions raised during the upload, not in a rejection email three days later
  • Each question carries a proposed patch to the metadata
  • Accepting a patch re-runs only the checks it affects
  • Unanswered questions hold the release rather than failing it
  • Every question and answer is part of the release's permanent record

Verdicts & audit trail

In build

A verdict is a decision with its reasoning attached. Clean releases are approved automatically with the full evidence recorded; everything else routes to the right queue, so human review is spent on the cases that need a human.

  • Five outcomes: pass, pass with warnings, needs clarification, manual review, fail
  • Per-rule evidence rows — what was checked, what was found, what it cost
  • Automatic approval for clean releases, with the audit trail to defend it later
  • Manual review routed by reason, not dumped in one queue
  • A published turnaround target for the fast lane

QC as an API

Roadmap

Quality control is useful to every distributor, not only to the one that owns the catalogue. The engine is being built as a standalone service from the first commit so it can be consumed over an API by platforms that will never use anything else here.

  • REST submission with idempotency keys and retrying signed webhooks
  • DDEX input accepted alongside a native payload
  • A sandbox that returns realistic verdicts without consuming metering
  • Per-tenant rule profiles and thresholds
  • Metered per release, with the cost ledger visible to the tenant

Embeddable release builder

Roadmap

The builder as a component another platform can embed — their branding, their session, their users, with the checks and the clarification loop running live as the release is assembled.

  • Embeddable component with short-lived session tokens
  • Checks run live as fields are filled, not on submit
  • The clarification loop rendered inside the host product
  • Uploads go directly to storage from the visitor's browser
  • Host-controlled styling

Audio intelligence

Roadmap

The analysis that powers the defect checks also describes the music. Exposed to artists and labels, that becomes a product of its own: what this track is, and how it sits against the catalogue around it.

  • BPM, key and scale
  • Danceability, energy and mood descriptors
  • Hook and chorus timestamps for clip selection
  • Comparative percentiles against a reference catalogue
  • Available to the artist, not only to the reviewer

Why the clarification loop is the product

Every distributor already has quality control; it is usually a person reading a spreadsheet and an email three days later saying no. The expensive part is not the checking, it is the round trip — the artist has moved on, the release date is closer, and the fix is a sentence long. Asking the question inside the upload session, with the correction already proposed, is what turns quality control from a cost centre into something artists do not resent.

Talk to us about release qc

There is no price list on this site and no self-serve sign-up for the platform. Tell us what you are running today and what you want to run it on, and we will tell you plainly whether this fits.

Talk to our team[email protected]

Every conversation starts here. There is no price list on this site — what this costs depends entirely on what you need it to do.