Formater chapitres audio pour apps

Les applications de podcast compatibles avec les chapitres Podcasting 2.0 attendent un petit fichier JSON lié à l’élément RSS de l’épisode, et non des balises de chapitre intégrées dans le MP3. Cette capacité prend vos lignes de chapitres ordonnées—titre plus heure de début en secondes, avec image et URL optionnelles par chapitre—et émet l’objet chapters versionné standard ainsi qu’une chaîne json_text mise en forme que vous pouvez héberger et référencer avec la balise podcast:chapters. Si les heures de début ne sont pas strictement croissantes, la tâche échoue avec invalid_input afin que de mauvais marqueurs n’atteignent pas le flux.

À quoi ressemble le JSON de chapitres Podcasting 2.0

Ce fichier est un objet JSON dont les clés obligatoires sont version (souvent 1.2.0) et chapters, un tableau de marqueurs ordonnés par startTime croissant. Des champs optionnels au niveau du fichier tels que author, title, podcastName et description aident les lecteurs web et les archives sans changer la façon dont les apps sautent dans l’audio. Cet exporteur mappe votre entrée par lignes—start_time et title sur chaque chapitre, img et url optionnels—vers cette forme camelCase afin que vous n’éditiez pas les accolades à la main ni n’oubliiez la chaîne de version. Hébergez le json_text résultant à une URL HTTPS stable, puis ajoutez podcast:chapters avec type application/json+chapters dans l’élément.

Contrat d’entrée, forme de la réponse et règles de validation

Les clés de sortie optionnelles sont omises entièrement plutôt que mises à null. Envoyez en POST un corps JSON avec un tableau chapters obligatoire d’au moins un objet. Chaque objet doit inclure title comme chaîne non vide et start_time comme nombre fini non négatif en secondes (des alias tels que startTime sont acceptés sur chaque ligne). Les champs optionnels par chapitre sont img et url comme chaînes non vides, toc comme booléen (false marque un chapitre silencieux ; true est la valeur par défaut et est omis de l’export), et end_time comme nombre non négatif non inférieur au début de ce chapitre. Les chaînes optionnelles au niveau du fichier—version (par défaut 1.2.0), episode_title, author, podcast_name et description—sont copiées dans l’objet chapters lorsqu’elles sont présentes. En cas de succès le corps renvoie version, chapter_count, chapters comme le tableau Podcasting 2.0 avec des clés startTime, json_text comme le fichier mis en forme prêt à téléverser, mime_type égal à application/json+chapters, et les métadonnées d’épisode fournies sous author, title, podcast_name et description. Les échecs de validation lèvent invalid_input et ne sont pas facturés : chapters manquant, title vide, temps négatifs ou non finis, fin avant le début, plus de cinq cents lignes, ou heures de début qui ne sont pas strictement croissantes. Exemple : trois lignes à zéro, cent vingt et mille huit cents secondes avec une image et un lien sur le chapitre du milieu produisent un tableau chapters de trois entrées et une chaîne json_text alignée structurellement sur les exemples publics Podcasting 2.0.

Où un exporteur déterministe de chapitres justifie son coût

Les outils de transcription ou de suggestion de chapitres qui produisent des paires titre et secondes peuvent diriger leur résultat ici pour obtenir le format orienté app sans intégrer la connaissance Podcasting 2.0 dans chaque client. Une validation en échec ne consomme pas de solde. Associez cet exporteur à des produits distincts de génération de chapitres par ASR lorsque vous devez inventer des horodatages à partir de l’audio ; utilisez ce chemin lorsque vous connaissez déjà les marqueurs et n’avez besoin que d’un export conforme au standard. Les producteurs indépendants qui terminent un épisode dans un DAW ont déjà des horodatages dans un tableur ou des notes d’émission ; ils ont besoin d’un fichier JSON correct sans apprendre l’espace de noms par essais et erreurs dans chaque app. Comme l’implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle et sans réseau sortant. Gardez les titres de chapitre assez courts pour les interfaces d’index mobile, préférez des URL HTTPS absolues pour img et url, et relancez le formateur après chaque modification afin que l’ordre strictement croissant reste appliqué.