AleXH

@Evgen1, с АС, ибо это самый дорогой и долгоживущий в системе компонент. Под них уже подбирается усилитель.

@spongebob, использование рамдиска имеет смысл только в режиме DI - чтении без допбуферизации, рамдиск позволит свести задержки доступа к минимуму, но как бы не был "быстр" рамдиск - прямое чтение из памяти в режиме FM быстрее всех. Использовать связку рамдиск + FM бессмысленно. @Vshap, оптика на матплате проигрывает оптике на дискретной карте, и тем более проигрывает оптике на хорошей дискретной карте - в первую очередь из-за бОльшей зашумленности питания, что приводит к бОльшему джиттеру. Как соотносятся величины задержек доступа к системной памяти (для встроенной оптики) и к кэширующему буферу ДК доподлинно сказать сложно - всё зависит от конкурирующих процессов в ОС, использованной элементной базы ЗК и тд. Не стоит забывать также и про необходимость битпёфектности - обеспечивает ли её ЗК, будь то встроенная или дискретная. - Последующее изменение уже сведённого материала, как правило ухудшает разрешение. @audioshock, DI и FM отличаются не только подходами к работе с данными, они отличаются также и юзабельностью (потребительскими качествами). Почему DI нужен рамдиск, сказал выше. Если памяти физически недостаточно для размещения в ней файла целиком, и при этом в ОС нет рамдиска соответствующего размера, то нужно использовать не DI, а standard.

На это я уже дал ответ выше, читайте внимательнее.

Евгений, если в терминале линукса звук лучше, чем в гуи окон, то о чём это говорит? - Полагаю о том, что процесс передачи данных в ЗК меньше "дёргается", меньше перезагружается конвеер ЦП и его кэш. - В виндовс куча параллельных процессов, драйверов, сервисов и др. "хлама" не относящегося к процессу звуковоспроизведения, что в итоге оказывает негативный эффект на звук. Если это так, то каким образом параллельное чтение, декодирование и последующая запись в память помогает улучшить звучание по отношению к прямому чтению из памяти?

прибавку цифровой грязи по отношению к FM? - сомнительное приобретение.

Рамдиски обслуживают драйверы, написанные разработчиками этих рамдисков. Соответственно код разный и влияние, оказываемое на звук скорее всего тоже разное, вопрос лишь в степени влияния. Если использование параллельного воспроизведению чтения из ФС рамдиска с последующим декодированием в память даёт лучший, по вашему мнению звук, чем чтение из памяти данных декодированных ДО воспроизведения, то... либо тракт кривой, либо само понимание "лучшего". Ибо отсутствие конкурирующих исполняемых процессов благотворно сказывается на конечном звуке - звук приобретает бОльшую прозрачность, разрешение, микродинамику. Конечно лишь в том случае, если тракт позволяет это услышать. Но поскольку изменение АЧХ, либо наполнение звука "левыми гармониками" (которых быть не должно, да и не гармоники это вовсе, а порождённая софт джитером цифровая грязь) субъективно гораздо заметнее, чем три выше названные характеристики, то на недостаточно прозрачном тракте для кого-то "наполнение" может быть более желанным, приводя к искажению понятия лучшего звука. Мой опыт показывает - меньше латентность системы - выше прозрачность, разрешение, микродинамика. Именно эти характеристики определяют качество звука с PC. Забота о правильной АЧХ должна лежать на самом тракте. К сожалению платформа PC не ориентирована под бескомпромиссное звуковоспроизведение с синхронизацией всех протекающих процессов, она (платформа PC) создавалась для универсальной асинхронной многозадачности, что и приводит к понятию "софтджитера" - совокупности мелких задежек, возникающих как на аппаратном, так и на программном уровнях, и оказывающих влияние на итоговый звук lossless плейеров. Если все lossless плейеры звучат одинаково, то это говорит о том, что последующий тракт недостаточно прозрачен для обнаружения разницы. Само по себе это не есть плохо, вопрос в абсолютных значениях - ведь разницу можно нивелировать и аппаратными буферами с синхронизацией от цапа, и чем лучше исполняет свою функцию этот компонент, тем в меньшей степени мы зависим от PC и его "капризов". Всё выше сказанное исключительно моё ламерское ИМХО.

Ну это совсем уже в лес

@audioshock, зелёный фломастер имеет гипотетическую основу - поглощение красного луча на позелёнённых ободах внутри и снаружи, распростаняющегося в толще диска путём многократного отражения на границах разных сред. Край диска когда вращается - дрожит, и мол поэтому преломлённые отсветы луча могут попать на линзу, поэтому в первую очередь нужно красить внешний край, а внутренний заоодно, раз уже фломастер в руках. Я 20 лет назад покрасил один диск, но результата не услышал, а вот CDR да, слышны своей пленностью.

Если для алюминиевого диска нужен демагнитизатор, то всё очень плохо в голове..., правда неизвестно в какой - в лазерной, или... Проблема CD плейеров - следящая система, помехи от её работы, а главное количество ошибок с которыми читаются данные. Коды Рида-Соломона не всесильны, к тому же от процессора восстанавливающего данные тоже идут помехи. Всё это счатье приезжает в цап, ну и там имеем результат. Правда уровень помех с ПК не сравнить, ПК это страх и ужас в этом отношении. В Hi-End индустрии много лохотрона, но если деньги девать некуда, то почему бы и не купить демагнитизатор КД Я бы понял ещё, если бы это был какой полировщик карбононового слоя.. Но если чистым дискам (не представляю себе коллекционера с пилиными или грязными КД) требуются приблуды для того, чтобы читать диски без ошибок, то очевидно, что проблема совсем не в дисках, а в следящей системе проигрывателя. Либо владелец настолько привык к ритуалу, что камертон в голове иначе не настраивается.

К тому же надо учесть, что даже болванки "For Audio" не обладают такой же отражающей способностью как алюминиевое покрытие прессованных обычных дисков, что приводит к потерям: разрешения, микродинамики, прозрачности. Обычные же диски для данных имеют столь мутную поверхность, что потери гораздо более удручающи - ощущение, что звук становится уже ближе к mp3, чем к lossless. Лучшие из CD-R по качеству отражающего покрытия, что мне доводилось видеть - TDK CD-R74, но и они уступают прессованным дискам.

можно на форум им написать. кроме мингуя можно к нему и другой гуй прицепить, тот же гном.

@sannik, не поймите превратно - я без претензий, наоборот спасибо за попытку помочь. Я в недоумении как так можно писать софт с претензией на генератор для радиогубителя, а в нём даже крутёлки почеловечески не сделать - какой прок от такой поделки, зачем было тратить время? - Если только автору сам процесс нравится...

@sannik, а Вы попробуйте: 1. попадите в конкретную частоту, если шаг прокрутки несоизмеримо шире и не регулируется 2. найдите диапазон частот - а как его найти, если возбуд возниает лишь тогда, когда на входе частота -генератор возбуда. 3. переберите вводом значений пару сотен 4. свип пролетает и даже не успеешь понять, что возбуд был. А учитывая, что свип перебирает частоты процентно от частоты, то шаг в процессе перебора становится всё шире и шире. К тому же в программе кривая реализация свипа - семплы рассчитываются заранее и их количество ограничено относительно невысоким значением. Программист генератор написал, а толку с него 0, зря потраченное время на написание - пользоваться им в боевых условиях невозможно. Такого ПО хватает, когда программисты ПО пишут, но не понимают что они пишут и для кого - юзабилити ниже плинтуса.

В нём нет возможности плавно и точно изменять частоту в реальном времени, т.е. найти частоту возбуда не получится.

Игорь, можно ли использовать АП для запуска VST синтезаторов,органов, роялей и пр. - чтобы играть на них в реальном времени? Положил DLL ComboF в VST32 (точнее хардлинк на неё) - АП конфиг не видит её. И не попадался ли вам бесплатный генератор синуса, импульсов и тп. с точной регулировкой частоты в реальном времени для удобного поиска возбудов, резонансов и тп. в аудиотрактах, помещениях?

борда обратные слэши не пропускает

@giclee, AP2110/EXTRAS/ASIO/RegCopy/regcopy.txt

300-400МБ для образа слишком жирно - лучше мелкий, быстрее загружаться будет. TinyCore 16МБ вместе с простеньким GUI, можно на базе TinyMPD сделать.

Именно из-за разнообразия дистрибов линукса с непонятным эффектом на выходе, я и предлагал сделать liveCD на основе мелкого TinyCore-MPD, который можно загрузить Grub4Dos'ом с винта, либо флешки в память и послушать, что предлагает линукс.

одного PAE не достаточно?

Игорь, под winxp опция в boot.ini /3GB что-то может дать АП?

изменённые файлы можно сохранить на носителе, а потом вживить в iso. У меня XGUI не стартует, в tc@box всё останавливается - пока не разобрался что дальше делать.

тот не патченый на рилтайм, но в любом случае интересно - если есть разница в звучании с основным линуксом, то в какую сторону? И какой вариант - х86 или х64?

Я исходил из того, что хорошо бы изначально иметь некий звуковой маяк-ориентир с минимальным разбросом.

Под mpd, в который вносит диффы Анисюткин был в своё время дистриб TinyCore с рилтайм патчами. Имхо перед тем как бегать по своим граблям, имеет смысл обратиться к нему, может поделится своими соображениями куда и как лучше копать.