Preflight QC

Preflight QC ist eine Premium-Zusatzoption, die Ihnen professionelle Release-Qualitätskontrolle bietet. Reichen Sie ein Release ein, und Preflight QC analysiert es von Anfang bis Ende: Metadaten, Release-Daten, Audio, Artwork und Lizenznachweise. Sie erhalten einen klaren, umsetzbaren Qualitätsbericht. Beheben Sie in Ihrem eigenen Tempo, was er meldet, und bestätigen Sie das Release zur Prüfung, wenn Sie zufrieden sind.

Für Labels und API-Integratoren ist Preflight QC ein Baustein. Rufen Sie den Qualitätsbericht programmatisch ab, binden Sie ihn in Ihre eigene QA-Pipeline ein, machen Sie Ihren internen Freigabeprozess davon abhängig und bestätigen Sie Releases automatisch zur Prüfung. Ihr Team setzt die Qualitätslatte, Preflight QC übernimmt die Analyse.

Ein Release, das sauber ankommt, kommt schnell durch die Prüfung. Preflight QC bringt Sie dorthin, bevor Sie einreichen.

Was Preflight QC ist

Mit aktiviertem Preflight QC gelangt ein zum Vertrieb eingereichtes Release nicht direkt in die Prüfwarteschlange. Stattdessen kommt es in eine Wartephase vor der Prüfung („wartet auf Ihre Prüfung”), während Preflight QC seine Qualitätsanalyse durchführt: Metadaten, Release-Daten, Audio, Artwork und Lizenznachweise. Das Ergebnis ist ein Qualitätsbericht, und was Sie darauf aufbauen, liegt bei Ihnen:

• Ihr eigener QA-Workflow (API). Lassen Sie Ihren Katalog durch die Qualitätsanalyse laufen, rufen Sie den Bericht programmatisch in Ihrer eigenen QA-Pipeline ab, machen Sie Ihren internen Freigabeprozess von den Ergebnissen abhängig und bestätigen Sie jedes Release erst dann zur Prüfung, wenn es Ihre Messlatte nimmt. Siehe Die API nutzen für Integrationen.
• Der Ablauf in der App. Lesen Sie den Bericht auf der Release-Seite, beheben Sie, was er meldet, und bestätigen Sie, wenn Sie zufrieden sind.

In beiden Fällen ist es die Bestätigung, die das Release in die normale Prüfwarteschlange verschiebt: Nichts geht in die Prüfung, bevor Sie grünes Licht geben.

Preflight QC fügt vor der Prüfung eine Qualitätsstufe hinzu. Es ändert nichts an dem, was danach passiert: Sobald Sie bestätigen, durchläuft Ihr Release denselben Validierungs- und Prüfprozess wie jedes andere Release.

So erhalten Sie Preflight QC

Preflight QC ist eine Premium-Zusatzoption, die unser Team pro Konto aktiviert. Um sie für Ihr Konto einzuschalten, kontaktieren Sie unser Vertriebsteam und teilen Sie mit, dass Sie Preflight QC möchten.

Sobald es aktiviert ist, sehen Sie den neuen Warte- und Bestätigungsschritt, wenn Sie das nächste Mal ein Release zum Vertrieb einreichen.

Der Ablauf von Preflight QC

Hier ist der vollständige Weg eines Releases mit aktiviertem Preflight QC, vom Einreichen bis zur Prüfung.

1. Reichen Sie Ihr Release zum Vertrieb ein

Erstellen und vervollständigen Sie Ihr Release wie gewohnt und reichen Sie es dann zum Vertrieb ein. Mit aktiviertem Preflight QC stellt das Release nicht sofort in die Prüfwarteschlange. Stattdessen wechselt das Release in eine Wartephase vor der Prüfung und wird als wartet auf Ihre Prüfung markiert.

2. Die Qualitätsanalyse läuft

Während sich Ihr Release in der Wartephase befindet, analysiert Preflight QC es von Anfang bis Ende. Die Analyse umfasst:

• Metadaten: Titel, Interpreten, Credits und andere Angaben zum Release und zu den Tracks
• Release-Daten: Ihre Datumseinstellungen und Release-Versionen
• Audio: die von Ihnen hochgeladenen Audiodateien
• Artwork: Ihr Coverbild
• Lizenzen: wenn eine Coverversion, ein Sample oder Ähnliches einen Nachweis benötigt

Die Analyse ist in der Regel wenige Minuten nach Abschluss von Upload und Transkodierung fertig. Solange sie noch läuft, zeigt der Qualitätsbericht an, dass die Prüfungen in Bearbeitung sind, und listet noch keine Probleme auf.

3. Lesen Sie Ihren Qualitätsbericht

Sobald die Analyse abgeschlossen ist, öffnen Sie den Qualitätsbericht des Releases, um zu sehen, was Ihre Aufmerksamkeit erfordert, falls überhaupt etwas. Sie können ihn an zwei Stellen lesen:

• Über die öffentliche API, für Ihre eigene QA-Pipeline; siehe Die API nutzen weiter unten.
• In der App, auf der Release-Seite.

Der Bericht listet jedes Problem mit einem klaren Titel und einer Nachricht auf, die beschreibt, was zu beheben ist. Siehe Den Qualitätsbericht verstehen, um die Felder zu lesen.

4. Beheben Sie, was gemeldet wird

Arbeiten Sie die Probleme in Ihrem Bericht durch:

• Metadaten-Probleme: Bearbeiten Sie die Angaben zum Release oder Track.
• Audio- oder Artwork-Probleme: Ersetzen Sie die betroffene Datei.
• Probleme, die eine Rückmeldung erfordern: Antworten Sie im Notizen-Thread des Problems oder laden Sie das angeforderte Dokument hoch (zum Beispiel eine Lizenz für eine Coverversion oder ein Sample).

Wenn Sie Ihr Release während der Wartephase bearbeiten, werden die betreffenden Teile der Analyse erneut ausgeführt, und der Bericht aktualisiert sich mit den neuen Ergebnissen. Sie können diesen Kreislauf so oft durchlaufen, wie Sie möchten.

5. Bestätigen Sie das Release

Wenn Ihr Bericht sauber ist, oder Sie alles Nötige erledigt haben, bestätigen Sie das Release. In der App ist das eine Bestätigen-Schaltfläche auf dem Release; für Integrationen ist es der Bestätigungs-Endpunkt.

Die Bestätigung nimmt das Release aus der Wartephase und verschiebt es in die normale Prüfwarteschlange. Für die Bestätigung muss die Analyse abgeschlossen sein: Wenn Sie das Release nach dem letzten Lauf bearbeitet haben, warten Sie den aktualisierten Bericht ab, bevor Sie bestätigen.

6. Normale Prüfung

Nach der Bestätigung wird Ihr Release genau wie jedes andere geprüft. Was während der Prüfung passiert, wie lange sie dauert und welche Ergebnisse möglich sind, erfahren Sie unter Validierung und Prüfung.

Den Qualitätsbericht verstehen

Der Qualitätsbericht hat zwei Teile: eine Liste von Problemen und einen kleinen Block mit Bericht-Details zum Analyselauf selbst.

Probleme

Jedes Problem im Bericht beschreibt einen Punkt zum Ansehen. Die Felder, mit denen Sie arbeiten:

Feld	Was es Ihnen sagt
Titel	Ein kurzer, verständlicher Name für das Problem.
Nachricht	Worum es sich handelt und was zu tun ist.
Schweregrad	Wie wichtig das Problem ist, um Ihnen die Priorisierung zu erleichtern.
Blockierend	Ob das Problem gelöst sein muss, bevor Sie bestätigen können (siehe unten).
Erfordert Rückmeldung	Ob das Problem eine schriftliche Antwort oder ein hochgeladenes Dokument von Ihnen benötigt.
Benutzerdefinierte Beschreibung	Zusätzliche, für Ihr Release spezifische Details, sofern verfügbar.
Betroffene Tracks	Auf welche Tracks sich das Problem bezieht. Probleme auf Release-Ebene nennen keine bestimmten Tracks.

Blockierend oder informativ

• Blockierende Probleme müssen gelöst sein, bevor Sie das Release zur Prüfung bestätigen können. Beheben Sie, was sie beschreiben, lassen Sie die Analyse erneut laufen, und sie verschwinden aus Ihrem Bericht.
• Informative Probleme weisen auf etwas hin, das einen Blick wert ist, hindern Sie aber nicht am Bestätigen. Sehen Sie sie sich an und bestätigen Sie, wenn Sie bereit sind.

Probleme, die eine Rückmeldung erfordern

Manche Probleme lassen sich nicht allein durch Bearbeiten lösen: Sie brauchen etwas von Ihnen, etwa eine schriftliche Erläuterung oder einen Nachweis (zum Beispiel eine Lizenz für eine Coverversion oder ein Sample). Diese sind als erfordert Rückmeldung markiert. Um ein solches Problem zu lösen, antworten Sie im Notizen-Thread des Problems oder laden Sie das angeforderte Dokument hoch, bevor Sie bestätigen.

Die Bericht-Details

Neben den Problemen enthält der Bericht einige Details zum Analyselauf:

Feld	Was es Ihnen sagt
generated_at	Wann der aktuelle Bericht erstellt wurde. Leer, solange die erste Analyse noch läuft.
checks_in_progress	true, solange die Analyse noch läuft; die Problemliste bleibt leer, bis sie abgeschlossen ist.
hold	Ob sich das Release derzeit in der Wartephase vor der Prüfung befindet.
review_status	Der aktuelle Prüfstatus des Releases.
profile	Das auf dieses Release angewendete Qualitätsprofil.

Die API nutzen (für Integrationen)

Wenn Sie auf der öffentlichen LabelGrid-API aufbauen, können Sie Preflight QC in Ihre eigene Pipeline einbinden: Lassen Sie jedes Release durch die Qualitätsanalyse laufen, holen Sie den Bericht in Ihren eigenen QA-Workflow, machen Sie Ihren internen Freigabeprozess davon abhängig und bestätigen Sie zur Prüfung aus Ihrem eigenen Tooling heraus. Dafür stellt Preflight QC zwei Endpunkte bereit; beide verwenden dieselbe Bearer-Token-Authentifizierung wie der Rest der öffentlichen API. Die vollständigen und stets aktuellen Anfrage- und Antwortschemata finden Sie in der API-Referenz.

Den Qualitätsbericht abrufen

GET /v4/public/veroeffentlichungen/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

Gibt den aktuellen Qualitätsbericht des Releases zurück. Die Antwort enthält:

• issues[]: ein Eintrag pro Problem, jeweils mit code (ein stabiler String; siehe Mit den Problemcodes arbeiten), title, message, severity, is_blocking, requires_feedback, custom_description und affected_tracks.
• report: generated_at, checks_in_progress, hold, review_status und profile.

Solange die Analyse noch läuft, gibt der Bericht checks_in_progress: true mit einer leeren issues-Liste zurück. Fragen Sie den Endpunkt wiederholt ab, bis generated_at gesetzt ist, in der Regel wenige Minuten nach Abschluss von Upload und Transkodierung, und lesen Sie dann die Probleme.

Eine Beispielantwort nach abgeschlossener Analyse:

{
  "issues": [
    {
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "hold": true,
    "review_status": "…",
    "profile": "…"
  }
}

Das Release zur Prüfung bestätigen

POST /v4/public/veroeffentlichungen/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

Nimmt das Release aus der Wartephase und verschiebt es in die normale Prüfwarteschlange: das API-Äquivalent der Bestätigen-Schaltfläche in der App.

Für die Bestätigung muss die Analyse abgeschlossen sein. Wenn das Release nach dem letzten Analyselauf bearbeitet wurde, wird der Bericht gerade neu erstellt, und der Endpunkt gibt einen Konflikt zurück. Rufen Sie in diesem Fall den Qualitätsbericht erneut ab, warten Sie, bis generated_at wieder gesetzt ist, und versuchen Sie die Bestätigung erneut.

Mit den Problemcodes arbeiten

Wenn Sie Logik auf dem Qualitätsbericht aufbauen, stützen Sie sie auf den code des Problems:

• code ist ein stabiler String im Slug-Format (zum Beispiel audio.trailing-silence). Sie können Codes gefahrlos in Ihrem System abbilden und Logik darauf aufbauen.
• Titel und Nachrichten sind Texte für Menschen. Sie können mit der Zeit überarbeitet werden; stützen Sie Ihre Logik nie auf den Text, sondern nutzen Sie ihn nur zur Anzeige.
• Neue Codes können hinzukommen, wenn die Abdeckung von Preflight QC erweitert wird. Behandeln Sie unbekannte Codes generisch: Zeigen Sie title und message aus der Antwort an, statt einen Fehler auszulösen.
• Ihre Berichte zeigen Ihnen die Codes, die zählen. Während Sie Releases durch Preflight QC laufen lassen, tauchen die für Ihren Katalog relevanten Codes ganz natürlich in Ihren eigenen Qualitätsberichten auf.
• Was die Analyse abdeckt. Die Probleme fallen in diese Kategorien: Release- und Track-Metadaten, Release-Daten und -Versionen, Audioqualität, Artwork sowie Lizenzen und Nachweise.

Der Problemkatalog

Um die Probleme beim Aufbau Ihres eigenen QA-Workflows zu mappen, rufen Sie den vollständigen Katalog programmatisch ab:

GET /v4/public/issue-definitions
Authorization: Bearer YOUR_API_TOKEN

Er liefert jedes Problem, das in einem Qualitätsbericht auftauchen kann, indiziert nach seinem stabilen String-Code, mit Titel, Nachrichtenvorlage, Schweregrad, Blockierend-Kennzeichen und requires_feedback. Der Endpunkt steht nur Konten mit der Preflight-QC-Zusatzoption zur Verfügung.

Häufige Fragen

Was, wenn die Analyse noch läuft?

Der Bericht zeigt checks_in_progress: true an, ohne dass bereits Probleme aufgeführt sind. Das ist direkt nach dem Einreichen normal. Warten Sie einige Minuten nach Abschluss von Upload und Transkodierung und sehen Sie dann erneut nach: In der App aktualisiert sich der Bericht von selbst, und über die API können Sie ihn wiederholt abfragen, bis generated_at gesetzt ist.

Kann ich mein Release während der Wartephase bearbeiten?

Ja. Wenn Sie ein Release in der Wartephase vor der Prüfung bearbeiten, werden die betreffenden Teile der Analyse erneut ausgeführt und der Bericht aktualisiert; Sie können Probleme also beheben und die aktualisierten Ergebnisse sehen, ohne die Wartephase zu verlassen. Denken Sie nur daran, dass Sie nach einer Bearbeitung den aktualisierten Bericht abwarten müssen, bevor Sie bestätigen können.

Was passiert, nachdem ich bestätigt habe?

Ihr Release verlässt die Wartephase und reiht sich in die normale Prüfwarteschlange ein, wo es wie jedes andere geprüft wird. Siehe Validierung und Prüfung dazu, wie die Prüfung abläuft, wie lange sie dauert und welche Ergebnisse möglich sind.

Kann ich ein Release wieder in den Entwurf zurücksetzen?

Ja: Solange sich Ihr Release in der Wartephase vor der Prüfung befindet und Sie es noch nicht bestätigt haben, ist es nicht in die Prüfung gelangt. Sie können es also weiter bearbeiten oder als Entwurf liegen lassen und später zurückkehren. Es gelangt erst in die Prüfwarteschlange, wenn Sie es bestätigen.

Muss ich jedes Problem beheben, bevor ich bestätige?

Sie müssen blockierende Probleme beheben, bevor Sie bestätigen können. Informative Probleme hindern Sie nicht am Bestätigen, sind aber einen Blick wert: So viel wie möglich vor der Prüfung zu bereinigen, ist der schnellste Weg zur Freigabe.

---

Fragen zu Preflight QC? Kontaktieren Sie unser Team. Wir helfen Ihnen gern.