@AleXH, я могу сделать отладочный вариант текущего ap2decoder, который будет сохранять в файл копию передаваемых драйверу данных. Но драйверу передаются отдельные блоки данных для левого и правого каналов. Тогда должно быть два файла?

@AleXH, я могу сделать отладочный вариант текущего ap2decoder, который будет сохранять в файл копию передаваемых драйверу данных. Но драйверу передаются отдельные блоки данных для левого и правого каналов. Тогда должно быть два файла?

Вот,, наконец то нашлись люди, которые понимают друг друга.

...

Жуть какая-то...

Дай Б-г им здоровья...

Посмотрел - как я понимаю base address звуковых данных 0x1640000 (иногда 0x1650000)?

 

Отладочный ap2decoder вещь безусловно полезная для самоконтроля и для пресечения инсинуаций некоторых не в меру мнительных барышень - а то ору, то ору! Предлагаю добавить диалог как сохранять - по канально или мультиканал в один файл как в WAV.

 

Тест №1. AP2104, FM ASIO x32, approxy с DSP и VST, трек 24/96. Сделал несколько дампов с перезапусками плейера, задействованы даунсемплинг SoX, формат вывода 32bit float, DustEq с активированными настройками - все дампы сошлись бит в бит, что говорит о том, что все "примочки" дают всегда одини те же данные без изменений.

 

Тест №2. AP2104, FM ASIO x32, approxy разные, трек один и тот же 16/44, в настройках (ap2config) DSP и VST деактивированы (птички сняты), формат вывода оригинальный - все 3 варианта approxy дают одни и те же данные.

 

Тест №3. AP2104, FM ASIO x32, approxy с DSP и VST, в настройках (ap2config) DSP и VST деактивированы (птички сняты), формат вывода оригинальный, трек 16/44. Дамп данных идентичен WAV, исключая заголовок и теги в конце. Т.е. битпёфект для 16/44 подтверждён (при условии, что ap2decoder передаёт данные без ошибок).

 

Результат тестов - ошибки не выявлены.

Изменено 25 сентября, 201510 г пользователем AleXH

@AleXH, в блок, выделенный в памяти под образ файла загружаются данные, полученные от декодера формата через approxy. Эти данные одинаковы для разных режимов и их можно сохранить в файл, используя стандартную конфигурацию и вывод в out_disk.dll от второго винампа. Драйверу передаются разделенные по каналам данные и с преобразованной разрядностью. В 32-разрядной версии последнее преобразование выполняется непосредственно в процессе пересылки данных в буфер драйвера. То есть, окончательный результат можно брать только оттуда. В 64-разрядной версии выходной формат формируется в процессе загрузки образа в память. Это различие существует из-за размера, занимаемого данными в памяти, так как на последнем этапе этот размер часто удваивается, что было бы чревато в 32-разрядной версии отказом в воспроизведении даже CD образов. Что касается разрядности данных драйвера, то если ее нет в панели настроек ASIO, ее показывают актуальные версии программы RMAA. Чаще всего там целочисленные 32 бита, реже 24, иногда в настройках драйвера можно выбрать 16. Формат с плавающей точкой в ASIO мне не встречался.

Результат тестов - ошибки не выявлены.

Так ведь bit perfect, видимо, никто под сомнение не ставил. Речь шла скорее о более тонких материях.

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

Изменено 25 сентября, 201510 г пользователем AleXH

Игорь, зачем в памяти в FM ASIO x32, под 16/44 файл при отключенных преобразованиях отводится на 42% памяти больше, чем нужно? Т.е. первые 58% идут данные вавки, а затем 42% массив 00h - не рационально.

Изменено 25 сентября, 201510 г пользователем AleXH

@AleXH, там излишек не в процентах. Резервируется дополнительно 8Mb. Это не так много. Связано с тем, что буфер выделяется на основе информации от декодеров о длительности файла, которая в некоторых случаях бывает заниженной.

Так и есть - фрагмент в 11МБ занимал 19МБ. Согласен, 8МБ это пыль. Это по 4МБ на канал?

Да.

Маятник качнулся в другую сторону. Еще недели три назад все(почти) были в восторге от новых фич .

Мое сообщение о том,что не стоит превращать АП в комбайн для домохозяек,осталось почти незамеченным.

Теперь я успокоился,а некоторые товарищи возбудились.

 

Психика все же у всех разная.У одних Direct Input у некоторых Full Memory.

 

Не вижу никаких проблем . В папке EXTRAS есть варианты -NO_DSP,, NO_VST.

Скажу больше ..никто не запрещает пользоваться старыми версиями ,2.101 например мне симпатична.

Одним словом нет повода для негодования,кроме одного... Игорь мог бы тратить время, непосредственно на улучшение движка,а не на всякую мишуру.

 

Но!! Это время Игоря и ему видней ,чем его занять.

 

Согласитесь до Хироюкиной Шизы..еще очень далеко.!

 

Слушаем музыку и не паримся...пока не придумали влагозащищенный АП

Как-то все не обращают внимание, что разработка третьей версии уже была отложена на годы именно ради работы над движком.

 

Вот сообщение от 1 ноября 2013 года:

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

В папке EXTRAS есть варианты -NO_DSP,, NO_VST.

Это время Игоря и ему видней ,чем его занять.

Совершенно верно, но некоторые товарищи этого упорно не понимают. Более того, как показал Тест №2, approxy с деактивированными DSP и VST выдаёт те же данные, что и approxy без DSP и VST, а Тест №3 - что эти данные на входе ap2decoder побитово соответствуют входным данным WAV.

Изменено 26 сентября, 201510 г пользователем AleXH

@IgorA, в ридми не освещено какой движок использует ресемплер и в каких режимах. Например по форуму известно, что это SoX, но с какими опциями? - Например, неизвестно какие используются настройки предзвонного фильтра.

Игорь,

1. out_disk.dll взял с посте от 10 сентября - как правило, завешивает АП. ap2decoder использован "стандартный".

 

2. В диалоге обзора папок при выборе конкретного файла, АП затягивает всю папку, в которой расположен файл.

@AleXH, SoX resampler с версией указан на вкладке DSP ap2config. Используются рекомендованные разработчиками параметры режима Very High Quality Linear Phase.

 

2. В диалоге обзора папок при выборе конкретного файла, АП затягивает всю папку, в которой расположен файл.

Да, и мы это уже обсуждали месяц или два тому. Используется стандартный системный диалог выбора папки, он файлы не возвращает. Для выделения выбранного файла следует использовать перетаскивание из проводника.

 

1. out_disk.dll взял с посте от 10 сентября - как правило, завешивает АП. ap2decoder использован "стандартный".

Если настройки не менять, а просто выбирать его для вывода, то обычно он работает. Он создает файл в корне диска C.

Если настройки не менять, а просто выбирать его для вывода, то обычно он работает. Он создает файл в корне диска C.

У него ряд недостатков:

1. не умеет формировать имя дампа согласно названия трека, или хотя бы присваивать ему номер трека

2. непонятки с перезаписью существующего дампа, которые часто заканчиваются зависанием АП, либо АП может крутить счётчик воспроизведения за конец трека.

3. поддерживает ли он многоканальные хайрез вавки я так и не понял - вешается.

@AleXH, вывод плеера может перехватывать Virtual Audio Cable (VAC). Только он не в файл пишет, а создает виртуальный вход, с которого надо записывать в аудиоредакторе, например, в Sound Forge.

Последнее время всё очень серьёзно - диалог двух профи.

 

А можно пофантазировать?

 

Уважаемый Игорь,а не могли бы Вы создать версию Apleer,в которой при воспроизведении

музыкального контента автоматом отключались бы все балластные процессы и программы,

блокировался бы интернет,отключался монитор ну и проч.фигня,которая гадит и все

сосредотачивалось бы на главном - максимальное качество воспроизведения звука.

 

Управление (перемотка,пауза,возврат в стационарный режим и проч.) только с клавиатуры и

дистанционки типа простейшего GoTviev.

 

Ну,а после выгрузки Apleer всё возвращалось бы на круги своя.

 

Супер минималистский проигрыватель с супер качеством воспроизведения.

Ну и ... впереди планеты всей ...

 

Мечты ...

@Vshap, этим можно заниматься без участия плеера. Мне хватает занятий с ним.

@Vshap, этим можно заниматься без участия плеера. Мне хватает занятий с ним.

Я так понимаю, что Вы это сгоряча ответили.Я ведь именно о плеере.

Я так понимаю, что Вы это сгоряча ответили.

Точно погорячился, иначе не забыл бы добавить - "А спину вареньем не намазать?"

@Vshap, этим можно заниматься без участия плеера. Мне хватает занятий с ним.

Я так понимаю, что Вы это сгоряча ответили.Я ведь именно о плеере.

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

Точно погорячился, иначе не забыл бы добавить - "А спину вареньем не намазать?"

Вы тут уже святее ПАПЫ. Уже и за автора отвечаете.

 

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

Да это понятно.Только это намного качественее сделает профессионал и в составе продукта.

И,если при этом улучшиться качество воспроизведения,выиграют все.

Изменено 26 сентября, 201510 г пользователем Vshap

Какое отношение имеет к разработке плеера:

автоматом отключались бы все балластные процессы и программы, блокировался бы интернет,отключался монитор ну и проч.фигня

? - Вы заметили сколько времени идёт доработка 2-й версии, и сколько времени в туду стоит 3-я с модернизацией гуя? Как вы полагаете, сколько времени будет совершенствоваться 3-я? А вы тут же предлагаете заняться вообще не плейером, а отключением балластных процессов, которые наплодил балласт, сидящий за ПК вместо пользователя разумного. - Такая задача решается созданием альтернативной ОС, оптимизированной под рилтайм, в которой "балластные" процессы по определению отсутствуют.

Управление (перемотка,пауза,возврат в стационарный режим и проч.) только с клавиатуры и дистанционки типа простейшего GoTviev.

- Напрягаемся и читаем ридми.

Ну,а после выгрузки Apleer всё возвращалось бы на круги своя.

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

Супер минималистский проигрыватель с супер качеством воспроизведения. Ну и ... впереди планеты всей ...

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

Изменено 26 сентября, 201510 г пользователем AleXH