Formattare capitoli audio per app

Le app di podcast compatibili con i capitoli Podcasting 2.0 si aspettano un piccolo file JSON collegato all’elemento RSS dell’episodio, non tag di capitolo incorporati nell’MP3. Questa capacità riceve le righe di capitolo ordinate—titolo più tempo di inizio in secondi, con immagine e URL opzionali per capitolo—ed emette l’oggetto chapters versionato standard più una stringa json_text formattata che Lei può ospitare e referenziare con il tag podcast:chapters. Se i tempi di inizio non sono strettamente crescenti, l’attività fallisce con invalid_input così che marcatori errati non raggiungano il feed.

Come si presenta il JSON dei capitoli Podcasting 2.0

Quel file è un oggetto JSON le cui chiavi obbligatorie sono version (comunemente 1.2.0) e chapters, un array di marcatori ordinati per startTime crescente. Campi opzionali a livello di file come author, title, podcastName e description aiutano player web e archivi senza cambiare il modo in cui le app saltano nell’audio. Questo esportatore mappa l’input a righe—start_time e title su ogni capitolo, img e url opzionali—in quella forma camelCase così non deve modificare le parentesi graffe a mano né dimenticare la stringa di versione. Ospiti il json_text risultante a un URL HTTPS stabile, poi aggiunga podcast:chapters con type application/json+chapters nell’item.

Contratto di input, forma della risposta e regole di validazione

Le chiavi di output opzionali sono omesse del tutto invece di essere impostate a null. Invii con POST un corpo JSON con un array chapters obbligatorio di almeno un oggetto. Ogni oggetto deve includere title come stringa non vuota e start_time come numero finito non negativo in secondi (sono accettati alias come startTime su ogni riga). I campi opzionali per capitolo sono img e url come stringhe non vuote, toc come booleano (false segna un capitolo silenzioso; true è il predefinito ed è omesso dall’esportazione), e end_time come numero non negativo non inferiore all’inizio di quel capitolo. Stringhe opzionali a livello di file—version (predefinito 1.2.0), episode_title, author, podcast_name e description—vengono copiate nell’oggetto chapters quando presenti. In caso di successo il corpo restituisce version, chapter_count, chapters come l’array Podcasting 2.0 con chiavi startTime, json_text come il file formattato pronto per il caricamento, mime_type impostato su application/json+chapters, e gli eventuali metadati di episodio forniti sotto author, title, podcast_name e description. I fallimenti di validazione sollevano invalid_input e non vengono fatturati: chapters assente, title vuoto, tempi negativi o non finiti, fine prima dell’inizio, più di cinquecento righe, o tempi di inizio non strettamente crescenti. Esempio: tre righe a zero, centoventi e milleottocento secondi con immagine e link sul capitolo centrale producono un array chapters di tre voci e una stringa json_text allineata strutturalmente agli esempi pubblici Podcasting 2.0.

Dove un esportatore deterministico di capitoli ripaga

Strumenti di trascrizione o di suggerimento capitoli che emettono coppie titolo e secondi possono inoltrare il risultato qui per ottenere il formato orientato all’app senza incorporare la conoscenza Podcasting 2.0 in ogni client. La validazione fallita non consuma saldo. Abbini questo esportatore a prodotti separati di generazione capitoli tramite ASR quando deve inventare marche dall’audio; usi questo percorso quando conosce già i marcatori e le serve solo un’esportazione conforme allo standard. I produttori indipendenti che concludono un episodio in un DAW hanno già le marche temporali in un foglio di calcolo o nelle note della puntata; serve loro un file JSON corretto senza imparare il namespace per tentativi ed errori in ogni app. Poiché l’implementazione è pure parse di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello e senza rete in uscita. Mantenga i titoli di capitolo abbastanza corti per le UI di indice su mobile, preferisca URL HTTPS assolute per img e url, e riesegua il formattatore dopo ogni modifica affinché l’ordine strettamente crescente resti applicato.