Lewati ke konten
Dukungan

Preflight QC

Preflight QC adalah pengaya premium yang memberi Anda QC rilis profesional. Kirim sebuah rilis dan Preflight QC menganalisisnya dari awal sampai akhir: metadata, tanggal rilis, audio, artwork, konten AI, identifier katalog, distribusi sebelumnya, dan dokumentasi lisensi. Anda menerima laporan kualitas yang jelas dan dapat ditindaklanjuti. Perbaiki apa yang ditandainya sesuai ritme Anda sendiri, lalu konfirmasikan rilis ke tinjauan saat Anda puas.

Bagi label dan integrator API, Preflight QC berfungsi sebagai balok penyusun. Ambil laporan kualitas secara terprogram, sambungkan ke pipeline QA Anda sendiri, jadikan dasar proses persetujuan internal Anda, dan konfirmasikan rilis ke tinjauan secara otomatis. Tim Anda yang menetapkan standar kualitas, Preflight QC yang melakukan analisisnya.

Rilis yang tiba dalam keadaan bersih melewati tinjauan dengan cepat. Preflight QC membawa Anda ke sana sebelum Anda mengirim.

Dengan Preflight QC diaktifkan pada akun Anda, rilis yang dikirim untuk distribusi tidak langsung masuk ke antrean tinjauan. Sebagai gantinya, rilis masuk ke penahanan pra-tinjauan (“menunggu peninjauan Anda”) selagi Preflight QC menjalankan analisis kualitasnya: metadata, tanggal rilis, audio, artwork, konten AI, identifier katalog, distribusi sebelumnya, dan dokumentasi lisensi. Hasilnya adalah laporan kualitas, dan apa yang Anda bangun di atasnya terserah Anda:

  • Alur kerja QA Anda sendiri (API). Jalankan katalog Anda melalui analisis kualitas, ambil laporannya secara terprogram di pipeline QA Anda sendiri, jadikan hasilnya dasar proses persetujuan internal Anda, dan konfirmasikan setiap rilis ke tinjauan hanya setelah lolos standar Anda. Lihat Menggunakan API untuk integrasi.
  • Alur di aplikasi. Baca laporan di halaman rilis, perbaiki apa yang ditandainya, dan konfirmasi saat Anda puas.

Bagaimanapun caranya, konfirmasilah yang memindahkan rilis ke antrean tinjauan normal: tidak ada yang masuk tinjauan sebelum Anda memberi persetujuan.

Preflight QC menambahkan tahap kualitas sebelum tinjauan. Ia tidak mengubah apa yang terjadi setelahnya: begitu Anda mengonfirmasi, rilis Anda melalui proses validasi dan tinjauan yang sama seperti rilis lainnya.

Preflight QC adalah pengaya premium yang diaktifkan per akun oleh tim kami. Untuk mengaktifkannya pada akun Anda, hubungi tim penjualan kami dan beri tahu bahwa Anda menginginkan Preflight QC.

Setelah diaktifkan, Anda akan melihat langkah penahanan dan konfirmasi yang baru saat berikutnya Anda mengirim rilis untuk distribusi.

Berikut perjalanan lengkap sebuah rilis dengan Preflight QC diaktifkan, dari pengiriman hingga tinjauan.

Buat dan lengkapi rilis Anda seperti biasa, lalu kirim untuk distribusi. Dengan Preflight QC diaktifkan, ini tidak langsung menempatkan rilis ke antrean tinjauan. Sebaliknya, rilis berpindah ke penahanan pra-tinjauan dan ditandai sebagai menunggu peninjauan Anda.

Selagi rilis Anda ditahan, Preflight QC menganalisisnya dari awal sampai akhir. Analisisnya mencakup:

  • Metadata: judul, artis, kredit, serta detail rilis dan trek lainnya
  • Tanggal rilis: pengaturan tanggal dan versi rilis Anda
  • Audio: berkas audio yang Anda unggah
  • Artwork: gambar sampul Anda
  • Konten AI: apakah penggunaan AI dideklarasikan, serta musik atau sampul buatan AI yang kami deteksi
  • Identifier katalog: apakah ISRC Anda valid dan apakah sebuah rekaman sudah diklaim oleh pemilik hak lain
  • Distribusi sebelumnya: apakah rilis atau treknya sudah ada di toko melalui distributor lain
  • Lisensi: ketika sebuah cover, sampel (sample), atau yang serupa memerlukan dokumen pendukung

Analisis biasanya selesai beberapa menit setelah unggahan dan transcoding rampung. Selama masih berjalan, laporan kualitas menunjukkan bahwa pemeriksaan sedang berlangsung dan belum mencantumkan masalah apa pun.

Setelah analisis selesai, buka laporan kualitas rilis untuk melihat apa, jika ada, yang memerlukan perhatian Anda. Anda dapat membacanya di dua tempat:

  • Melalui API publik, untuk pipeline QA Anda sendiri; lihat Menggunakan API di bawah.
  • Di dalam aplikasi, pada halaman rilis.

Laporan mencantumkan setiap masalah dengan judul yang jelas dan pesan yang menjelaskan apa yang harus diperbaiki. Lihat Memahami laporan kualitas untuk cara membaca kolom-kolomnya.

Telusuri masalah pada laporan Anda:

  • Masalah metadata: sunting detail rilis atau trek.
  • Masalah audio atau artwork: ganti berkas yang terpengaruh.
  • Masalah yang meminta umpan balik: balas di utas catatan pada masalah tersebut, atau unggah dokumen yang diminta (misalnya, lisensi untuk sebuah cover atau sampel).

Menyunting rilis Anda selagi ditahan akan menandai laporan saat ini sebagai usang: temuannya tidak lagi mencerminkan keadaan terbaru rilis Anda. Sunting sepuasnya, lalu minta analisis baru, dari halaman rilis di aplikasi atau melalui endpoint penyegaran untuk integrasi. Analisis berjalan ulang dan laporan diperbarui dengan hasil yang baru. Anda dapat mengulangi siklus ini sebanyak yang Anda perlukan, dalam batas penggunaan wajar mengenai berapa banyak analisis baru yang dapat Anda mulai per rilis per jam.

Ketika laporan Anda bersih, atau Anda telah menangani semua yang perlu, konfirmasi rilis. Di aplikasi, ini adalah tombol konfirmasi pada rilis; untuk integrasi, ini adalah endpoint konfirmasi.

Konfirmasi mengeluarkan rilis dari penahanan dan memindahkannya ke antrean tinjauan normal. Konfirmasi mengharuskan analisis yang selesai dan terkini: jika Anda menyunting rilis setelah proses terakhir, laporan menjadi usang, jadi minta analisis baru dan biarkan selesai sebelum mengonfirmasi.

Setelah konfirmasi, rilis Anda ditinjau persis seperti rilis lainnya. Untuk apa yang terjadi selama tinjauan, lama waktunya, dan hasil yang mungkin, lihat Validasi dan tinjauan.

Laporan kualitas memiliki dua bagian: sebuah daftar masalah dan sebuah blok kecil detail laporan tentang proses analisis itu sendiri.

Setiap masalah dalam laporan menjelaskan satu hal untuk dicermati. Kolom-kolom yang akan Anda kerjakan:

KolomApa yang diberitahukannya
JudulNama singkat dan mudah dipahami untuk masalah tersebut.
PesanApa masalahnya dan apa yang harus dilakukan.
Tingkat keparahanSeberapa penting masalah itu, untuk membantu Anda menetapkan prioritas.
MemblokirApakah masalah harus diselesaikan sebelum Anda dapat mengonfirmasi (lihat di bawah).
Memerlukan umpan balikApakah masalah membutuhkan jawaban tertulis atau dokumen yang Anda unggah.
Deskripsi khususDetail tambahan yang spesifik untuk rilis Anda, jika tersedia.
Trek yang terpengaruhTrek mana yang terkena masalah. Masalah tingkat rilis tidak mencantumkan trek tertentu.
BuktiPada masalah tanggal, duplikat, dan distribusi sebelumnya, rilis yang cocok yang kami temukan, sehingga Anda dapat memeriksa sendiri konfliknya (lihat di bawah).
  • Masalah yang memblokir harus diselesaikan sebelum Anda dapat mengonfirmasi rilis untuk tinjauan. Perbaiki apa yang dijelaskannya, jalankan analisis baru, dan masalah akan hilang dari laporan Anda.
  • Masalah informatif ada untuk menandai sesuatu yang layak dilihat, tetapi tidak menghentikan Anda untuk mengonfirmasi. Cermati, lalu konfirmasi saat Anda siap.

Sebagian masalah tidak dapat diselesaikan hanya dengan menyunting: masalah itu memerlukan sesuatu dari Anda, seperti penjelasan tertulis atau dokumen pendukung (misalnya, lisensi untuk sebuah cover atau sampel). Masalah ini ditandai sebagai memerlukan umpan balik. Untuk menyelesaikannya, balas di utas catatan pada masalah tersebut atau unggah dokumen yang diminta sebelum mengonfirmasi.

Sebagian masalah menyertakan bukti untuk membantu Anda memeriksa sebuah penanda tanpa menebak-nebak: rilis yang sudah ada yang kami cocokkan dengan rilis Anda. Anda akan melihatnya pada masalah tanggal, duplikat, dan distribusi sebelumnya. Setiap kecocokan menampilkan judul dan artis trek yang cocok, judul rilisnya, tanggal rilis, dan ISRC, ditambah tautan ke toko tempat rilis tersebut tayang, serta trek Anda yang mana yang terpengaruh. Paling banyak tiga kecocokan dicantumkan per trek. Gunakan bukti untuk memastikan apakah konfliknya nyata (misalnya, unggahan Anda sendiri yang lebih awal) sebelum Anda memutuskan cara merespons.

Di samping masalah, laporan menyertakan beberapa detail tentang proses analisis:

KolomApa yang diberitahukannya
generated_atKapan laporan saat ini dihasilkan. Kosong selama analisis pertama masih berjalan.
checks_in_progresstrue selama analisis masih berjalan; daftar masalah akan kosong hingga analisis selesai.
staletrue ketika Anda telah menyunting rilis (atau salah satu treknya) setelah analisis terakhir yang selesai, sehingga temuannya tidak lagi mencerminkan keadaan saat ini. Setiap suntingan dihitung. Minta analisis baru untuk memperbarui laporan.
holdApakah rilis saat ini berada dalam penahanan pra-tinjauan.
review_statusStatus tinjauan rilis saat ini.
release_statusStatus keseluruhan rilis itu sendiri, di samping status khusus tinjauan.
profileProfil kualitas yang diterapkan pada rilis ini, beserta nama dan versinya.

Jika Anda membangun di atas API publik LabelGrid, Anda dapat menyambungkan Preflight QC ke pipeline Anda sendiri: jalankan setiap rilis melalui analisis kualitas, ambil laporannya ke alur kerja QA Anda sendiri, jadikan dasar proses persetujuan internal Anda, dan konfirmasikan ke tinjauan dari perangkat Anda sendiri. Preflight QC menyediakan tiga endpoint untuk ini; ketiganya menggunakan autentikasi token Bearer yang sama seperti bagian lain dari API publik. Untuk skema permintaan dan respons yang lengkap dan selalu terkini, lihat referensi API.

Alih-alih melakukan polling untuk hasil, Anda dapat meminta LabelGrid memberi tahu Anda begitu sebuah laporan siap. Berlanggananlah ke event webhook release.preflight.report_ready: event ini terpicu begitu Preflight QC selesai menganalisis sebuah rilis dalam penahanan pra-tinjauan, termasuk setiap kali analisis ulang yang Anda minta selesai. Anda mendapatkan tepat satu event per siklus analisis.

Berlanggananlah dengan cara yang sama seperti Anda berlangganan event webhook rilis LabelGrid lainnya, dari pengaturan webhook Anda di aplikasi atau melalui API. Setiap event membawa ringkasan singkat dari proses tersebut, bukan masalahnya itu sendiri:

  • Pengidentifikasi rilis: release_id, label_id, release_cat, dan release_title.
  • generated_at: kapan laporan ini dihasilkan. Nilainya cocok dengan generated_at milik laporan itu sendiri.
  • profile: profil kualitas yang menjadi dasar penghitungan jumlah, sebagai {name, version}.
  • counts: total blocking, informational, dan requires_feedback. Jumlah requires_feedback tumpang-tindih dengan dua lainnya.

Gunakan jumlah tersebut untuk memutuskan apakah Anda perlu bertindak, lalu ambil laporannya sendiri untuk detailnya. Pola integrasi yang disarankan:

  1. Berlangganan ke release.preflight.report_ready.
  2. Pada setiap event, panggil Mengambil laporan kualitas untuk membaca seluruh rangkaian masalah.
  3. Perbaiki dan jalankan ulang: setelah menyunting rilis yang ditahan, panggil endpoint penyegaran untuk memulai analisis baru; webhook terpicu lagi ketika selesai.
  4. Putuskan dan konfirmasi dari perangkat Anda sendiri begitu rilis lolos standar Anda.

Untuk referensi payload lengkap dan mekanisme webhook (penandatanganan, percobaan ulang, dan amplopnya), lihat Webhooks.

GET /api/public/releases/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

Mengembalikan laporan kualitas rilis saat ini. Respons memuat:

  • issues[]: satu entri per masalah, masing-masing dengan id, code (string yang stabil; lihat Bekerja dengan kode masalah), title, message, status, severity, is_blocking, requires_feedback, custom_description, dan affected_tracks. Pada masalah tanggal, duplikat, dan distribusi sebelumnya, entri juga membawa array evidence (lihat di bawah).
  • report: generated_at, checks_in_progress, stale, hold, review_status, release_status, dan profile (sebuah objek dengan name dan version). stale bernilai true ketika rilis atau salah satu treknya disunting setelah analisis terakhir yang selesai; jalankan ulang analisis dengan endpoint penyegaran sebelum mengonfirmasi.

Selama analisis masih berjalan, laporan mengembalikan checks_in_progress: true dengan daftar issues yang kosong. Jika Anda lebih suka tidak menggunakan webhook, lakukan polling pada endpoint ini hingga generated_at terisi, biasanya beberapa menit setelah unggahan dan transcoding selesai, lalu baca masalahnya. Untuk diberi tahu begitu laporan siap, gunakan webhook laporan-siap.

Contoh respons setelah analisis selesai:

{
"issues": [
{
"id": "12345",
"code": "example.issue-code",
"title": "Short issue title",
"message": "What to fix and how.",
"status": "confirmed",
"severity": "",
"is_blocking": true,
"requires_feedback": false,
"custom_description": null,
"affected_tracks": [456],
"evidence": [
{
"affected_track_id": 456,
"track_title": "Matched track title",
"artist": "Matched artist",
"release_title": "Matched release",
"release_date": "2024-03-01",
"isrc": "USRC12345678",
"store_url": "https://…"
}
]
}
],
"report": {
"generated_at": "2026-07-07T12:00:00Z",
"checks_in_progress": false,
"stale": false,
"hold": true,
"review_status": "",
"release_status": "",
"profile": { "name": "quality_report", "version": 2 }
}
}

Setiap item evidence menjelaskan satu rilis yang sudah ada yang cocok dengan rilis Anda: affected_track_id (trek Anda yang mana yang dikenai kecocokan), track_title, artist, release_title, release_date, dan isrc yang cocok, serta store_url yang menunjuk ke halaman toko tempat kecocokan itu tayang. Paling banyak tiga kecocokan dicantumkan per trek, dan kunci ini hanya ada pada jenis masalah di atas.

POST /api/public/releases/{id}/quality-report/refresh
Authorization: Bearer YOUR_API_TOKEN

Memulai siklus analisis Preflight QC yang baru untuk rilis yang ditahan. Menyunting rilis yang ditahan tidak menjalankan ulang pemeriksaan dengan sendirinya: ini hanya menandai laporan saat ini sebagai usang (report.stale: true). Ketika Anda selesai menyunting, panggil endpoint ini untuk menjalankan ulang analisis; ketika siklus selesai, webhook laporan-siap terpicu dan report.stale kembali menjadi false.

Panggilan yang berhasil mengembalikan 202 Accepted:

{
"status": "refreshing",
"checks_in_progress": true,
"review_status": "pending_customer_review",
"release_status": "to_review"
}

Panggilan ini idempoten selama sebuah siklus sedang berjalan: memanggilnya lagi mengembalikan isi respons yang sama (masih berjalan), tidak mengantrekan analisis kedua, dan tidak mengurangi kuota Anda. Respons lain yang perlu Anda tangani:

  • 409 not_in_customer_review_hold: rilis saat ini tidak sedang ditahan untuk tinjauan Preflight QC Anda.
  • 409 refresh_coalesced: sebuah analisis untuk rilis ini baru saja selesai, jadi tidak ada yang diantrekan. Coba lagi setelah header Retry-After (dalam detik).
  • 429 preflight_recheck_limit_reached: Anda telah mencapai kuota penggunaan wajar sebesar 6 siklus analisis yang dimulai per rilis per jam bergulir. Header Retry-After (dalam detik) memberi tahu Anda kapan penyegaran berikutnya diizinkan. Melakukan polling pada analisis yang sedang berjalan itu gratis; hanya memulai siklus baru yang menghabiskan kuota.
  • 403 RELEASE_NOT_VALIDATED: rilis harus lolos validasi sebelum analisis ulang dapat dimulai (aturan yang sama seperti mendistribusikan); jalankan validasi terlebih dahulu.
  • 403 pre_review_qc_not_enabled: Preflight QC tidak diaktifkan untuk akun pemilik.
POST /api/public/releases/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

Mengeluarkan rilis dari penahanan dan memindahkannya ke antrean tinjauan normal: padanan tombol konfirmasi di aplikasi versi API.

Konfirmasi mengharuskan analisis yang selesai dan terkini. Dua konflik yang perlu ditangani:

  • 409 checks_in_progress: analisis masih berjalan. Tunggu webhook laporan-siap (atau lakukan polling hingga generated_at terisi), lalu coba lagi.
  • 409 checks_stale: rilis disunting setelah analisis terakhir yang selesai (report.stale bernilai true). Panggil endpoint penyegaran, tunggu laporan yang baru, lalu coba konfirmasi lagi.

Jika Anda membangun logika di atas laporan kualitas, dasarkan pada code masalah:

  • code adalah string yang stabil dalam format slug (misalnya audio.trailing-silence). Aman untuk memetakan kode di sistem Anda dan membangun logika di atasnya.
  • Judul dan pesan adalah teks untuk manusia. Keduanya dapat diperhalus seiring waktu, jadi jangan pernah mendasarkan logika pada teks; gunakan hanya untuk tampilan.
  • Kode baru dapat muncul seiring cakupan Preflight QC berkembang. Tangani kode yang tidak Anda kenali secara generik: tampilkan title dan message dari respons alih-alih gagal.
  • Laporan Anda mengajarkan kode yang penting. Seiring Anda menjalankan rilis melalui Preflight QC, kode yang relevan dengan katalog Anda muncul secara alami di laporan kualitas Anda sendiri.
  • Apa yang dicakup analisis. Masalah terbagi dalam kategori berikut: metadata rilis dan trek, tanggal dan versi rilis, kualitas audio, artwork, konten AI, identifier katalog, distribusi sebelumnya, serta lisensi dan dokumentasi.

Untuk memetakan masalah saat membangun alur kerja QA Anda sendiri, ambil katalog lengkapnya secara terprogram:

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

Endpoint ini mengembalikan setiap masalah yang dapat muncul dalam laporan kualitas, dengan kode string yang stabil sebagai kuncinya, beserta judul, templat pesan, tingkat keparahan, penanda pemblokiran, requires_feedback, dan kategorinya (type). Respons juga membawa profil kualitas yang menjadi dasar penghitungan katalog, sebagai {name, version}. Endpoint ini hanya tersedia untuk akun dengan pengaya Preflight QC.

Laporan akan menampilkan checks_in_progress: true tanpa masalah yang tercantum untuk saat ini. Ini normal tepat setelah Anda mengirim. Tunggu beberapa menit setelah unggahan dan transcoding selesai, lalu periksa lagi: di aplikasi laporan akan menyegarkan dirinya sendiri. Melalui API, Anda dapat berlangganan webhook laporan-siap untuk menerima pemberitahuan begitu laporan siap, atau melakukan polling hingga generated_at terisi.

Bisakah saya menyunting rilis selagi ditahan?

Section titled “Bisakah saya menyunting rilis selagi ditahan?”

Bisa, sunting sebebas yang Anda mau: rilis dalam penahanan pra-tinjauan tetap sepenuhnya dapat disunting. Menyunting tidak menjalankan ulang pemeriksaan dengan sendirinya; ini menandai laporan saat ini sebagai usang. Ketika Anda selesai dengan perubahan Anda, minta analisis baru (dari halaman rilis di aplikasi, atau endpoint penyegaran untuk integrasi) untuk melihat hasil yang diperbarui tanpa keluar dari penahanan. Analisis baru perlu selesai sebelum Anda dapat mengonfirmasi.

Apa yang terjadi setelah saya mengonfirmasi?

Section titled “Apa yang terjadi setelah saya mengonfirmasi?”

Rilis Anda keluar dari penahanan dan bergabung ke antrean tinjauan normal, tempat ia ditinjau seperti rilis lainnya. Lihat Validasi dan tinjauan untuk cara kerja tinjauan, lama waktunya, dan hasil yang mungkin.

Bisa: selama rilis Anda berada dalam penahanan pra-tinjauan dan Anda belum mengonfirmasinya, rilis belum masuk tinjauan, sehingga Anda bebas untuk terus menyuntingnya atau membiarkannya sebagai draf dan kembali nanti. Rilis baru masuk ke antrean tinjauan ketika Anda mengonfirmasinya.

Apakah saya harus memperbaiki setiap masalah sebelum mengonfirmasi?

Section titled “Apakah saya harus memperbaiki setiap masalah sebelum mengonfirmasi?”

Anda harus menyelesaikan masalah yang memblokir sebelum dapat mengonfirmasi. Masalah informatif tidak menghentikan Anda untuk mengonfirmasi, tetapi layak dilihat: membereskan sebanyak mungkin sebelum tinjauan adalah jalur tercepat menuju persetujuan.


Ada pertanyaan tentang Preflight QC? Hubungi tim kami. Kami dengan senang hati membantu.

Belum menggunakan LabelGrid?

Semua yang baru saja Anda baca tersedia di platform kami.

Lihat kemampuan LabelGrid →