IgorA

В iso выкладываются версии сборки TINYAP, а в tar.gz - тестовые версии плеера. В обновление сборки войдут и обновления плееров. Я думаю, это будет скоро.

@AleXH, а насчет "А, теперь, Маша, о главном..."?

@AleXH Никаких, это просто рабочие файлы, которые были под рукой. Я думаю, разницы там нет. И когда FM работает, BASS уже вообще выгружен. Чтобы не переделывать русские CUE добавил внутреннюю табличную перекодировку 1251-UTF8. От неё вреда точно не будет. Вот последний вариант: http://albumplayer.r...p64-cue2.tar.gz

Для исследователей звука консольного плеера новый вариант для тестирования (x64): http://albumplayer.r...ap64-cue.tar.gz В предыдущем обновлении с добавленной поддержкой CUE было единственное структурное изменение - зависимость от библиотеки glibc для работы с кодировками. В этом новом варианте данная зависимость убрана и настройки по умолчанию приведены в соответствие с релизом 1.08. Однако по этой причине для отображения русских CUE потребуется пересохранять их в кодировке UTF8. Это можно сделать в блокноте Windows командой "Сохранить как". В режиме воспроизведения добавлена команда c, по которой отображается загруженный CUE и выделяется цветом воспроизводимый трек.

@AleXH Это вопрос для исследования. Есть объективные характеристики процесса - занимаемая память, потребляемые ресурсы процессора, динамика переключений контекста. Они, вроде бы, не меняются при этих трансформациях. Есть сигналы на выходе, их можно оцифровывать и сравнивать их характеристики. В Windows, действительно, наблюдаются такие "потусторонние" влияния, как зависимость звука от используемой версии библиотеки VisualС, не влияющей непосредственно на указанные выше параметры. Возможно, и Linux эта чаша не миновала.

Реализация обмена тоже потребует дополнительных библиотек. А звуковой движок и так при воспроизведении работает в кэше. Поэтому вариант ap из релиза - самый минималистский.

@AleXH В принципе, сами файлы ap такие маленькие, что можно оба в папку программы положить, на выбор пользователя. Например, ap и ap2.

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

@Max_A, размер preload буфера по умолчанию - универсальный компромисс. Сочетающий устойчивость воспроизведения, отзывчивость на команды, возможность прослушивания радио и оперативного управления через VST. Увеличить его или уменьшить каждый пользователь может легко в соответствии со своими пожеланиями. Опция Force Direct Mode в программном интерфейсе WaveOut отключает автоматическое декодирование форматов, отличных от несжатого PCM, если они будут передаваться через этот интерфейс. В работе плеера с WaveOut она ничего не меняет, поскольку он всегда передает туда PCM, но это отдельный параметр в системной конфигурации вывода через WaveOut, поэтому возможность выбора его значения предоставлена пользователю.

Это, конечно, странно. Для самого плеера чем больше доступно памяти, тем лучше. Возможно, здесь сказывается особенность работы с памятью или с конкретным железом самой системы. Ещё возможна менее стабильная работа рендерера с конкретным сервером UPnP/DLNA (если серверы там разные). Можно попробовать, повлияет ли отключение опции "Lock Memory" на вкладке настроек "System". Также, как вариант - использовать стандартный режим, если он будет работать стабильно. По мере увеличения буфера он приближается по свойствам к Full Memory, поскольку в стационарном состоянии он выводит поток из буфера полностью аналогично выводу в Full Memory, а периодические подкачки данных могут занимать долю секунды с интервалами между ними в десятки секунд.

выводит, но не все - есть команды, текущие значения которых неизвестны. st выводит все технические параметры, доступные при остановленном воспроизведении. Включать в этот список настройки вывода на экран (наличие цвета и число выводимых строк), эффект которых пользователь и так видит на экране, я не считаю нужным. Тем более, что эти настройки подбираются обычно однократно или редко для постоянного использования. вводить без параметра, чтобы узнать его текущее значение - это интуитивно и удобно. Менять разделение команд на информационные и управляющие я не буду. Если формат команды требует ввода числа, его отсутствие рассматривается как "0". Команды управления воспроизведением в их списке выводятся по убыванию их актуальности и меня устраивает этот порядок. Я не думаю, что ещё кого-то это беспокоит.

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

st выводит все текущие значения. А cmd без value просто не надо вводить.

Приоритеты любой может мгновенно вернуть как было: pr99 ni-20 Но Evgen1 это не помогло. Как дела у других?

Делитесь пожалуйста собственными впечатлениями о влиянии на звук консольной версии работы с CUE. Evgen1 сообщил в ЛС, что "звук стал отвратительным".

В TINYAP свой файл ap.sh, там из папки ap этот файл можно удалить, чтобы не путаться. Он там присутствует поскольку архив универсальный, для всех систем. Папку из архива в TINYAP надо распаковывать в /home/tc . Там уже есть папка ap. Удалить её и заменить на версию из архива.

@AleXH N. уже занято на позиционирование в минутах. И по логике: снаружи из командного режима адресация файл.трек, а внутри, в режиме воспроизведения, когда файл уже выбран, он отрезается и остаётся .трек.

Тестируйте пожалуйста версию консольного плеера x64 с полуавтоматической поддержкой CUE: http://albumplayer.r...est/ap64.tar.gz Там отображаются .cue файлы внизу списков папок и файлов. Выделяются жёлтым цветом. Загружаются с выводом на экран информации по номеру файла. После этого (после явной загрузки .cue) в командном режиме для запуска трека из .cue доступна команда формата номер_файла.номер_трека То есть, разделителем номера файла из списка файлов и номера трека из списка .cue является точка, ".". В режиме воспроизведения доступна команда .номер_трека То есть, по номеру с префиксом точкой выполняется переход на трек с указанным номером из ранее загруженного .cue. Кроме этого добавлены команды управления абсолютным и относительным приоритетом: pr<число>, ni<число>. В частности это связано с тем, что планирование реального времени для процесса плеера, используемое для приоритета большего чем "0", может приводить к меньшей стабильности воспроизведения (прерываниям звука) при минимальных буферах и высокой нагрузке, чем выполнение плеера с приоритетом "0" и обычным планированием. Поэтому в исходной конфигурации сейчас приоритет "0", но выбрать можно любой. Кроме того, для режима Full Memory исключена повторная загрузка файла при старте воспроизведения того же файла, что был перед этим загружен.

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

Листинг треков из CUE по запросу можно добавить.

Полноценная обработка CUE далеко уведет консольный плеер от минимализма, а частичная не устраивает меня. Я не буду его таким образом трансформировать. Решение окончательное, не надо дальше тратить время на его обсуждение.

Я предлагаю дискуссию вокруг CUE на этом закончить. Я выше уже сказал, что в консольном плеере не будет обработки CUE. Вопрос закрыт.

Да, TINYAP - 64-разрядная сборка. Я не делал 32-разрядную версию сборки, поскольку x86 процессоры, не поддерживающие 64-разрядного режима, сейчас мало распространены. Но можно скачать архив 32-разрядного плеера и использовать его с любой 32-разрядной системой.

Под ARMv7 на следующей неделе я планирую универсальный комплект всех трёх программ (плеер, рендерер, консольный плеер). Возможно, он подойдёт и для BeagleBone Black.

Аудиофилы, вроде бы, слушают преимущественно lossless, в котором при грамотном разрезании не страдает ни один бит. Но я как раз не призываю резать. Я думаю, что и вариант с управлением по сети при кабельном подключении компьютера к роутеру может играть вполне качественно. Загружаясь в текстовом режиме и предоставляя при дистанционном управлении все удобства, включая CUE, ISO, плейлисты, картинки, радио. Ну а подвижники перфекционизма вполне могут потерпеть без CUE. Или всё порезать.