[Homeros] I: Обновление образа дистрибутива ALT Linux Homeros Friend

[Michael Pozhidaev]

> Идея не в том, чтобы заменить им mp3, а в том, что это должен быть
> обязательно поддерживаемый формат, т.к. это позволяет получить на
> выходе практически любой другой (то есть у пользователя есть выбор,
> которого у него нет, если единственным форматом сохранения будет mp3
> -- сжатие с потерями). Кроме того,  реализация сохранения в wav/pcm
> требует минимальных усилий и лишена ряда проблем, сопровождающих mp3.

Окей-окей, без вопросов.

> К тому же предполагается, что программа позволяет указать размер
> фрагментов, на которые разбивается исходный текст. Тогда скриптом или
> командной строкой можно пустить внешний кодер, который параллельно
> будет кодировать в нужный формат уже готовые wav-файлы и удалять их.

Ну это само собой. Без этого, согласен, никак. Думаю, будем указывать в
секундах со значением по умолчанию в пять минут.

> aac.

А этот-то зачем? Если в случае speex понятно, что он заделан на упаковку
речи, что актуально для нашего случая, то aac осмыслен только в случае
существования железок, играющих только его. Да и то лучше, если
более-менее популярных.

> Однако вопрос в том, надо ли писать очередной sox  или конкурировать с
> имеющимися утилитами сжатия аудио для конкретных форматов(это
> относится и к идее с плагинами)? Или лучше предусмотреть в
> конфигурации набор командных строк для вызова внешних
> конверторов. Вызов таких конверторов из самой программы улучшил бы
> синхронизацию по сравнению с вызовом из внешнего скрипта. 
>
> Насколько я понимаю, встроенного менеджера медиа-кодеков HomerOS не
> имеет, поэтому идея с плагинами, как ни крути, предполагает много
> велосипедной работы. 

Анатолий, прошу прощения, но тут я в принципе не понял, что Вы хотели
сказать. При вызове упаковщика из командной строки надо как-то
передавать формат потока, а в теории каждый упаковщик может иметь свой
отдельный синтаксис. На этом, собственно, всё и
заканчивается. Синтезаторы имеют разный формат аудио-данных, включая
почти нестандартные, как частота дискретизации у ru_tts.

К тому же не ясен остался смысл фразы: "Вызов таких конверторов из самой
 программы улучшил бы   синхронизацию по сравнению с вызовом из внешнего скрипта".

Какая синхронизация? Какого скрипта? 

> Другой аспект: кодирование в mp3 является лицензируемым (скорее всего,
> что и кодирование в aac тоже). В лицензионно чистой сборке
> сомнительных кодеров быть не должно, либо вам придется делать
> соответствующее предупреждение и получать согласие пользователя, на
> то, что он использует проприетарные кодики под свою ответственность. 

В России не действуют патенты на алгоритмы. Поправьте меня, если это не
так. На этом, собственно, опять всё и заканчивается. Я следил за
историей h.264, кажется, что это тот же самый случай. Заимствований кода
в lame нет, так что пока сидим нормально. Если законодательство других
стран, где может использоваться русскоязычный Homeros, отличается от
российского, наверно, мне надо быть в курсе. В любом случае, в наличии
возможности упаковки преступления нет, а пользоваться ею или нет -
каждый способен решить самостоятельно. Не знание закона, как известно,
не освобождает от ответственности.

-- 
Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/