- порядок беклога и роадмапа назначен слоями: проверки, которым можно верить → долги входа → владелец записи и контракт API → конвейер под тестами → приложение и возможности поверх; у каждого движения записана причина; - заведены восемь задач под пункты «Завершения», которых не закрывала ни одна запись, — цель any-audio-source была без задач вовсе; - у четырёх задач сняты критерии, требовавшие того, что делает задача ниже по очереди; исправлены ссылки на несуществующий repo/sqlite и на отменённую разведку об очереди.
2.2 KiB
🔬 Потолки SpeechKit по длине записи и по формату
- Тип: research
- Категория: Очередь — Долгие записи начинаются с замера: без потолков ни отказ на приёме, ни резка не проектируются.
- Зачем: Потолок длины записи и перечень принимаемых форматов неизвестны, а цель про долгие записи без них не начинается.
- Теги: goal:long-recordings
Цель «запись длиной в несколько часов доходит до текста» упирается в то, что неизвестно, на каком звене такая запись отваливается. Начинать с переделки приёма или с деления записи на куски — разные работы, и выбор между ними определяет замер, а не рассуждение.
Отдельно висит расхождение: конвертер отдаёт ogg/vorbis (libvorbis), а
SpeechKit получает заявку ContainerAudio_OGG_OPUS. Работает ли это и что
происходит с записью — не разбиралось.
Вопрос
Какую самую длинную запись модель deferred-general доводит до текста, что
происходит при превышении и какие контейнеры она принимает на самом деле.
Куда ляжет ответ
docs/research/speechkit.md — числами и с командой замера. Ответ на вопрос про
OGG_OPUS уходит туда же и снимает открытый вопрос из
architecture.md.
Рамки
Замер идёт за деньги: распознавание и хранение в Object Storage оплачиваются по факту. Число прогонов и длину пробных записей назначает человек. Боевые записи пользователей для замера не берём.