Это не "лучше", а другой тип детектора (среднего, а не пиковый). А можно еще детектор среднекватричного значения сделать - но (+) («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

[an error occurred while processing this directive] Это не "лучше", а другой тип детектора (среднего, а не пиковый). А можно еще детектор среднекватричного значения сделать - но (+)

(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Отправлено SM 19 февраля 2005 г. 19:37
В ответ на: ну а еще лучше может быть(+) отправлено -=Electrovoicer=- 19 февраля 2005 г. 19:35

если задача, как сказано, не допустить перегруща АЦП - то пиковый однозначно и безповоротно.

Составить ответ ||| Конференция ||| Архив

Ответы

я почему то подумал о звуковых сигналах, для которых АРУ лучше делать по какому-нибудь среднему значению. а то(+) — -=Electrovoicer=- (19.02.2005 19:44, 86 байт)
- Не портит пиковый детектор звук, все зависит от постоянной времени. А вот перегруз кодека еще как портит. — SM (19.02.2005 19:49, пустое)
  - Более того - кодек после перегруза очухивается хрен знает сколько времени... — SM (19.02.2005 19:49, пустое)
    - в студийных комрпессорах-лимитерах видел(+) — -=Electrovoicer=- (19.02.2005 20:06, 133 байт)
      - ну все верно - главное оцифровать сигнал так, что бы (+) — SM   (19.02.2005 20:12, 303 байт)
        
        ну да они потом гады пишут что SNR 147db. а это с учетом всех хитростей, а не реальный SNR — -=Electrovoicer=-   (19.02.2005 20:19, пустое)
        
        Я вообще-то про расширение ДД говорил. АРУ с его последующей компенсацией это отнюдь не для улучшения SNR... — SM   (19.02.2005 20:30, пустое)

Перейти к списку ответов ||| Конференция ||| Архив ||| Главная страница ||| Содержание ||| Без кадра

E-mail: info@telesys.ru

Ответы

Отправка ответа