Genius-bot · 9 минут чтения
Когда нужна api озвучки текста для книги, курса или большой документации, отправлять весь материал одним запросом неудобно. Рабочая схема для длинных материалов строится вокруг разбиения исходника на логические части, последовательной генерации аудио и последующей сборки.
В этой статье разберём именно такой конвейер: как делить текст по главам и абзацам, сохранять единый голос на протяжении нескольких часов, добавлять оглавление и временные метки, а затем обновлять только те фрагменты, которые изменились. Для доступа к ключу используйте раздел API: ключ выдаётся после входа и показывается один раз.
У сервиса операция «Озвучка текста» обозначена как tts и стоит 18 ₽ за 1000 знаков. Оплата идёт за запуск, без абонентской платы и минимального платежа; при выпуске первого ключа на баланс начисляется 50 ₽ для пробного использования.
Почему длинный текст нельзя отправить одним куском
Большой текст лучше рассматривать не как один запрос, а как набор самостоятельных аудиофрагментов. У книги это могут быть главы и подглавы, у курса — уроки, у документации — разделы и подразделы. Такой подход позволяет повторно обработать только изменившийся участок.
Есть и практическая причина. Если весь материал генерируется как единый объект, любое исправление в середине книги превращает задачу в полную повторную генерацию. При разбиении достаточно найти изменённый блок, получить для него новый звук и заменить соответствующий файл при сборке.
Например, книгу на 300 000 знаков можно представить как 30 частей по 10 000 знаков. При правке одного абзаца не требуется заново обрабатывать остальные 29 частей. Это особенно полезно, если текст выпускается несколькими версиями.
Стоимость тоже удобно считать заранее. При тарифе 18 ₽ за 1000 знаков условные 300 000 знаков дают 5400 ₽ при полном выпуске, если считать только объём текста для озвучки. При повторной генерации одного изменённого фрагмента стоимость зависит только от его размера.
| Операция | Код | Цена |
|---|---|---|
| Озвучка текста | tts |
18 ₽ за 1000 знаков |
| Расшифровка записи | stt |
10 ₽ за запуск |
| Убрать шум | denoise |
36 ₽ за запуск |
| Звук из видео | ytaudio |
0 ₽ за запуск |
Для контроля процесса API предоставляет отдельные маршруты для запуска и проверки задачи: POST /generate запускает операцию, а GET /tasks/{id} возвращает её состояние и результат. Частота запросов ограничена 60 запросами в минуту на ключ, поэтому очередь из большого количества небольших фрагментов стоит обрабатывать с учётом этого ограничения.
Разбиение по смыслу, а не по числу знаков
Простое правило «каждые 5000 знаков» удобно для программного кода, но плохо подходит для речи. Если граница попадает между предложениями или, например, после незаконченной мысли, при склейке появляется слышимый разрыв. Поэтому сначала нужно найти естественные границы, а уже потом учитывать размер частей.
Для книги хорошая базовая структура выглядит так: книга → глава → подраздел → несколько абзацев. Внутри одного фрагмента желательно оставлять законченный смысловой блок. Заголовок можно хранить отдельно, чтобы управлять тем, произносится ли он голосом или используется только как элемент оглавления.
Для автоматического разбиения можно сначала искать заголовки, затем абзацы. Если получившийся блок слишком большой, его можно делить по предложениям. Последняя часть каждого уровня должна сохранять контекст предыдущего уровня только там, где это действительно нужно для корректной интонации.
Полезно сразу создать идентификаторы частей. Например: book-01-chapter-03-part-004. Тогда имя файла, запись в базе и запись в манифесте будут ссылаться на один и тот же блок. При повторной сборке не придётся определять соответствие по порядковому номеру аудиофайла.
Отдельно стоит хранить исходный текст каждой части и его версию. Например, в базе можно иметь поля part_id, chapter, text, text_hash, audio_file и duration. Если хеш нового текста совпадает с сохранённым, эту часть можно не озвучивать повторно.
Склейка глав: паузы и уровни
Склейка — это не просто соединение файлов один за другим. Между абзацами, подразделами и главами нужны разные логические паузы, иначе несколько часов материала могут восприниматься как непрерывный поток.
Удобно задать три уровня: короткая пауза между абзацами, более заметная пауза между подразделами и самая длинная — между главами. Конкретную длительность лучше определять по звучанию готового материала, а не применять одну цифру ко всему проекту.
При этом сами фрагменты должны генерироваться с одинаковыми параметрами. Если одна глава создана с одними настройками, а другая с другими, даже один и тот же голос может субъективно восприниматься иначе. Поэтому параметры генерации стоит вынести в конфигурацию проекта и не задавать вручную для каждого запроса.
Для многочасовой записи полезно также собирать манифест. В нём можно хранить последовательность частей, название главы, имя аудиофайла, длительность и смещение относительно начала всей записи. Такой список становится основой для оглавления и последующих обновлений.
Единый голос и параметры на всю книгу
Единый голос — это не только выбор одного варианта озвучки. В проекте нужно придерживаться одной конфигурации для всех частей. Если настройки меняются от главы к главе, на стыках могут появляться различия в тембре, темпе или характере подачи.
Поэтому конфигурацию лучше хранить рядом с метаданными книги. Например, запись проекта может содержать идентификатор операции tts, параметры, версию текста и список частей. При повторной генерации изменённого блока программа подставляет те же параметры, что использовались для остальных частей.
Сам запуск операции выполняется через базовый адрес API https://genius-bot.ru/wp-json/genius/v1. Авторизация передаётся заголовком Authorization: Bearer <ключ>. Например, общий вид запроса на запуск можно построить так:
curl -X POST "https://genius-bot.ru/wp-json/genius/v1/generate" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"service": "tts",
"text": "Текст одного подготовленного фрагмента."
}'Точные параметры конкретной операции нужно брать из ответа GET /services, который возвращает список доступных операций и цен. Это позволяет не зашивать в приложение предположения о параметрах запроса.
Для Python такой же конвейер можно оформить отдельной функцией:
import requests
BASE_URL = "https://genius-bot.ru/wp-json/genius/v1"
API_KEY = "YOUR_API_KEY"
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
payload = {
"service": "tts",
"text": "Текст одного подготовленного фрагмента."
}
response = requests.post(
f"{BASE_URL}/generate",
headers=headers,
json=payload,
timeout=60,
)
response.raise_for_status()
task = response.json()
print(task)После запуска нужно сохранить идентификатор задачи. Состояние проверяется через GET /tasks/{id}. Для большого проекта удобнее не держать HTTP-запрос открытым до завершения обработки, а поставить задачи в очередь и периодически проверять их состояние.
Есть и другой вариант — передать при запуске callback_url. Когда задача будет готова, API отправит POST на указанный адрес. Для конвейера из сотен частей webhook позволяет не делать постоянный опрос каждой задачи.
Оглавление и метки времени
Оглавление для аудиокниги проще строить после получения длительности каждого фрагмента. Если главы идут последовательно, достаточно суммировать длительности всех предыдущих частей и получить время начала очередной главы.
Например, если первая глава длится 24 минуты 18 секунд, а вторая начинается после неё, метка второй главы будет 00:24:18. Для третьей главы нужно прибавить длительность второй. Так получается таблица, которую можно использовать при создании навигации поверх итогового аудио.
В манифесте стоит хранить время не только главы, но и более мелких элементов, если пользователю понадобится переход к разделам. Структура может выглядеть так: chapter_id, title, start, end, parts. Само аудио при этом остаётся обычной последовательностью сгенерированных фрагментов.
Для многочасового проекта полезно не пересчитывать всё вручную после каждой правки. Если изменилась только часть главы и её длительность стала другой, можно пересчитать временные смещения начиная с этой части. Предыдущие главы сохраняют прежние метки.
Такой подход особенно удобен, когда нужно озвучить книгу нейросетью не один раз, а поддерживать аудиоверсию вместе с текстовой редакцией. Текст и аудио становятся двумя представлениями одной версии документа, а манифест связывает их между собой.
Правка текста после озвучки: что переделывать
После первой сборки обычно находятся не только фактические ошибки, но и места, где текст плохо звучит вслух. Необязательно заново генерировать всю главу. Сначала нужно определить минимальный фрагмент, который действительно изменился.
Если исправлено одно предложение внутри абзаца, технически можно заменить только соответствующую часть. Но слишком мелкое дробление увеличивает число стыков. Поэтому имеет смысл выбирать минимальную единицу обновления так, чтобы рядом оставался достаточный контекст и естественная пауза.
Для каждой версии стоит хранить хеш текста. Допустим, глава состоит из 12 частей. После правки программа вычисляет хеш каждой новой части и сравнивает его с предыдущей версией. Если совпали 11 хешей из 12, повторно запускается только одна операция tts.
Отдельно нужно учитывать изменения заголовков. Если текст главы не менялся, но изменилось её название, сам аудиофрагмент может остаться прежним, если заголовок хранится отдельно. Если же заголовок произносится внутри записи, соответствующий фрагмент придётся обновить.
Тот же принцип работает для курсов и документации. При выпуске новой версии можно оставить неизменные аудиофайлы, заменить только изменившиеся части и заново рассчитать метки после первой затронутой позиции. В результате озвучка длинного текста превращается из одноразовой операции в управляемый процесс обновления.
Если проект нужно запускать регулярно, полезно разделить его на четыре этапа: подготовка текста, генерация отсутствующих или изменённых частей, сборка и публикация метаданных. Тогда аудиокнига через API строится тем же способом, что и любой версионируемый цифровой материал: исходник является источником данных, а аудио — производным результатом.
Для больших объёмов важно учитывать и лимит частоты. На один ключ допускается не более 60 запросов в минуту, поэтому очередь генерации должна ограничивать скорость отправки. Если частей много, лучше заранее сформировать очередь и обрабатывать её последовательно или с контролируемой конкуренцией, не превышая установленный предел.
Частые вопросы
Можно ли озвучить всю книгу одним запросом?
Для управляемого процесса лучше разделить книгу на части по главам, подразделам и абзацам. Это позволяет повторно генерировать только изменённые фрагменты и отдельно формировать оглавление.
Сколько стоит озвучка текста?
Операция tts стоит 18 ₽ за 1000 знаков. Цены указаны за один запуск, а для озвучки расчёт привязан к 1000 знаков.
Как проверить, закончилась ли генерация?
После запуска операции нужно сохранить идентификатор задачи и обращаться к GET /tasks/{id}. Также можно передать callback_url, чтобы получить POST после готовности задачи.
Как сохранить единый голос между главами?
Параметры генерации нужно хранить как часть конфигурации проекта и использовать одну конфигурацию для всех частей книги. При обновлении отдельного фрагмента применяются те же параметры.
Что делать, если текст книги изменился?
Сравните версии отдельных частей, например по хешу текста. Неизменившиеся фрагменты можно оставить, а изменившиеся повторно отправить на озвучку и затем пересобрать последовательность и временные метки.
Где получить API-ключ?
После входа ключ выдаётся в личном разделе API. Ключ показывается один раз, поэтому его следует сохранить в конфигурации приложения или менеджере секретов, а не вставлять непосредственно в исходный код.
