enderhi72 писал(а):
Да все гораздо проще, на диске записан лишь код, а частотка ( 20 Гц - 20 000 Гц) генерируется в цапе, вот отсюда и всякие горбы и тд., нужен лишь высококлассный цап и качественный выходной каскад сидишника или чего там еще, и все будет в порядке. ИМХО как то так.
Не совсем так. Непосредственно форма волны в аналоге - да, цап формирует (ну условно), но команду для цапа на построение этой волны - формирует достаточно много элементов цепи.
Например, начиная от диска СДДА, который в мр3 или лосслесс грабят, потом передают на носителе и воспроизводят на медиаплеере, форма волны для конечного цап в системе Серёги будет примерно такая цепь (грубо, только наиболее влияющие узлы):
1. привод (мех. стабилизация системы считывания, уровень светового потока лазера, напрямую влияющий на правильность считывания - ведь СДДА не имеет обратной связи системы коррекции ошибок и привод не знает, верно ли он на самом деле считал данные, алгоритм правки обнаруженных ошибок в считанных данных (правятся до вероятного правильного значения), трансформация выправленных данных в более общественную форму (спдиф, например, либо внутренний интерфейс привода, работающий на ином уровне в систем - если речь о ПК, там же возможен другой контроль за ошибками, но суть мало меняется, меняется программное исполнение корректора)
2. трансформация хранящихся не сжатых данных в файле (не рав, РСМ, но форма волны сохранена полностью + добавлено описание данных) в некий формат со сжатием (с потерями "ненужных" данных - например, мр3, или лосслесс - принципиально подобие того же зипа - т.е. до полного восстановления формы путём точного (точного - это 1:1 - как было) рассчёта выкинутых при сжатии избыточных данных, тут нужно сказать, что форма сигнала восстанавливается с отличиями от первоначального РСМ в файле только когда речь идёт о форматах с потерями, либо когда железо декодера не справляется с расчётом слишком сильно упакованного лосслесс - степень сжатия напрямую влияет на время, необходимое для декодирования, по идее слабый проц может не справиться с такой задачей - ведь данные идут потоком), в случае мр3 - очень сильно форма сигнала зависит от кодера (его настроек, типа, версии).
3. декодирование - очень важный этап, очень многое зависит от декодера, об этом я выше писал (добавлю только, что, например, в случае мр3, несмотря на похожесть алгоритмов декодирование происходит немного разными принципами, в результате оди и тот же файл может кардинально различно "звучать" на разных декодерах (ну, т.е. плеерах с железно-программной реализацией декодера)
4. формирование потока в общественно-доступной форме (ну вот спдиф, например) - по идее тут всё жёстко, ибо прописано и соблюдается всеми, но и тут "возможны варианты", так как реализация цифрового интерфейса у нас на аналоговых цепях
плюс, вернее минус - этот самый спдиф вообще не имеет обратной связи, поэтому теоретически то, что ушло на трансформацию - не факт, что будет воспринято верно ответным девайсом
5. собственно сам ацп - вариантов реализации и главное - результата - наверное ещё больше, чем в п.3
учитывая п. 3 и 4 - его работа зависит от того, что ему подсунут в первую очередь, ну и конечно же его "обвес" сыграет финальный аккорд
6, 7, 8 - далее аналоговые цепи, это уже удел местной аудитории, там "возможны варианты" от физ. реализации до мистической составляющей.
Как видно, в нашем конкретном случае пункты 3 и 4, имеют прямое влияние на форму звука для АЦП, так что в данном конкретном случае нельзя сказать определённо, что АЦП - панацея от всех бед. Нет, это лишь один из участков большой дороги. Важный, но не определяющий всё и вся.
Ессно это очень грубая схема, просто нужно понимать, что менять тут Серёге лучше источник целиком, ибо декодер айконбита может врать. И выдавать враньё в спдиф, аналог, хдми - куда там ещё, все интерфейсы после декодера в этом плане без разницы. Как-то так.