|
ru.algorithms
- RU.ALGORITHMS ----------------------------------------------------------------
From : Sergey Kovalev 2:5020/400 23 Jan 2002 11:06:09
To : Sergey Kabikov
Subject : Re: максимальное сжатие звука
--------------------------------------------------------------------------------
"Sergey Kabikov" <kser@elsov.ru> wrote in message
news:324953335@p2.f175.n5020.z2.ftn...
> Tue Jan 22 2002 15:35, Sergey Kovalev wrote to Sergey Kabikov:
[]
> SK> Если не нужно ничего "супер-пупер" по соотношению
> SK> качество/битовая скорость, то можно решать задачу в лоб
> SK> - строить линейный предсказывающий фильтр
> SK> (считать коэффициенты по Дарбину или еще как-то), сделать
> SK> детектор основного тона и возбуждать фильтр импульсами с периодом
> SK> основного тона. Передавать в поток квантованные коэффициенты ,
> SK> период и амплитуду возбуждения. Все!
> SK> Hа 2400 получается вполне прилично
> SK> и о разборчивости речи не идет - все более чем разборчиво.
> Гм. Получился примитивный LPC, ничем не лучше, чем тот же GSM. И нижний
предел
> разборчивости (при препротивнейшем звучании) около 4 кбит/с.
1) Понимаешь, хорошая сжималка обычно оптимизирована
под определенный битовый поток. Если ты будешь
GSM-й кодер использовать на неестественно
(для этого кодера) низких скоростях, то он будет
работать заведомо плохо. Хуже, чем какой-то
более простой кодер, изначально сконструированный
и оптимизированный под более низкую скоростью.
Под оптимизацией понимается
и выбор размера кадра и выбор какого-то конкретного способа
адаптивного квантования коэфф-ов (или наоборот отсутствие
такой адаптации) и наличие/отсутствие детектора пауз,
наличие/ отсутствие классификации звука на кадре
и еще море всякой мелочевки. Я сейчас не помню,
что там в GSMе, но не сомневаюсь, что на 2400 он будет
работать отвратительно.
2) Возможно, тебя ввело в заблуждение мое излишне
упрощенное описание кодера. Я имел в виду его основной скелет,
так сказать, принципы его организации.
Кроме скелета должно быть и мясо. По умолчанию безусловно
предполагается много мелочей, каждая из которых не очень существенна,
но вместе они значительно сказываются на размере битового потока.
Hапример, там обязательно должно быть разностное
кодирование величины основного тона,
а поверх разностей обязательно должен стоять Хаффман, аналогично
с амплитудой возбуждения, не забыть поставить фильтр перцептуального
предыскажения речи и т.д. и т.п. Эти мелочи хорошо известны
и есть в том или ином виде практически во всех компрессорах.
Поэтому они мной отдельно и не упоминались,
а предполагались по умолчанию как обязательные атрибуты.
> Ты уверен в этом утверждении ?
>Если да - приведи аргументы (разрядность квантования etc).
Собственно, у меня и в мыслях нет кого-то в чем-то _убеждать_.
Мне это не интересно.
Я просто делюсь информацией, в которой уверен. Могу и не делиться.
Я уверен, тк сам писал программу. Правда, это было лет 7 тому назад,
и некоторорые нюансы(разрядность квантования etc) я сейчас,
конечно, забыл, но основные параметры компрессора хорошо помню.
И, конечно, есть исходник. Делалось под заказ, так что исходником
поделится не могу.
SK
--- ifmail v.2.15dev5
* Origin: HOME (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
