AleXH

И я об этом - должно быть либо 400px, либо шаг 0.33 - для громкости поэтому и стоит 301, чтобы давало 100, но в ней шаг 1. Измерил длины прогрессбаров в aplayer - перемотка 233px, громкость 190px - откуда тогда 255?

Кликал по ней, видно не попал, подумал визуальный деффект. Ещё картинки не всегда успевают за 1 сек вывестись, в итоге кэшируются частично выведенными. Бывает в web ползунок "замерзает" в конце трека, а время воспроизведения идёт дальше, при этом звучит следующий трек. Ещё одно место смутило: input type="range" onchange="ProgressChange(this.value)" id="progress" value="0" min='0' max="100" step="0.25" style="width:300px;" input type="range" id="volume" onchange="VolumeChange(this.value)" min=0 max=100 value=100 step="1" style="width:301px;" - Если шаг 0.25, то как он соотносится с 0..100 и 300px %), а также почему у громкости 301px, а не 300? - Надёжней защёлкивается на 100% громкости?

теперь понятно, спасибо. в aplayer.html есть код: td id="PictMode" onclick='OnPictureMode()' style='width: 16px; display: none; background-color: rgb(68,68,68)' из-за которого при плейлисте во всю ширину справа от плейлиста идёт тонкая вертикальная полоса, поправил так: td id="PictMode" onclick='OnPictureMode()' style='width: 16px; display: none; background-color: rgb(86,86,86)'

В web не поддерживается 127.0.0.1, что неожиданно. Вот это не вкурил (aplayer.js): function ProgressChange(pos) { if (!Playing) document.getElementById('progress').value = 0; else { ChangePosition = true; var pos2 = Math.round(pos * 232.0 / 100.0); PositionCommand(pos2); CurrentTime = PlayingLen / 1000 * pos / 200; } } function VolumeChange(vol) { ChangePosition = true; var volume = Math.round(vol * 255.0 / 100.0); VolumeCommand(volume); } - Почему 232? - за вычетом ширины ползунка? А 255 в громкости откуда? js не правил, на первый взгляд вроде всё правильно работает и без правок. web900x640.zip web-интерфейс 900x640. Использование: скачать и распаковать в папку web с заменой оригинальных файлов. UP. Добавлена кнопка-ярлык отображения картинок.

Проверил - ширшэ, но недостаточно - ещё бы ширшэ до 1024-1200px, можно и более высокое до 600px, но со стандартным шрифтом Размер кнопок вполне устроит как в стандартной.

Я бы от более широкого окна не отказался бы - заголовки альбомов классики, мюзиклов часто не помещаются.

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

@IgorA, возможно ли изменить алгоритм сборки (отображения) плейлиста в случае, когда в папке лежат образы дисков одного бокссета со своими cue? Например: FileName CD1.cue FileName CD1.flac FileName CD2.cue FileName CD2.flac FileName CD3.cue FileName CD3.flac - поскольку у каждого flac есть свой cue, то помещаем их в плейлист ввиде отдельных альбомов с указанием их продолжительности звучания, т.е. как при разносе по отдельным папкам.

Истинно научных нет, есть статистические данные по отзывам пользователей и собственный опыт - чем быстрее система передаёт управление процессу плейера, чем меньше ЦП переключается в сторонние задачи, тем звук прозрачнее и детальнее.

@kleymor.metal, музыку нужно слушать под отдельной оптимизированной под вывод звука ОС с минимумом сторонних процессов. А лучше и на отдельной платформе, если позволяет тракт услышать разницу, конечно.

Она не расползается, она появляется у "антивирусов", имеющих недостаточно толковый движок.

Спустя 2 недели экипаж станции (так они представились, sectorradio, видимо ушли в далёкий космос ) ответил:

отправил им эту новость, пусть задумаются - в бобине ли дело )

Прошлой осенью они мне ответили так: Про AI-radio напишу. Но то, что инфа не отображается в типсах с точки зрения юзабилити и интерфейса вери бэд.

А если удастся договориться с ними о выводе инфы по http-запросу в какой-либо порт?

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

Сектор Радио стал вещать ещё один канал во flac - Next http://89.223.45.5:8000/next-flac

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

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

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

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

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

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

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

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