А в чем сложность принять решение о наполнении самим? И даже менять его между релизами. Лишь бы механизм был.
Сами признаете, что таких слов мало. Что дает намек, вы про них уже знаете. И просто не знаете, как с ними оперировать. Точнее, приняли решение ничего не делать.
Хардкодить ифами это конечно жестко. Словарный метод коррекции, с наполнением распространенными исключениями — вполне предсказуемо. Инфлюенсеры... оценивать надо статистически. 1 решивший слушать кафЕ против 9 считающими нормальным кафэ, это кмк не аргумент.
Именно что таких слов мало. Но каждое из них бьет больно. Не предлагаю "подтирать сопельки" каждому слову или каждому пользователю. Речь исключительно об основных словах с основным предпочтением фонетики.
У меня другой попутный вопрос возник: Как оценивать "крупность"? Распространенность устной речи; распространенность письменных материалов; распространенность письменных нуждающихся в озвучке — это разные значения. Текст-в-речь связывает две среды.
А много ли слов нуждается в э-фикации? На память кроме этих приходят только интернет, тест, купе и кафе. Ну а выбор стороны работающей с исключениями — клиент или "сервер", — зависит от объема этого списка и отношения к нему, в целом по рынку. Если большинство синтезаторов справляется, это одно, если же большинство также не придает внимания, оставляя на откуп клиенту, то другое.
Что-то такое есть. Как минимум надо посмотреть внимательнее.
Одна из заявленных идей, привлекла внимание. Все ORM всегда или с большего пляшут от базы, давая скорее ROM — relation object mapper. А почему бы не плясать от данных. Заставить разработчика описывать не структуры хранения данных со всякими Field, Column, а структуры использования. Простые типы, простые связи list[Child], простые указатели Parent, если связь объектов двунаправленная. ORM анализирует как это хранить. При необходимости требуя помощи, желательно с подсказками на место, где ему нужна помощь. Но эта помощь маппинга как бы сбоку от данных и только там, где сбоит автовывод. Примерно как в самом DDL SQL. Можно PK, References указывать для полей при создании таблицы, а можно отдельно Constraint.
Для меня, самая большая проблема, это ORM или SQL. Многие правильно отметили, для разных задач, разные подходы. Но редко бывает так, что проект не выбивается местами за рамки одного. Иногда хочется быстро переключиться на другую модель работы, а фиг. Это не два вида на задачу — работа в коде с табличными данными, а две задачи от хранилища и от кода, на один вид — данные.
Например поменять схему через DDL бывает проще. Но потом повторяй аналогичное в модели. Или чем ломать голову, написать SQL запрос, отладить его, а потом модель преобразует его в кодовое представление. Разных сочетаний множество. Прозрачно переключаться туда-сюда, не думая как удобнее сделать, а осмысливая что и зачем — ORM и SQL, через минуту SQL и ORM, еще через пять — снова обратно, код вперед. Синхронизация.
Например держать автогенерируемые модели в отдельном модуле, куда будут извлекаться все структуры, типы, связи, свойства (pk, uq, nullable, default, check). Надо надстроить — удобный механизм наследования. IDE проверит контракты и визард при необходимости поможет разрешить конфликты.
Не совсем то. О продукте речь не идет. Лишь личная возможность оценить. Посмотрите какие "метрики" дикции становятся заметны, выходят на первый план. Прослушивание предложениЯ и прослушивание предложениЙ, текста, вызывают разный отклик в сознании.
Кстати, возник еще вопрос — финальные "паддинги". Если они "продуктовые", не надо обращать внимания, само получится нормально после склейки, это одно. Помогают. Но если нужна коррекция, а паддинг плавающий, уже другое. Вредит. Он у вас постоянный? Не зависит от голоса и/или последнего предложения в задании? То есть надо или 0, или константа.
Здравствуйте. Перечитав на свежую голову нашу беседу, действительно нашел два пробела в аргументации.
Вопросы только к одному голосу — Айдар. А я почему-то обобщил их на весь проект. Прошу прощения. Однако, посмотрите на свой предыдущий скрин. Найдите во втором и третьем предложении позиции запятых. А если не зная текста, есть они там или нет, и не имея в подсказке других голосов? В отношении пауз между предложениям, может быть из-за малых внутренних пауз, может они действительно меньше, но складывается ощущение избыточной "компактности" голоса. Слышны слова, не слышно речи.
Нормально ли такое чередование, как утверждаете вы, или ненормально, как считаю я, без эталона не определить. Мой "эталон" других синтезаторов вы разумно отклоняете, но иного не предоставлено. Подумывал приложить еще образцов, но отказался. Сторонние данные психологически проще дезавуировать. Поэтому запишите запишите живую речь сами и посмотрите глазами на ее тайминги. Именно живую, обычного рассказчика "как я провел выходные", а не озвучивающего декламатора. Хотя может и на него стоит глянуть, не знаю.
Интересно, как вы тестируете? Предложу озвучить и прослушать рассказ на десяток-другой страниц. Обращая внимание не на голос, а на содержание. Насколько легко это будет. Насколько удерживается внимание. Насколько слышен сам текст. Ведь тестируя на коротких демо-фрагментах, некоторые моменты не привлекают внимания. А на длинных — становятся значимыми. Тайминги пауз, кмк из их числа.
По вашему примеру... текст должен быть чуть больше, либо уменьшить масштаб. И тут нет эталона. Нет сравнения. Сравнения не между вашими голосами, а с вашими голосами. Я же не сказал, что у вас совсем нет "артикуляции", лишь что она слабовыразительна, до полной потери.
Попросите в понедельник прочесть этот фрагмент кого-то из коллег, не особо привлекая к этому внимания, чтобы получилась речь в естественной среде. Ну либо просто забейте, если считаете это не важным, а мои реплики придирками. Так тоже может быть. До следующей встречи, коллега.
Обратите внимание на структуру, чередование сигнал-тишина. Как для внутренней пунктуации предложения, так и между ними. В качестве образца можете взять абсолютно любой текст на ~1 минуту звучания, а в качестве эталона озвучку любым другим синтезатором, а лучше живую речь.
По данному примеру... например, в двух других голосах видна 1 запятая в первом предложении и 2 в третьем. У вас сплошной поток. И так далее по всему треку.
Интонация в рамках уже не предложения, а в рамках абзаца / страницы текста.
Да нет же. Монотонность создается отсутствием пауз. Должна ли пауза повествовательного отличаться от его длительности? Или длительности последнего "блока", от запятой до финала? Какая пауза должна быть на многоточии, тире? А у восклицательного и вопросительного?
Здесь не только гигантских моделей не надо, здесь вообще моделей не надо. Если предварительно разбить на предложения и озвучивать по ним. Достаточно отобрать несколько типов предложений, в зависимости какая гипотеза проверяется, проанализировать человеческую дикцию и вывести обобщенную закономерность. Не надо многих часов, пяток предложений тремя-четырмя обычными людьми, на гипотезу.
Слишком все бросились в нейросети. Решают квадратное уравнение через интегралы :)
При попытке открыть аудио выдает 404.
Нужна регистрация для доступа к вложениям, вроде бы.
Ошибка не в конкретном месте. Мол везде хорошо, а тут. Ошибка в отсутствии. Системном. Лучше покажу в волновой форме. Основное внимание на диапазон 50-80% трека, но и остальное показательно.
...не могли отличить по 1 фразе синтез от не-синтеза. Копать имхо надо в сторону интонаций / контроля эмоций / интонаций.
О какой структуре текста вообще может идти речь в синтезе, который в принципе не понимает смысла прочитанного?
Именно, что по фразе. В книге — заметнее. На счет интонаций, в обсуждении "ударятора" я писал, как по моему мнению, происходит окраска текста читателем при чтении книги. Поэтому копать надо в первую очередь в эту сторону. Дать слушателю крепкую основу для личной окраски — озвучить просодией структуру предложения, включая финальный знак.
Не надо понимать смысл прочитанного, надо понимать смысл структуры текста выраженный знаками препинания. Помните пример "выдры в гетрах", где 5 предложений с одинаковым текстом, по разному размечено пунктуацией. Вот именно ее и надо "прочитать" просодией. И только после уверенного преодоления этого этапа, начать окрашивать самому, выступая в роли декламатора, подчеркивающего смыслы.
Нет времени читать все 56 страниц форума.
Ссылка ведет на конкретный пост, а не ветку.
Если вам нужен контроль длины пауз или более длинные паузы между абзацами - то в SSML это всё есть.
Прекрасно понимаю и неоднократно писал об этом. Вопрос в другом. Должно ли продуктовое решение уметь читать абзацы, речью давая понять слушателю, что текст содержит последовательность отдельных утверждений, восклицаний и вопросов? Это один из элементов оценки похожести на человека — монотонность дикции. Только если в предыдущем абзаце речь шла о монотонности в рамках предложения, тут монотонность в рамках более крупной структурной единицы.
Качество тут выше, чем у v3 и значительно выше, чем уv4
Бесспорно. Скорость в 3-4 раза быстрее v3 и качество на X пунктов выше. А если бы скорость была равна, на сколько бы пунктов было выше качество? Вот это и хотелось бы глянуть. Любопытство, не более. Если что, к фонетике вообще непритязателен. Больше обращаю внимания на просодию. И тут вы прилично подтянулись. Надо еще послушать непрерывно пару-тройку книг, чтобы окончательно в этом убедиться (или опровергнуть).
Это уже слабо похоже на правду, нужны примеры.
Если не возражаете, можете прогуляться на 4pda. Откройте Айдара в аудиоредакторе. В лучшем случае, паузы 200 и менее миллисекунд. Если память не изменяет, рядовым является 400-750 мс. Особое внимание отрывку 30-48 секунд. Да, пунктуация там может непростая, но она есть. Можете убедиться по другим озвучкам.
При озвучке абзацев или не дай создатель, еще больших фрагментов — структура текста теряется. Не считаю это значимой проблемой — "Побить на предложения и вперёд". Но многие, если не большинство, будут использовать библиотеку именно так и впечатление будет соответствующее. Решение за вами.
Это вы про время, дату, температуру, координаты и римские цифры? Ну да, есть такая буква. И все они сводятся к уже описанному, согласовать слово с числом и число со словом. Остальные юзкейсы либо исчезающие, либо не детектируемые.
Покрутил "ручки", послушал демки — проект достойный. В первую очередь оцениваю с точки зрения приватного озвучивания книг, не особо напрягаясь вопросом лицензионной чистоты. Больше всего радует стабильность и (автоматизируемая) управляемость. Этой пары больше никто не предоставляет. А вот качество... еще один проект среди достойных, плюс-минус. Во главу угла была поставлена скорость и этот результат был достигнут. На CPU cопоставима с классическими SAPI синтезаторами старой школы. Было бы интересно глянуть, если бы не "стали в 3-4 раза быстрее", а разменяли скорость на качество, сохранив её как у v3 или лучше v4.
Из наиболее бросающегося в глаза. Предложения не выделены соответствующими паузами. Речь сливается. Более того, паузы часто меньше чем от запятой, а иногда и вовсе отсутствуют. Это в принципе исправляется вручную, вставкой тегов или генерацией тишины в коде. Но для режима "сделай хорошо" нужна встроенная поддержка. Которая заодно поможет решить проблему "при генерации сразу сильно длинного аудио скорость немного проседает". Разбивать внутри текст на предложения, например razdel из проекта Natasha (очень быстрый и качественный), озвучивать порциями, вставляя пустые межблоки в выходное аудио. Ну и заодно подумать о расширении интерфейса библиотеки потоковым методом. Уменьшит задержку между запросом и ответом. Не нужно будет ждать синтеза всего запроса.
Число в текст, с учетом спряжений и склонений, количественной и порядковой формы, дело нескольких чел*часов. Правда я использовал PyMorphy.
Осталось выбрать из корпуса числа с контекстом (±1-2 слова), сгруппировать, разметить форму и обучить сетку. Которая потом и будет эту форму указывать дискретному конвертеру. Тут пока даже предварительных оценок нет. Но таки думаю, что не огромные, а просто большие.
Однако речь немного про другое. Куда по сути этот подход и должен быть расширен — последовательное с накоплением. Мы же не учим учебник за раз. Тему за темой, параграф за параграфом, абзац за абзацем, тезис за тезисом. Используя на следующем шаге всю информацию предыдущих. А также уточняя их понимание.
Как писал в других темах, естественный язык это инструмент описания реальности. То есть языковая модель переводит с естественного языка на некий промежуточный, создавая модель этой реальности. Смысловая ей оперирует. И потом языковая выступает в роли вокодера.
То есть для изучения Rust нам не надо трогать языковую модель. Ни одного нового символа не появилось. Ну может кроме зарезервированных слов. Вся работа проводится в смысловой модели. Которая сама изначально должна быть построена на расширении, а не вытеснении или перестройке весов. И следовательно теряется смысл в этапных Hebbian-патчах. Точнее, они приобретают совсем другой смысл — фрагмента реальности с которым мы сейчас оперируем, быстрой памяти.
Эволюции это хорошо. Но возможно, данная, заведет процесс создания ИИ еще глубже в тупик.
Представим, что модель как-то обучена программированию и как-то знает несколько языков. Выходит новый. Для него пишется документация, учебник. Вот это переменная, вот это функция, вот это структура, вот это трейт, вот это модель владения, вот это... и так далее. Попросту представим что Rust вышел только сейчас. Скормив BDH эту доку, сможет ли он выучить язык?
Если есть обоснованное предположение, что структура функций не будет меняться, либо более сложная логика появится только в редких статус-обработчиках, можно еще больше упростить.
class OrderProcessor:
def __init__(self):
self.handlers = {
"new": [validate_order, process_payment, send_confirmation_email],
...
}
def __call__(self, order_data):
status = order_data['status']
if status in self.handlers:
for handler in self.handlers[status]:
reuslt = handler(order_data)
else:
logger.warning(f"Unknown order status: {status}")
result = {"error": "Unknown status"}
return result
Скажу как читатель со стажем. Впоследствии перешедшим на аудио. Как декламаторов, так и синтезированное. Подход если не полностью, то существенно ошибочен.
Как сознание читает текст? В нейтральном ключе, последовательно строит фрагмент реальности. Видит знак препинания и фиксирует этот фрагмент в соответствующем ключе. Для вопросительного и возможно восклицательного, ища и подсвечивая точку внимания. Ретроспективно.
С печатным текстом иное невозможно. Там нет указаний на акцентирование. Что авторы учитывают, возможно подсознательно. Вопросительные и восклицательные статистически заметно короче и обладают более простой внутренней структурой.
А что же с аудио, создаваемому синтезатором по этому тексту? С хорошим декламатором, который подсвечивает точку внимания, в ближайшем будущем сравниться невозможно. Нужно понимать смысл. Без него, более целевое декламаторское интонирование, только повредит выучиванию. А с пониманием смысла пока беда-беда.
А что же надо? Достаточно интонацией уверенно "ставить" знак препинания. Обобщенно. Не мешая мозгу излишней ажиотацией, самому находить и подсвечивать эту точку. То есть стать подобным обычному чтению! Тем более, мозгу сложнее обрабатывать ошибки, чем достраивать нюансы. Лучше нейтрально обозначить знак препинания, который получен из текста, гарантированно, чем ошибиться во внимании, о котором нужно догадываться.
Как это сделать? Пара соображений есть. Но общий низкий уровень понимания говорит — не позорься. Думайте, вы больше в этом понимаете!
А в чем сложность принять решение о наполнении самим? И даже менять его между релизами. Лишь бы механизм был.
Сами признаете, что таких слов мало. Что дает намек, вы про них уже знаете. И просто не знаете, как с ними оперировать. Точнее, приняли решение ничего не делать.
Хардкодить ифами это конечно жестко. Словарный метод коррекции, с наполнением распространенными исключениями — вполне предсказуемо. Инфлюенсеры... оценивать надо статистически. 1 решивший слушать кафЕ против 9 считающими нормальным кафэ, это кмк не аргумент.
Именно что таких слов мало. Но каждое из них бьет больно. Не предлагаю "подтирать сопельки" каждому слову или каждому пользователю. Речь исключительно об основных словах с основным предпочтением фонетики.
У меня другой попутный вопрос возник: Как оценивать "крупность"? Распространенность устной речи; распространенность письменных материалов; распространенность письменных нуждающихся в озвучке — это разные значения. Текст-в-речь связывает две среды.
А много ли слов нуждается в э-фикации? На память кроме этих приходят только интернет, тест, купе и кафе. Ну а выбор стороны работающей с исключениями — клиент или "сервер", — зависит от объема этого списка и отношения к нему, в целом по рынку. Если большинство синтезаторов справляется, это одно, если же большинство также не придает внимания, оставляя на откуп клиенту, то другое.
Что-то такое есть. Как минимум надо посмотреть внимательнее.
Одна из заявленных идей, привлекла внимание. Все ORM всегда или с большего пляшут от базы, давая скорее ROM — relation object mapper. А почему бы не плясать от данных. Заставить разработчика описывать не структуры хранения данных со всякими Field, Column, а структуры использования. Простые типы, простые связи list[Child], простые указатели Parent, если связь объектов двунаправленная. ORM анализирует как это хранить. При необходимости требуя помощи, желательно с подсказками на место, где ему нужна помощь. Но эта помощь маппинга как бы сбоку от данных и только там, где сбоит автовывод. Примерно как в самом DDL SQL. Можно PK, References указывать для полей при создании таблицы, а можно отдельно Constraint.
Для меня, самая большая проблема, это ORM или SQL. Многие правильно отметили, для разных задач, разные подходы. Но редко бывает так, что проект не выбивается местами за рамки одного. Иногда хочется быстро переключиться на другую модель работы, а фиг. Это не два вида на задачу — работа в коде с табличными данными, а две задачи от хранилища и от кода, на один вид — данные.
Например поменять схему через DDL бывает проще. Но потом повторяй аналогичное в модели. Или чем ломать голову, написать SQL запрос, отладить его, а потом модель преобразует его в кодовое представление. Разных сочетаний множество. Прозрачно переключаться туда-сюда, не думая как удобнее сделать, а осмысливая что и зачем — ORM и SQL, через минуту SQL и ORM, еще через пять — снова обратно, код вперед. Синхронизация.
Например держать автогенерируемые модели в отдельном модуле, куда будут извлекаться все структуры, типы, связи, свойства (pk, uq, nullable, default, check). Надо надстроить — удобный механизм наследования. IDE проверит контракты и визард при необходимости поможет разрешить конфликты.
Не совсем то. О продукте речь не идет. Лишь личная возможность оценить. Посмотрите какие "метрики" дикции становятся заметны, выходят на первый план. Прослушивание предложениЯ и прослушивание предложениЙ, текста, вызывают разный отклик в сознании.
Кстати, возник еще вопрос — финальные "паддинги". Если они "продуктовые", не надо обращать внимания, само получится нормально после склейки, это одно. Помогают. Но если нужна коррекция, а паддинг плавающий, уже другое. Вредит. Он у вас постоянный? Не зависит от голоса и/или последнего предложения в задании? То есть надо или 0, или константа.
Здравствуйте. Перечитав на свежую голову нашу беседу, действительно нашел два пробела в аргументации.
Вопросы только к одному голосу — Айдар. А я почему-то обобщил их на весь проект. Прошу прощения. Однако, посмотрите на свой предыдущий скрин. Найдите во втором и третьем предложении позиции запятых. А если не зная текста, есть они там или нет, и не имея в подсказке других голосов? В отношении пауз между предложениям, может быть из-за малых внутренних пауз, может они действительно меньше, но складывается ощущение избыточной "компактности" голоса. Слышны слова, не слышно речи.
Нормально ли такое чередование, как утверждаете вы, или ненормально, как считаю я, без эталона не определить. Мой "эталон" других синтезаторов вы разумно отклоняете, но иного не предоставлено. Подумывал приложить еще образцов, но отказался. Сторонние данные психологически проще дезавуировать. Поэтому запишите запишите живую речь сами и посмотрите глазами на ее тайминги. Именно живую, обычного рассказчика "как я провел выходные", а не озвучивающего декламатора. Хотя может и на него стоит глянуть, не знаю.
Интересно, как вы тестируете? Предложу озвучить и прослушать рассказ на десяток-другой страниц. Обращая внимание не на голос, а на содержание. Насколько легко это будет. Насколько удерживается внимание. Насколько слышен сам текст. Ведь тестируя на коротких демо-фрагментах, некоторые моменты не привлекают внимания. А на длинных — становятся значимыми. Тайминги пауз, кмк из их числа.
Потому что не я делал демку.
По вашему примеру... текст должен быть чуть больше, либо уменьшить масштаб. И тут нет эталона. Нет сравнения. Сравнения не между вашими голосами, а с вашими голосами. Я же не сказал, что у вас совсем нет "артикуляции", лишь что она слабовыразительна, до полной потери.
Попросите в понедельник прочесть этот фрагмент кого-то из коллег, не особо привлекая к этому внимания, чтобы получилась речь в естественной среде. Ну либо просто забейте, если считаете это не важным, а мои реплики придирками. Так тоже может быть. До следующей встречи, коллега.
В таком нет. Но попробую близко.
Обратите внимание на структуру, чередование сигнал-тишина. Как для внутренней пунктуации предложения, так и между ними. В качестве образца можете взять абсолютно любой текст на ~1 минуту звучания, а в качестве эталона озвучку любым другим синтезатором, а лучше живую речь.
По данному примеру... например, в двух других голосах видна 1 запятая в первом предложении и 2 в третьем. У вас сплошной поток. И так далее по всему треку.
Да нет же. Монотонность создается отсутствием пауз. Должна ли пауза повествовательного отличаться от его длительности? Или длительности последнего "блока", от запятой до финала? Какая пауза должна быть на многоточии, тире? А у восклицательного и вопросительного?
Здесь не только гигантских моделей не надо, здесь вообще моделей не надо. Если предварительно разбить на предложения и озвучивать по ним. Достаточно отобрать несколько типов предложений, в зависимости какая гипотеза проверяется, проанализировать человеческую дикцию и вывести обобщенную закономерность. Не надо многих часов, пяток предложений тремя-четырмя обычными людьми, на гипотезу.
Слишком все бросились в нейросети. Решают квадратное уравнение через интегралы :)
Нужна регистрация для доступа к вложениям, вроде бы.
Ошибка не в конкретном месте. Мол везде хорошо, а тут. Ошибка в отсутствии. Системном. Лучше покажу в волновой форме. Основное внимание на диапазон 50-80% трека, но и остальное показательно.
Скрытый текст
Именно, что по фразе. В книге — заметнее. На счет интонаций, в обсуждении "ударятора" я писал, как по моему мнению, происходит окраска текста читателем при чтении книги. Поэтому копать надо в первую очередь в эту сторону. Дать слушателю крепкую основу для личной окраски — озвучить просодией структуру предложения, включая финальный знак.
Не надо понимать смысл прочитанного, надо понимать смысл структуры текста выраженный знаками препинания. Помните пример "выдры в гетрах", где 5 предложений с одинаковым текстом, по разному размечено пунктуацией. Вот именно ее и надо "прочитать" просодией. И только после уверенного преодоления этого этапа, начать окрашивать самому, выступая в роли декламатора, подчеркивающего смыслы.
Ссылка ведет на конкретный пост, а не ветку.
Прекрасно понимаю и неоднократно писал об этом. Вопрос в другом. Должно ли продуктовое решение уметь читать абзацы, речью давая понять слушателю, что текст содержит последовательность отдельных утверждений, восклицаний и вопросов? Это один из элементов оценки похожести на человека — монотонность дикции. Только если в предыдущем абзаце речь шла о монотонности в рамках предложения, тут монотонность в рамках более крупной структурной единицы.
Бесспорно. Скорость в 3-4 раза быстрее v3 и качество на X пунктов выше. А если бы скорость была равна, на сколько бы пунктов было выше качество? Вот это и хотелось бы глянуть. Любопытство, не более. Если что, к фонетике вообще непритязателен. Больше обращаю внимания на просодию. И тут вы прилично подтянулись. Надо еще послушать непрерывно пару-тройку книг, чтобы окончательно в этом убедиться (или опровергнуть).
Если не возражаете, можете прогуляться на 4pda. Откройте Айдара в аудиоредакторе. В лучшем случае, паузы 200 и менее миллисекунд. Если память не изменяет, рядовым является 400-750 мс. Особое внимание отрывку 30-48 секунд. Да, пунктуация там может непростая, но она есть. Можете убедиться по другим озвучкам.
При озвучке абзацев или не дай создатель, еще больших фрагментов — структура текста теряется. Не считаю это значимой проблемой — "Побить на предложения и вперёд". Но многие, если не большинство, будут использовать библиотеку именно так и впечатление будет соответствующее. Решение за вами.
Это вы про время, дату, температуру, координаты и римские цифры? Ну да, есть такая буква. И все они сводятся к уже описанному, согласовать слово с числом и число со словом. Остальные юзкейсы либо исчезающие, либо не детектируемые.
Покрутил "ручки", послушал демки — проект достойный. В первую очередь оцениваю с точки зрения приватного озвучивания книг, не особо напрягаясь вопросом лицензионной чистоты. Больше всего радует стабильность и (автоматизируемая) управляемость. Этой пары больше никто не предоставляет. А вот качество... еще один проект среди достойных, плюс-минус. Во главу угла была поставлена скорость и этот результат был достигнут. На CPU cопоставима с классическими SAPI синтезаторами старой школы. Было бы интересно глянуть, если бы не "стали в 3-4 раза быстрее", а разменяли скорость на качество, сохранив её как у v3 или лучше v4.
Из наиболее бросающегося в глаза. Предложения не выделены соответствующими паузами. Речь сливается. Более того, паузы часто меньше чем от запятой, а иногда и вовсе отсутствуют. Это в принципе исправляется вручную, вставкой тегов или генерацией тишины в коде. Но для режима "сделай хорошо" нужна встроенная поддержка. Которая заодно поможет решить проблему "при генерации сразу сильно длинного аудио скорость немного проседает". Разбивать внутри текст на предложения, например
razdelиз проектаNatasha(очень быстрый и качественный), озвучивать порциями, вставляя пустые межблоки в выходное аудио. Ну и заодно подумать о расширении интерфейса библиотеки потоковым методом. Уменьшит задержку между запросом и ответом. Не нужно будет ждать синтеза всего запроса.Число в текст, с учетом спряжений и склонений, количественной и порядковой формы, дело нескольких чел*часов. Правда я использовал PyMorphy.
Осталось выбрать из корпуса числа с контекстом (±1-2 слова), сгруппировать, разметить форму и обучить сетку. Которая потом и будет эту форму указывать дискретному конвертеру. Тут пока даже предварительных оценок нет. Но таки думаю, что не огромные, а просто большие.
Я тоже не знаю, поэтому и написал "возможно".
Однако речь немного про другое. Куда по сути этот подход и должен быть расширен — последовательное с накоплением. Мы же не учим учебник за раз. Тему за темой, параграф за параграфом, абзац за абзацем, тезис за тезисом. Используя на следующем шаге всю информацию предыдущих. А также уточняя их понимание.
Как писал в других темах, естественный язык это инструмент описания реальности. То есть языковая модель переводит с естественного языка на некий промежуточный, создавая модель этой реальности. Смысловая ей оперирует. И потом языковая выступает в роли вокодера.
То есть для изучения Rust нам не надо трогать языковую модель. Ни одного нового символа не появилось. Ну может кроме зарезервированных слов. Вся работа проводится в смысловой модели. Которая сама изначально должна быть построена на расширении, а не вытеснении или перестройке весов. И следовательно теряется смысл в этапных Hebbian-патчах. Точнее, они приобретают совсем другой смысл — фрагмента реальности с которым мы сейчас оперируем, быстрой памяти.
Эволюции это хорошо. Но возможно, данная, заведет процесс создания ИИ еще глубже в тупик.
Представим, что модель как-то обучена программированию и как-то знает несколько языков. Выходит новый. Для него пишется документация, учебник. Вот это переменная, вот это функция, вот это структура, вот это трейт, вот это модель владения, вот это... и так далее. Попросту представим что Rust вышел только сейчас. Скормив BDH эту доку, сможет ли он выучить язык?
Если есть обоснованное предположение, что структура функций не будет меняться, либо более сложная логика появится только в редких статус-обработчиках, можно еще больше упростить.
Скажу как читатель со стажем. Впоследствии перешедшим на аудио. Как декламаторов, так и синтезированное. Подход если не полностью, то существенно ошибочен.
Как сознание читает текст? В нейтральном ключе, последовательно строит фрагмент реальности. Видит знак препинания и фиксирует этот фрагмент в соответствующем ключе. Для вопросительного и возможно восклицательного, ища и подсвечивая точку внимания. Ретроспективно.
С печатным текстом иное невозможно. Там нет указаний на акцентирование. Что авторы учитывают, возможно подсознательно. Вопросительные и восклицательные статистически заметно короче и обладают более простой внутренней структурой.
А что же с аудио, создаваемому синтезатором по этому тексту? С хорошим декламатором, который подсвечивает точку внимания, в ближайшем будущем сравниться невозможно. Нужно понимать смысл. Без него, более целевое декламаторское интонирование, только повредит выучиванию. А с пониманием смысла пока беда-беда.
А что же надо? Достаточно интонацией уверенно "ставить" знак препинания. Обобщенно. Не мешая мозгу излишней ажиотацией, самому находить и подсвечивать эту точку. То есть стать подобным обычному чтению! Тем более, мозгу сложнее обрабатывать ошибки, чем достраивать нюансы. Лучше нейтрально обозначить знак препинания, который получен из текста, гарантированно, чем ошибиться во внимании, о котором нужно догадываться.
Как это сделать? Пара соображений есть. Но общий низкий уровень понимания говорит — не позорься. Думайте, вы больше в этом понимаете!