AleXH

Система ставится на SSD, все %TEMP% 's переносятся на рамдиск, соответственно памяти желательно иметь минимум 8ГБ, а лучше 16 с учётом рамдиска А не надо хотеть от диска того, для чего он не предназначен. Хотим дешёвые удельные ТБ хранилище - значит uT пишем на быстрый HDD 7200 1-2ТБ, а затем с него контент переносим в хранилище, где он и лежит без изменений.

ни то, ни другое в данном случае не поможет, ибо пассив. Искажается сигнал до подачи в усил - в цапе. Разная картина помех - разная картина изменения фронтов импульсов - разное время их защёлкивания (джиттер), восстанавливается разный сигнал. А помехи у нас дает и ЦП при декодировании flac и картинок и ВК при их выводе, если картинки крутятся в процессе воспроизведения - шины памяти очень классно излучают, когда данные по ним носятся.

процесс wav1->flac->wav2 даёт побитовую точность между wav1 и wav2, т.е. это lossless (беспотерьное математическое) кодирование, как у архиваторов. деградация звука воспроизведения flac по отношению к wav я уже говорил из-за чего. Посмотрел графики - профанация и бред.

нет - либо плацебо, либо извлечённые данные "мотляются" в бегущей строке в фейсе - нет данных, мотляться нечему. Т.е. причина таже, что описывал в своём посте выше.

99% - изменения в звук вносят помехи генерируемые в процессе работы ЦП, выполняющего декодирование файла во время воспроизведения, плюс помехи от пересылки данных. Помехи влияют на процесс ЦАП, изменяя выходной аналоговый сигнал. Абсолютной защиты от помех не существует, их можно лишь уменьшить до какого-то уровня. Абсолютно верно. 2ALL Если данные распаковываются по-разному, то это баги в коде декодеров - используйте официальный.

М-да... Бред какой-то пишите - прочтите внимательно, что человек написал, а не то, что вам почудилось.

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

О ней и речь - окошки чаще перезагружают кеш и конвейер ЦП, порождая больше грязи.

смотря как цап на это реагирует, всё зависит от тракта.

НЧ более массивны, но они теряют в рельефе из-за ухудшения микродинамики, размываются ИЗ в пространстве, размываются групповые события на временной оси - отстой, одним словом. полезной меньше, не нужной больше. Нет - шум, или точнее "срань" проникает даже и при правильном восстановлении сигнала из цифры.

Не якобы, а де-факто - спектр сигнала содержит больше широкополосного шума, создавая ощущение бОльшей плотности звука. Пример - чистый синус и он же с гармониками - чистый звучит более "легковесно".

Можно взять ВК на время на вторичке, воткнуть и послушать как изменился звук. Очевидно, что такой подход гораздо эффективнее, чем гадание на кофейной гуще какой из вариантов будет лучше. Оба варианта имеют свои +- и заведомо сказать какой из них окажется в итоге лучше без эксперимента - затруднительно. По поводу звука Win vs. Lin — в окнах звук грязнее, хуже разрешение, микродинамика, пространство. Нравиться виндовый звук может лишь в силу привычки. И да, грязь даёт бОльшую плотность звука, убивая при этом в нём свободу полёта, мелодичность, музыкальность. Особенно это заметно на классической музыке, БСО.

Такие вопросы обсуждаются там

Вставлю свои 5 копеек - 32 более комфортны как раз из-за смазанности, больше расслабляют. 64 чётче прорисованны и поэтому больше акцентируют внимание, оставляя меньше времени для релакса. - Почему так происходит? - Дело в том, что современные x64 CPU имеют не CISC, а RISC архитектуру, и x86 (x32) инструкции они эмулируют, выполняя больше "подковёрной" работы, чем в случае нативных x64 инструкций, что приводит к бОльшему уровню ЭМ помех, размывающих фронты сигналов и и ухудшающих микродинамику, атаку, пространственное разрешение и тд., т.е. субъективно происходит сглаживание мгновенных характеристик сигнала. Какие-то системы с этим справляются хорошо, какие-то хуже и в зависимости от этого и личных предпочтений, кто-то выбирает эмулируемый x86 (x32), а кто-то родной x64. Подытожу так - хороший цап с правильным послецаповым ФНЧ фильтром покажет превосходство x64 кода, цап с недостатками будет гнать пургу. Но, как правильно заметил Игорь, субъективно драйвер тоже имеет свой "голос", и возможно x64 реализован хуже, чем x86. Голос в кавычках потому, что он не вещественнен, а субъективен - создан коррелируемыми временно-амплитудными структурами помех и их воздействием на процесс восстановления сигнала из дискретной, цифровой в непрерывную, аналоговую форму. Для их обозначения "на пальцах" Игорь использовал определение - паттерн. Игорь, если я ошибаюсь - поправьте.

Имхо лучше та, которая нативна процессору - проц х64, значит х64, иначе х86. Но ведь никто не мешает послушать и принять решение самому.

За давностью подзабылось уже - там были ещё адаптированные оригинальные декодеры, bass был позже.

Имхо дело в BASS - он звучит иначе, нежнее и басовитее, чем FFMPEG, который более усреднённый, обыденный.

Интеловский компилятор тоже это не умеет - не в курсе? С общей методикой препятствования вымывания нужных данных из кэша знаком, надеялся, что есть инструкции, позволяющие удерживать данные и кусочки кода в кэшах.

А для окошек?

Игорь, для компиляции АП используете G++? Какой версии? Есть ли компиляторы, которым можно указать, что эти массивы данных надо поместить и держать в кэше процессора (они интенсивно обрабатываются в цикле)?

Смысл есть, если помимо критики предложите и свой вариант. Себе я ранее допиливал dimas, выкладывал здесь.

rad это способ передачи url плагину радио, но почему бы не добавить в парсер аргументов распознавание url с последующей прямой передачей радиоплагу?

- Есть какие-то противопоказания? За - универсальность и целостность поведения. Имхо хорошо бы воспроизводить переданные в качестве аргумента ссылки на файлы/стримы при запуске APlayer.

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

Чем не подходит индекс трека в m3u аналогично cue, 1 папка - 1 m3u? В принципе можно адресовать и несколько m3u, разбив 4 байта на индекс файла в папке и индекс трека в файле. Да, при изменении порядка обхода m3u в папке указатель может указывать "не туда", но имхо это не проблема.