willow

Рекомендую Вам обратить внимание на shared mode режим работы WASAPI. Технически этот вариант имеет преимущества над WASAPI Exclusive и ASIO и даже DS в ключе совместимости и надёжности.

...что не делает из ASIO2KS полноценного ASIO. Теоретически, от чистого ks можно добиться наиболее оптимальной работы. Хотя ситуация, когда от перемены мест слагаемых результат меняется, и удручает непредсказуемостью, но есть в этом и положительный момент - не всегда самое простое решение лучшее, т.е. при прочих равных не обязательно опускаться до примитивизма ведь результат всё равно непредсказуем ибо субъективен. Другими словами, технически более 'прямое' решение в субъективной оценке может проиграть более сложному и комплексному решению. И здесь мы подходим к следующей важной мысли, что в попытке достичь наилучшего результата многие плееры следовали концепции примитивизма, т.е. рудиментации своих основных функций, интерфейса, модульности. И неизбежно вытеснялись субъективно более успешными связками модулей. Пользователь делает оценку согласно своему слуху, вкусам и имеющемуся у него в наличии оборудованию у которого обязательно есть индивидуальные недостатки. Неукоснительно избегая примитивизма модульный винамп дожил и до наших дней. Поэтому и настоящий аудиофильский плеер должен быть модульным ИМХО. Субъективно, звук через эмулятор вполне может обыграть родную реализацию вывода звука.

Являются ли такие настройки губительными для звука с технической стороны? Asio buffer latency 1-300ms:2ms (88 samples) и Asio buffer size 0-63:2 Я чувствую при уменьшении задержки звук яснее, ихмо. каковы оптимальные настроки чтобы защита от опустошения буфера работала? С чем лично не имел дело за то додумывать не могу. ASIO вывод сам не делал. Эффект от уменьшения буфера есть, я его могу объяснить по крайней мере меня самого устраивающими версиями-причинами. Но объясняется это лишь до определённого момента. Интересен факт самой возможности стабильной работы на таких крошечных буферах. Проблемы должны в теории проявляться писком, т.е. чередование крошечных фрагментов с тишиной. По размеру буфера - нужно знать сколько "колец (зацикленных потоков) управления" контроллирует процесс проигрывания звука ибо каждый поток может буферизировать результат своей работы (копирование это тоже работа, у декодера тоже буфер). Каждый буфер это плюс в смысле защиты но минус в смысле качества звука (допускаем такую взаимосвязь). В любом случае от множества мелких буферов на разных потоках толка совсем нет, важны лишь ёмкие буферы одного потока. Чем ниже уровень (ближе к устройству), тем существеннее вклад буфера в смысле защиты. От опустошения может спасти только размер буфера, но не его задержка. Просто часто ошибочно принимают задержку=размер. Как я понимаю, пожалуйста поправьте меня, буфер ASIO устройства считается как latency*2^size. Т.е., как я понимаю Ваши настройки, речь идёт о четырёх 2ms блоках. Да, это очень низкая задержка и очень маленький буфер, а качество - качество вы оцениваете сами. Самый достоверный факт тот, что у размера буфера устройства нет ориентира и оптимальной величины. Он функционирует пока может функционировать в реальном времени или пока что-то не помешает ему.

Рассматриваемый плагин реализован с пониманием и не вызывает отторжения в плане излишеств. Kernel Streaming plugin для Winamp написан Chun Yu Shien в 2002. Позже разработку продолжил Steve Monks в 2005 году, подлатав последнюю на тот момент 2.5 там и тут. В 2006 Steve стал решать главную проблему - заедание звука на некоторых системах, для этого он выделил проигрывание в отдельный поток со своим собственным буфером. Микро-плеер в плеере, это частое и интуитивно понятное техническое решение, для winamp это классика. По ходу дела добавил бесшовное воспроизведение и небольшие полезные дополнения. А потом исправлял то, что поломал в нововведениях. Звук может заедать по разным причинам. Малый размер буфера установленного пользователем, плюс особенности системы, звуковой карты и операционки. Особенно плохо то, что заедания звука очень трудно диагностируются, возникают в произвольный момент. Общая рекомендация разработчиков это увеличение буфера устройства. Упрощённо проигрывание в любом плеере устроено как большое кольцо, опрос - декодер - вывод, и по-новой. Более стабильный результат по равномерности проигрывания, как правило, даёт схема опрос - вывод без декодирования. Для этого в элемент вывода большого кольца вводится мини-плеер опрос-вывод. Простой вариант: программный поток 1/1: опрос устройства -> декодер -> вывод на устройство Надёжный вариант: программный поток 1/2: опрос памяти -> декодер -> вывод в память программный поток 2/2: опрос устройства -> вывод на устройство Как мы видим, первый вариант весьма чувствителен к различного рода нагрузкам. Приоритет потока это ещё не панацея. Нагрузка любого происхождения разрывает кольцо и тормозит исполнение единого исполняемого потока и всех связанных с этим процессом ресурсов. Крайним заложником такой тяжёлой ситуации всегда оказывается буфер устройства, ему и компенсировать все выпавшие миллисекунды простоя. Собственно, по словам Peter Pawlowski "вывод звука с 'малой задержкой' абсолютно бесполезен для проигрывания звука ибо убивает защиту от опустошения [выходного буфера]" с чем я согласен как разработчик.

Blash Все настройки максимально честные и спроектированы для качественного воспроизведения. Но у каждой настройки своя цель. Успеха в настройке не будет пока пользователь не определится с целью. Поскольку Ваш вопрос частый, то опции спроектированы следующим образом: Подобная комбинация опций форсирует режим сквозного копирования данных. Но, разумеется, не обещаю что такая настройка будет оптимальна для Вашего случая. Даже крайне тщепетильные в вопросах невмешательства в звук пользователи, хорошо разобравшись в настройках разрешают, к примеру, выборочную обработку данных. У каждого пользователя свои нюансы и особые запросы. К примеру, внешний дак не поддерживает 88khz но поддерживает 96khz - и пользователь, разумеется абсолютно согласен выборочно применять ресемплер. И прочая, прочая. Настройки зависят от целей и ситуации - неправильных или некачественных настроек в плагине нет. В сомнении, можно перебрать различные варианты и самостоятельно решить об использовании той или иной возможности предлагаемой плагиной. Если сформулируете свою задачу - то подскажу конкретные опции.

akalibr Хорошо когда вопрос благополучно разрешается! Хуже когда файлы "сами по себе" начинают портиться, например, когда контроллер жёсткого диска начинает тупить. Обнаружить такое очень трудно. Как правило, на lossless и вылезает. Всегда внезапно.

akalibr Спрашивайте со слухачей, что рекомендавали Вам крутить винду и согласующие задержки устройств. Накрутят, а потом глюки ловят ни в сказке сказать ни пером описать. У каждого устройства и его подсистем свои собственные задержки, они всё равно своё возьмут, джиттером ли, глюками, зависонами. Иной дак и по-хорошему не работает - но прожжёному аудиофилу добрый совет как с гуся вода. Это фубар кривой, ага. 50% битый файл, 50% сами накрутили. Скорее, последнее.

При 32 бит взаимодействии действительно есть проблема нехватки мантиссы числа для целевых 24 бит. В 24-битном целочисленном PCM потоке тоже есть знак, то есть, те же 23 + 1. Без DSP преобразование "Fixed point 24 -> Floating point 32" является обратимым. Спасибо за поправку насчёт знака. Но сути это не меняет, младший бит всё равно шумный из-за природы экспоненциальной формы числа. Ситуация осложняется наличием нормальной и нормализованной формы числа. Говорить про те же 23 бита нельзя, они вовсе не тождественны, ты верно попутал с фиксированной точкой где также используется двоичное дополнение как и в int. Хотя, как ни странно, перевод числа туда-и обратно является обратимым процессом. Обратим, потому что округление "подгоняет" число в нужную сторону - но лишь при условии, что ёмкость мантиссы достаточна. Не уверен, сохранит ли 32f весь диапазон 24i. Что лично сам не проверил, за то не отвечаю. Весь диапазон значений не тестировал, я лишь концентрируюсь на шуме чисел. Применительно к DSP модулям, они выполняют какое-то действие а не просто копируют значение, следовательно оперируют с шумом на входе и выходе. При приближении к единице, мантиссы числа начинает не хватать под остаток дроби, что увеличивает шум. Вот здесь и страдает младший бит. Эффектом обратимости я и сам пользуюсь, только вот 32f не использую конкретно для звука. На 16 бит хватит, а вот на 24 - неуверен, очень высокая погрешность - он же источник шума. Потом дизерингом маскировать это дело придётся.

Omelya.A. Это совершенно разные Latency! Конечно, это не моё дело но не ломайте то, что хорошо работает . ВЫ же делаете вещи прямо противопоказанные качественному звуку . Для качественного звука нужно как раз-таки увеличивать Latency. Уменьшают задержки те, кому критически важен мониторинг собственной записи. Там просто другого выхода нет, у Вас тоже "горит"? Тогда совсем другой вопрос, без альтернатив.

Я обозначил проблему фубара связанных с особенностями организации битперфекта. С самим битперфектом проблем нет. Но чтобы правильно регулировать громкость нужно одновременно расширить разрядность чтобы увести шум вычислений из слышимой области. Это необязательно, но на мой взгляд очень желательно. Касательно подключаемых модулей, да, за точность вычислений лишь они одни и отвечают. При этом, 32 бит межмодульные связи при длинном графе (длинной цепочке модулей) становятся узким местом. Как уже было сказано в предыдущем моём сообщении при 32 бит сцепке теряется 24-й бит. Но вообще, применительно к звуку точность очень условна, при низкой точности вычислений просто растёт шум и всё. Шум всегда есть, но при большой точности вычислений он уходит в неслышимую область, его становится неотличить от естественного фона записи. За точность конкретного модуля может отвечать лишь автор модуля. Фубар, насколько мне известно, отвечает лишь за регулятор громкости. Но это речь шла лишь про машинную погрешность. Здесь важно упомянуть о математической погрешности. Звуковая обработка предполагает конечную точность абстракции физических явлений, здесь присутствует естественная для таких случаев математическая погрешность. Уже даже не машинная, а математическая. Поэтому конечная точность эффекта определяется умножением машинной и математической погрешности. Поэтому 64 бит могут звучать хуже чем 32 бит - это зависит от применяемой математики.

Обсуждая разрядности старайтесь приводить ссылки на авторские комментарии, т.к. в вычислениях много кто участвует, зависит от применяемых модулей. Основопологающими являются разрядность входа-выхода и разрядность аккумуляторов. Вот разрядность аккумуляторов и определяет точность результата, а именно, напрямую влияет на уровень шума (если всё остальное сделано прямыми руками). Биты для 32 бит числа Вы точно распределили, т.е. куда и сколько. Но никто в здравом уме не будет производить вычисления на 32 бит аккумуляторах. Кому интересно почему - почитайте что такое нормализация чисел и в чём она заключается. С 32 бит аккумуляторами мы можем говорить лишь о том, что целью вычислений является 16 бит выход в лучшем случае. Внутренняя точность представления числа зависит от применяемых плагин обработки, поэтому однозначно говорить о точности нельзя если, конечно, о точности вычислений не говорит сам автор программы или плагины. Что меня привлекло в вашем сообщении - это утверждение про 128 бит обработку звука в Cplay. Нет таких аккумуляторов в современных x86 процессорах. Их можно только эмулировать, и я сам успешно строил настоящую 128 бит обработку звука. Скажем так, эмуляция 128 бит работает не просто медленно а феерично медленно. Зная проект Cplay, не будет он заниматься таким непотребством. Скорее всего, имелось в виду поддержка SSE расширения где регистры 128 бит. Но вот аккумуляторы-то там действительно либо 32 либо 64 бит. В фубаре точность вычислений так-же зависит от модулей. Межмодульное взаимодействие вполне может быть 32 бит, но это вовсе не говорит о том, что обработка происходит в 32 битах. Например, ресемплеры в фубар - 64 битные. APECR, я лишь прошу чтобы вы не путали народ. Есть проблема точности обработки а есть проблема точности межмодульного взаимодействия. При 32 бит взаимодействии действительно есть проблема нехватки мантиссы числа для целевых 24 бит. В фубаре на максимальной громкости работает битперфект, а на низкой громкости в силу природы плавающего числа проблема нехватки мантиссы снимается. Может лишь слегка проявится собственный шум вычислений на громкостях, близких к 100%. Но это вообще не проблема, в сравнении с другой проблемой фубара - то, как организован битперфект. При попытке вклинить вычисления типа простенькой громкости, целевыми остаются 16 бит! Вот здесь шум квантизации (представление линейной величины дискретным числом) идёт такой, что проблема шума 24 бита просто меркнет. Речь уже начинает идти о шуме в 16-м бите - независимо от точности вычислений конкретно применяемых модулей!

Действуйте по необходимости. Владельцам стерео там делать особо нечего. 5.1 дорожку, к примеру, плагин и так Вам сведёт в стерео с настройками по умолчанию (если, конечно, вы не включите необдуманно опцию "Slave to input channels"). Микшер нужен считанным людям с кинотеатрами и лишь один пользователь плагины попросил меня предусмотреть возможность балансировки канальной матрицы программно. Так что, зависит от ваших задач. Да, это взаимоисключающие и взаимозаменяемые модули. Можно, конечно, задействовать активным только одного однако случайно можно задействовать оба. При желании Вы можете сделать копию плеера с другим APE декодером и сравнить + и - обоих. Наиболее оптимальную с технической точки зрения работу своего модуля я могу гарантировать лишь с Maiko WASAPI. Этот процесс я просчитываю детально сам, за другие же не могу ручаться на 100%. Дело не в совместимости, а именно в оптимальности решения. Полноценные решения должны быть завершены концептуально и обдуманы от и до.

Ранняя альфа, конечно будет, это будет версия 0.00 Проводится чрезвычайно кропотливая серьёзная работа. Поэтому не могу давать никаких сроков. Играющий прототип декодера существует, но только для внутреннего пользования. По многим нюансам я могу доверять лишь собственному слуху, и совсем уж сырой продукт я не могу выпускать. Хотите верьте, хотите нет - но Maiko WASAPI отпочковалась из проекта Maiko MPEG и до сих пор является важной составной частью mp3 декодера, полностью несёт в себе транспорт, постобработку, анализаторы. Maiko WASAPI это не тупой транспорт, мне такой оголтелый битперфектизм не нужен, переболел уже. Я продумываю максимальную отдачу и эффективность работы начиная от битов на жестком диске до колонок, на любом оборудовании и настройках. То, что фрагмент mp3 декодера сейчас используется как самостоятельная единица это результат тщательно продуманной архитектуры, изначально такого плана не было. Изначально в концепции было что-то вроде плагин Игоря "всё в одном", но ушёл от этого. Игорь же напротив, пришёл к этому, и я желаю ему успехов. Сейчас моя архитектура отдалённо напоминает фубар, но более плотно интегрированная, без архитектурных обобщений, с обратными опциональными связями для Replay Gain (формат mp3). В плане машинной нагрузки, Maiko конечно, далеко не лидер. Но в то же время, примеров полностью 80-битных цифровых декодеров-транспортов я не знаю. Опираясь на свой опыт и слух я стал оперировать не машинной нагрузкой и показателем занятости процессорного времени а машинной эффективностью и аудиофильским режимом работы компонентов ПК, в этих двух случаях подход к построению программы немного отличается. Если переусердствовать с последним подходом, то можно получить малодружелюбные варианты типа стелс плеера без интерфейса или плееров играющих в режиме спячки. Определённо я не хочу видеть командную строку какой-то звуковой лаборатории, мне ближе мультимедиа станции и нормальные повседневные домашние ПК. Хм, путешествие по древу мысли затянулось. Знаю что это звучит негуманно, но я прошу Вас подождать. Ради завершения этого проекта я вышел из других бесплатных игровых и аудио-проектов. eduardpon, По математике изменений уже давно не было, наверное с 30-х версий. Проводится внутренняя реорганизационная работа. Оценивать результаты звучания одних и тех же формул мне трудно, на различном оборудовании результаты индивидуальны. То же самое сравнивать режим битперфекта. Очень индивидуальные результаты. Всё это в факторы в процессе и трудноконтроллируемые, нельзя же в программу не вносить никаких изменений, требуется развитие. Новую версию рекомендую, потому что она сохраняет индивидуальные настройки для каждого устройства. Только APE.

Для тех, кто пользуется плагинами Maiko: Maiko MonkeysAudio 0.02

Уточняю, потому что у Вас терминология путанная. Громкостей много разных. В системном микшере все громкости системные, в том числе приложений, эти громкости могут сохранятся в реестре, для каждого приложения индивидуально и регулируют подключение индивидуальных системных-же обработчиков для каждого приложения. Аппаратная, или по другому называемая общая громкость устройства напрямую связана с драйвером. Драйвер может применять свою собственную софтовую или аппаратную обработку. Чаще всего, аппаратную. Предполагается, что этот регулятор напрямую связан с регистром громкости, который есть на подавляющем числе устройств. Общая громкость устройства из системного микшера может дублироваться в фирменных микшерных панелях устройства, там же нужно смотреть отключалки. Аппаратный регистр громкости сам по себе никуда не денется, эта вендорозависимая низкоуровневая фича из под васапи не контролируется (в смысле отключения как функционального блока).

В чём заключается этот эффект и как Вы это определяете? Когда двигаю ползунок системного микшера в Windows 7, громкость меняется, хотя при АСИО, ВАСАПИ эксклюзив такого быть не должно (и не было, когда была АСУС СТ) Общая громкость устройства или приложения-плеера?

В чём заключается этот эффект и как Вы это определяете?

Карабас, пожалуйста не пытайсь неуклюже троллить с очень адекватными людьми, учитесь достойно воспринимать критику. Что это за детский бунт, попытки во всём найти подвох и изворот? Некрасиво тянуть одеяло на себя. Любое изменение в плеере, в том числе интерфейса, ведет к изменению в звучании, это не сентенция, а кропотливый анализ результатов такого исследовательского подхода как 'сначала сделай а потом рассуждай'. ДОКАЗАНО побитовое происхождение звука в различных аудиофильских плеерах но ПРИСУТСТВУЮТ нюансы звучания при воспроизведении на этих же самых рассматриваемых плеерах. Не заставляйте меня цитировать Ваши собственные пространные сравнения звучаний плееров. Фубар это даже не плеер, а целостная история и подход. Автор этого плеера очень опытный программист звука. Изначально фубар называли играющим блокнотом из-за нарочито простого интерфейса, ненастраиваемого. Затем интерфейс стал не сложным, но настраиваемым. Звучание менялось и часто в худшую сторону, поэтому автор, поняв куда дует ветер перемен, занял очень выгодную крепкую позицию - "кто сомневается в существовании и незыблемости битперфекта тот еретик". Автор фубара подчёркивает битперфектность плеера, и доказывает это графиками. Это роскошь, которую не может себе позволить поклонник минимализма. Минимализм построен исключительно на доверии и соучастии с автором продукта, представляющего собой реализацию подхода 'сначала сделай а потом рассуждай'. Если Вы, не проделав самостоятельную работу утверждаете что интерфейс не влияет на звук, то прислушайтесь к мнению Уважаемых форумчан - возвращайтесь на фубар, и тролльте с этой колокольни вех остальных, у Вас будет много друзей и сильных покровителей. Тем более плюс, эти покровители благосклонно поощряют существование "аудиофильных" сборок, выставляя их как "проверенные и сбалансированные решения интерфейса". Но одновременно этот двойной стандарт замалчивает и жестко цензурирует факт различий по звуку, ибо звук по теории "фубар" одинаков для всех сборок и плееров! Фубар это и есть Ваша реализованная концепция битперфекта с настраиваемым интерфейсом. Поэтому Вас и спросили, искренне не понимая, зачем ждать пока из аплеера сделают фубар? Выражу общее мнение, к фубару здесь большое почтение, это высококлассный плеер.

Карабас, ...Слишком длинное описание фубара у Вас получилось.

ss8545, У WASAPI (Vista, Win7) и Kernel Streaming (WinXP) плагин более богатые возможности. Можно рассмотреть их, это не худший вариант.

Адам, Карабас Моё мнение, тратить такой ценный ресурс как RAM-диск на файл подкачки нерационально. Если есть место под RAM диск, значит памяти в достатке и в первую очередь стоит избавиться от файла подкачки как явления. Те же самые 500Мб свободной несвязанной памяти будут более рационально расходоваться нежели зарезервированные под файл подкачки 500Мб.

...продолжил сравнение. Прослушал ещё арабский, израильский, гоа транс, весьма, весьма недурно. Воспроизводит очень чистенько, как в доме высокой культуры быта я бы даже сказал, все этно-вставочки, женский вокал, мужской, арабская речь как волшебный стих, вкрапления национальных инструментов - просто великолепно, басы, транформации, переходы, хорошо знакомые мелодии сияют как полированный самовар. Далее, представитель J-pop, Ayumi Hamasaki. Слишком заметна вездесущая уродская перекомпрессия, подвизгивающие звуки. RAM-диск неприятно подчёркивает повизгивания вместо бархатной атаки ж.д. Речь легче раскладывается на хирагану с RAM-диска, однако, компрессионное подвизгивание хуже на слух бархатной шероховатости. На тихих вступлениях всё отлично, богатый фон, хорошо заметна специфика голоса Ayumi. Слушать неприятно, мозг быстро устаёт "раскомпрессировать" звук. Ж.д. выиграл. Susan Wong - I believe, Moon river, и прочее. Тёплый, проникновенный голос, то что я и ожидал. Хочется прижать её к сердцу и никогда не отпускать. При игре с ж.д. всё чисто, хорошо, но почему-то нет такого тёплого, родного чувства. Очень странный опыт, весьма, весьма неожиданный эффект так как конкретное различие в звуке я сильно затрудняюсь описать, но той Susan Wong что поёт с RAM, я верю больше... Далее, запись игры Алексея Паршина, без преувеличения мой любимый исполнитель игры на огране, исполняет произведения И.С.Баха. Кроме великолепной игры и импровизации мастера что ещё можно сказать... Ж.д в полном ауте. RAM-диск однозначно в лидерах, богатые реверберации наполняют живым эхом тебя самого и уже вполне осязаемый зал с осязамой геометрией. Ты не просто слушаешь, ты сидишь в зале и соучаствуешь. Великолепный результат. Ж.д. иногда выдаёт непонятную сипотцу у труб, какую-то странную сссст, сссст, сссст. Необычайное разочарование! RAM-диск отчётливо (на мой слух) показывает (в моём понимании) маленький деффект записи, микрофон либо орган не вполне переваривает какую-то нотку фальшиво "подзванивая" её, и крошечный деффект будто отражается от соседних трубок. Итог. RAM-диск выиграл безусловно. Мне неприятно от этого факта, если честно. Даже боялся этого теста, но стараюсь быть объективным. Разница, надо объективно оценить, исчезающе мала. В моём случае это скорее различная энергетика чем собственно различия. Надеюсь, я удовлетворил Ваше любопытство, Карабас-барабас.

Если коротко, то жутко неудобно пользоваться. Копировать каждый альбом потом проигрывать... Неудобно, у меня предпочтения меняются постоянно, с жанра на жанр прыгаю, от классики до этники, от поп до рока и тяжёлой музыки. Сейчас на скорую руку скинул с рабочего стола что-то из RnB, Четвёртую симфонию Чайковского, New Age (Deep Forest - Music Detected). Так... Запись Чайковского шумновата.. Запись оказалась очень неудачной для теста, много песка. RnB, Работает mp3 декодер maiko (т.е. тест влияния на психоаккустику). Хорошая разборчивость, музыка, объём в обоих случаях. Я бы сказал одно и тоже играет и разницы нет. Запустил копирование на RAM-диск параллельно воспроизведению с RAM-диска. Звук покрылся едва-едва-едва уловимой, призрачной дымкой, утренним туманом. С жесткого диска практически нет этой утренней дымки, может это лишь самовнушение? Переходим к Deep Forest в формате Monkeys Audio, уже интереснее! Здесь самовнушение свирепствует. Прозрачную разборчивость демонстрирует RAM-диск. Отзвуки пугающе достоверны и заставляют обернуться. Всё идеально. С жесткого диска, как будто немножечко смазано, тот же бутерброд но со сливочным маслом. Тарелки будто маслом смазаны, щёточки по маслу проскальзывают оставляя какой-то неприятный чавкающий отзвук. RAM-диск однозначно выиграл, если бы выбирал, то однозначно RAM-диск, отличный опыт. Но без дисциплинированного уха разницы не будет никакой.

Очень положительно отношусь к самосовершенствованию и познанию мира через практику. Но смею уверить, что три раза из десяти можно случайно правильно выбрать даже с напрочь отсутствующим слухом, или устроив прослушку в метро, а то и вовсе не тратя на запуск плеера время а просто все десять раз ткнуть пальцем в один из двух вариантов. На основании 9 из 10 можно сделать некое очень смелое предположение что разница всё-таки есть. Статистика и вероятность это строгая математическая дисциплина хотя и работающая с произвольными наборами событий. Не было бы статистики и теории вероятности, невозможно было бы создать интеллектуальное оружие, машинное осязание, невозможно было бы исследовать общее по частному. У меня уже давно RAM-диск организован на 3Гб, для складирования логов, кэшей и прочего мусора ОС, подкачки ютюбов и скидывания моего собственного временного хлама. Великолепная вещь! В целом настроенная под RAM-диск операционка очень заметно снижает общий шум ПК в реальной работе, диски чаще находятся в спящем режиме. Но для звука в смысле для плеера это не очень-то подходит, к сожалению. Как говаривал кот Матроскин, чтобы продать что-то ненужное нужно сначала купить что-то ненужное, или если по теме, то для начала на этот диск информацию нужно подгрузить! Ну, и ровно на этой фразе все неоспоримые преимущества RAM-диска полностью сходят на нет. Ибо те же самые RAM-проигрыватели имеют даже более лучший КПД, экономнее выделяя память под конкретный файл и обходятся без лишних расходов на поддержание виртуального диска с его виртуальной файловой системой. Помните мульт "Падал прошлогодний снег": Стой! Обратно не то! Другой дом отгрохаю! Надёзно. Добротно. Хоросо! А хотя бы я и задничаю, зато от чистого седца! Ага, хоромина!