AIMP Forum

AIMP для Windows => Предложения => Topic started by: Alexey Kalaverin on May 17, 2018, 14:09:59

Title: Кеширование waveform и запоминание позиции при смене трека
Post by: Alexey Kalaverin on May 17, 2018, 14:09:59
Я понимаю, что это ну очень специфические кейсы и вряд ли будут иметь какую-либо популярность, но именно эти две вещи мне бы очень сильно сократили массу времени. Я постоянно работаю с записями от часа и больше, несмотря на 500 мб/сек чтение, чтение повторное из кеша оперативной памяти и i7 топовый камень — постоянно приходится ждать.

1. Кеширование waveform, очень долго считается для длинных файлов, это совершенно понятно и резонно, но вопрос, можно ли организовать кеширование оных, например по LRO по ключу last modified time + path (я бы вообще считал во время чтения md5 выборочно, и уже по этому ключу кешировал, чтобы дубликаты однозначно устранять)? Когда приходится туда-сюда для сравнения запускать разные версии одного и того же файла, каждый раз приходится считать waveform. И ждать.

2. Связанное с тем же самым таском „запускать вразнобой разные версии одного трека”, было бы просто невероятной магией иметь опциональную фичу активируемую, например, хоткеем (можно вообще сделать, что фича активируется только пока нажат, например контрол или хоткей, а после отпускания клавиш — деактивируется, или сделать переключаемым туда-сюда), при которой, при ручной смене трека на другой — он начинается не с начала, а с той же временной отметки, на которой находится ещё играющий трек, обработка ошибок — банально сбрасывать и начинать с начала.

Я понимаю, что в этом нет никакой острой необходимости, но, быть может, вас это заинтересует. И то и другое мне сократит кучу времени и даст массу положительных ощущений при работе с AIMP.

P.S. В последних версиях этого года (в финальном релизе 2017 этого ещё не было) есть баг, когда AIMP чем-то занят, то он не перехватывает события курсора над ним, иными словами, тыкая в занятый плейлист (например для активации), я попадаю в открытый за плеером терминал и там выделяю текст, если так же буду просто пытаться скроллить занятый плейлист, то скроллиться будет неактивный браузер, который находится за плеером.

Артём, огромное спасибо за самый охренительный плеер в интернете!
Title: Re: Кеширование waveform и запоминание позиции при смене трека
Post by: Artem on May 17, 2018, 15:15:32
Я понимаю, что это ну очень специфические кейсы и вряд ли будут иметь какую-либо популярность, но именно эти две вещи мне бы очень сильно сократили массу времени. Я постоянно работаю с записями от часа и больше, несмотря на 500 мб/сек чтение, чтение повторное из кеша оперативной памяти и i7 топовый камень — постоянно приходится ждать.

1. Кеширование waveform, очень долго считается для длинных файлов, это совершенно понятно и резонно, но вопрос, можно ли организовать кеширование оных, например по LRO по ключу last modified time + path (я бы вообще считал во время чтения md5 выборочно, и уже по этому ключу кешировал, чтобы дубликаты однозначно устранять)? Когда приходится туда-сюда для сравнения запускать разные версии одного и того же файла, каждый раз приходится считать waveform. И ждать.

2. Связанное с тем же самым таском „запускать вразнобой разные версии одного трека”, было бы просто невероятной магией иметь опциональную фичу активируемую, например, хоткеем (можно вообще сделать, что фича активируется только пока нажат, например контрол или хоткей, а после отпускания клавиш — деактивируется, или сделать переключаемым туда-сюда), при которой, при ручной смене трека на другой — он начинается не с начала, а с той же временной отметки, на которой находится ещё играющий трек, обработка ошибок — банально сбрасывать и начинать с начала.

Я понимаю, что в этом нет никакой острой необходимости, но, быть может, вас это заинтересует. И то и другое мне сократит кучу времени и даст массу положительных ощущений при работе с AIMP.

1. Вы думаете, посчитать Hash у большого файла сильно быстрее, чем построить волну? Не думаю, что выигрыш будет существенен

P.S. В последних версиях этого года (в финальном релизе 2017 этого ещё не было) есть баг, когда AIMP чем-то занят, то он не перехватывает события курсора над ним, иными словами, тыкая в занятый плейлист (например для активации), я попадаю в открытый за плеером терминал и там выделяю текст, если так же буду просто пытаться скроллить занятый плейлист, то скроллиться будет неактивный браузер, который находится за плеером.

Как этого добиться? У меня такого нет
Title: Re: Кеширование waveform и запоминание позиции при смене трека
Post by: Alexey Kalaverin on May 17, 2018, 15:21:44
1. Вы думаете, посчитать Hash у большого файла сильно быстрее, чем построить волну? Не думаю, что выигрыш будет существенен
Выборочно брать несколько блоков — будет моментально для локальных файлов, давайте накидаю прототип на python?

Скажите, пожалуйста, кеширование вейвформ дампом на диск — нормальная фича?

Как этого добиться? У меня такого нет
Любой веб-стрим без бёрста, который долго заполняет буфер, пока буфер не заполнен — не отвечает. В принципе, баг жить не мешает, даже бы не обратил внимания, но в 2017 году поведение было иное: плеер перехватывал события от курсора и ничего не делал, пока плеер зафрижен, сейчас пропускает ивенты через себя на следующее окно под собой.
Title: Re: Кеширование waveform и запоминание позиции при смене трека
Post by: Artem on May 17, 2018, 16:13:38
Выборочно брать несколько блоков — будет моментально для локальных файлов, давайте накидаю прототип на python?

Скажите, пожалуйста, кеширование вейвформ дампом на диск — нормальная фича?
Любой веб-стрим без бёрста, который долго заполняет буфер, пока буфер не заполнен — не отвечает. В принципе, баг жить не мешает, даже бы не обратил внимания, но в 2017 году поведение было иное: плеер перехватывал события от курсора и ничего не делал, пока плеер зафрижен, сейчас пропускает ивенты через себя на следующее окно под собой.

Не... не надо питона.
Выборочно делать нельзя - если кто-то редактировал аудиофайл - разница может ускользнуть. Я не вижу сильной надобности в кэшировании waveформы.

Выборочно брать несколько блоков — будет моментально для локальных файлов, давайте накидаю прототип на python?

Скажите, пожалуйста, кеширование вейвформ дампом на диск — нормальная фича?
Любой веб-стрим без бёрста, который долго заполняет буфер, пока буфер не заполнен — не отвечает. В принципе, баг жить не мешает, даже бы не обратил внимания, но в 2017 году поведение было иное: плеер перехватывал события от курсора и ничего не делал, пока плеер зафрижен, сейчас пропускает ивенты через себя на следующее окно под собой.

Как добавиться зависания я знаю, у меня проваливания кликов не наблюдается. Да и вряд ли дело в плеере - если он не отвечает, то и сообщения обрабатывать он не может. Может дело в обновлении Windows?
Title: Re: Кеширование waveform и запоминание позиции при смене трека
Post by: Alexey Kalaverin on May 17, 2018, 16:18:34
Не... не надо питона.
Выборочно делать нельзя - если кто-то редактировал аудиофайл - разница может ускользнуть. Я не вижу сильной надобности в кэшировании waveформы.
На питоне легко прототипируется, просто читается, но могу алгоритм на словах раскидать. Если кто-то редактировал → то будет мискеш на уровне путь+mtime, пересчитан fast hash для путь+mtime, а от него уже взята из кеша вейвформа или посчитана заново. Ну, короче, я доделаю, т.к. мне это тоже нужно, а вам принесу.

Без сложных вычислений можно хотя бы в памяти по path+mtime кешировать последние N штук? Ну реально, часовая запись mp3 vbr, сейчас засекал, файл читается из памяти, а вейвформ считается 6-8 секунд.

Как добавиться зависания я знаю, у меня проваливания кликов не наблюдается. Да и вряд ли дело в плеере - если он не отвечает, то и сообщения обрабатывать он не может. Может дело в обновлении Windows?
Понял, половлю и в конце лета, например, напишу снова подробно с версиями всего. Это так себе баг, ерунда малозначимая.
Title: Re: Кеширование waveform и запоминание позиции при смене трека
Post by: Alexey Kalaverin on October 16, 2018, 09:39:20
Выборочно делать нельзя - если кто-то редактировал аудиофайл - разница может ускользнуть. Я не вижу сильной надобности в кэшировании waveформы.
Итого, проверил на mp3: на 480 тысяч файлов нулевой ложноположительный хит.

Делаю так:

Читаю хедер, ищу оффсет первого датафрейма, от него и до последней границы датафрейма читаю равномерно 32 куска по 32 байта, получившуюся строку сверяю с уже просканированными образцами, профит. Я ещё поиграюсь с размерами, чтобы сделать ещё меньше, но суть в том, что на x3440 и медленных старых efrx винтах в zfs рейде в среднем этот хеш считается 0.02±0.005 секунды.

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

Айнод файла + мтайм, который является ключём для кеширования хеша чанков из моего примера. Хеш которых является ключём для вейвформы. Достаточно хранить лишь во время текущей сессии, я не знаю сколько памяти занимает вейвформа. Или хранить последние 2 ** 10 например.


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

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

По крайне мере сейчас этой хернёй надетектил больше 50 тысяч дубликатов с поменянными метаданными — уже существенный выхлоп. А это считается на три порядка быстрее хромакея и на три с половиной быстрее мелкепстралов, впрочем, последние два это уже тяжёлая артиллерия и вовсе не для этого разговора.