Show Posts
1
Предложения / Re: Кеширование waveform и запоминание позиции при смене трека
« on: October 16, 2018, 09:39:20 »Выборочно делать нельзя - если кто-то редактировал аудиофайл - разница может ускользнуть. Я не вижу сильной надобности в кэшировании waveформы.Итого, проверил на mp3: на 480 тысяч файлов нулевой ложноположительный хит.
Делаю так:
Читаю хедер, ищу оффсет первого датафрейма, от него и до последней границы датафрейма читаю равномерно 32 куска по 32 байта, получившуюся строку сверяю с уже просканированными образцами, профит. Я ещё поиграюсь с размерами, чтобы сделать ещё меньше, но суть в том, что на x3440 и медленных старых efrx винтах в zfs рейде в среднем этот хеш считается 0.02±0.005 секунды.
Итого можно банально для отзывчивости интерфейса при быстрых переключениях туда сюда кешировать вейвформы как:
Айнод файла + мтайм, который является ключём для кеширования хеша чанков из моего примера. Хеш которых является ключём для вейвформы. Достаточно хранить лишь во время текущей сессии, я не знаю сколько памяти занимает вейвформа. Или хранить последние 2 ** 10 например.
У меня пока считается вейвформа, быть может, из-за особенности контроллера диска — фризится сам апп на достаточно ощутимое время и пока он не посчитается — плеер не перехватыват ивент скролла с мышки, например. А когда приходится туда-обратно переключать одни и те же файлы, то обсчёт заново сурово раздражает.
Но считается эта ерунда чанками буквально моментально в отличии от полного хеша датафреймов. А так как первый чанк приходится на хедер фрейма, то это прям гарантирует тот же режим кодирования. С остальными кодеками не игрался, но на не разряженных типа флака / сырого битстрима по-моему будет тот же результат.
По крайне мере сейчас этой хернёй надетектил больше 50 тысяч дубликатов с поменянными метаданными — уже существенный выхлоп. А это считается на три порядка быстрее хромакея и на три с половиной быстрее мелкепстралов, впрочем, последние два это уже тяжёлая артиллерия и вовсе не для этого разговора.