AleXH

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

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

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

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

Можно взять ВК на время на вторичке, воткнуть и послушать как изменился звук. Очевидно, что такой подход гораздо эффективнее, чем гадание на кофейной гуще какой из вариантов будет лучше. Оба варианта имеют свои +- и заведомо сказать какой из них окажется в итоге лучше без эксперимента - затруднительно. По поводу звука 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 в папке указатель может указывать "не туда", но имхо это не проблема.

Сделана папка !M3U, в ней лежит Radio.m3u, но о какой именно концепции идёт речь? - уравнивание ссылок на файлы и стримы требует отхода от текущей архитектуры?

Не будет - станцию не запоминает, режим радио при перезапуске не восстанавливает.

Тогда при открытии этого плейлиста вижу следующее: по нажатию ок вижу тоже самое, что публиковал чуть раньше

Поскольку m3u формально валиден, то открываться должен, а не клинить. вот так это выглядит на хр. Из всего плейлиста оображается только 1 альбом с 1 треком, причём отображён он неверно. Кодировка m3u utf-8 без BOM.

- Это костыль. Речь же о том, что валидный m3u парсится "своеобразно".

Спасибо за подсказку - стало быть генерирую m3u, АП воспринимает его как статический список, соответственно сохраняет текущий трек. - Попробовал, всё работает, спасибо. Парсер m3u в APlayer.exe работает странно. Например следующий m3u: #EXTM3U #EXTINF:-1,011.FM (192 kbps)\90s Alternative.rad http://listen.011fm.com:8000/stream17 #EXTINF:-1,011.FM (192 kbps)\90s Country.rad http://listen.011fm.com:8000/stream10 #EXTINF:-1,011.FM (192 kbps)\Adult Standards.rad http://listen.011fm.com:8000/stream20 #EXTINF:-1,011.FM (192 kbps)\Alternative.rad http://listen.011fm.com:8000/stream15 #EXTINF:-1,Radio Caprice (AAC+)\RadioCaprice.m3u http://127.0.0.1/RadioCaprice.m3u #EXTINF:-1,70's Collection http://213.141.131.10:8002/70collection #EXTINF:-1,80's Collection http://79.120.39.202:8000/pop80 #EXTINF:-1,90's Collection http://213.141.131.10:8002/90collection #EXTINF:-1,Radio Clasic România (AAC)\AltRock.rad http://www.clasicradio.ro:8032/stream #EXTINF:-1,Radio Clasic România (AAC)\BlueJazz Radio.rad http://www.clasicradio.ro:8400/stream обрабатывается неправильно. Также часть URLs оканчиваются на /; , пример: http://178.172.150.248:2530/; , fb2k 1.2.9 для них не распознаёт title из предшедствующего #EXTINF.

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