Например... Если выдернуть выборки из "Wave" файла и отобразить (через лёгкую интерполяцию, чтоб не потерять пики) на контроле... Размер исходника (имеется ввиду выборок) очень большой и при обращении к нему для обработки (при прокрутке и масштабировании нужно изображение графика постоянно обновлять) проявляются большие накладные расходы (проц. время, обращение к жестаку)!

Вопрос: Можно ли устроить какое-нибудь кеширование (или что-нибудь, чтоб ускорить процесс) на подобии того, как это делает SoundForge и любой другой редактор звука?

> очень большой


Например ?

Было около 100 мб. Представте себе масштабирование в реальном времени...
Интерполяция всего участка (все 100) и ещё отрисовка, если захочется просмотреть весь трэк.
У меня всё встанет!

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

> Видимо ты все неправильно делаешь


Неправильно?? 20 мин аудио уместить в 320 пикселов по горизонтали сохранив все пики... Масштабировать на события прокрутки колеса мыши... Жёсткий не взлетит? В SoundForge это выполняется без труда! Или может неправильно мыслю на эту тему?

> может неправильно мыслю на эту тему?


Мыслишь-то может и правильно, а вот реализуешь свои мысли в алгоритме наверняка неправильно, оттого и проблемы имеешь.

Для построения и визуализации интерполяционного графика с 320-ю отсчетами по шкале времени вовсе не обязательно считывать (да еще и кешировать) все значения из файла.

> вовсе не обязательно считывать (да еще и кешировать) все
> значения из файла.


Скажем... Может и да, но чтобы увидеть пики при больших масштабах скажем 200:1, нужно их сначала найти. Так? Таблица? Не совсем улавливаю суть процетированной фразы... Вы не могли бы объяснить.

> чтобы увидеть пики при больших масштабах скажем 200:1, нужно
> их сначала найти. Так?


Так.

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

Ага! Спасибо! Значит мысль была ясна! Как мне кажется, в таблицу надо загонять пики только при достижении "критического" масштабирования. Т.е. где без таблицы надо было бы прочитать весь файл. Так чтоли... И не хранить те пики для тех масштабирований, где ещё жёсткий позволяет читать экие фремы с файла и быстро их выводить в граф. Или мне это только кажется? Было бы не плохо от мастеров услышать некий практический совет... (без укора)

> Сергей М. ©


Всё равно, спасибо!!!

Ну как действуют продвинутые картиночные вьюеры вроде AcdSee - читают сначала уменьшенную в 2,4,8 раз копию Jpeg под размер экрана, при необходимости подгружают копию нужного масштаба... данные у них 2D, а не 1D, но ничто не мешает использовать тот же принцип - читать файл с определённым шагом в зависимости от тек. степени масштабирования (разве что экономия памяти с 1D меньше). Точнее, прочитать один раз - сложить в кэш (благо "прореженная" копия файла весит относительно немного).
Что касается пиков... ну, найти их заранее, прописать в таблицу и использовать "адаптивный" шаг чтения файла, там где пики - читать чаще... хотя пересчитывать всё это дело в корректный масштаб при выводе на экран будет довольно муторно.