> Да и там наверно BLOB поля BLOB полями погоняют?

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

> Что-то сомнительно для подобного. Изображения, аудио, видео никто так не суёт же.

Естественно, зачем ты будешь хранить непожатый pcm-звук, когда его можно пожать? Но хранить его непожатым для редактирования, мне кажется, самое то, что надо. Потому как если жать, то всё равно придётся loseless использовать, этот loseless будет сжимать не на порядки, а в разы, то есть выигрыш не запредельный, а вот замедление доступа заметно будет. Уход от этого замедления, может ведь открыть простор для дальнейших оптимизаций потребления оперативки -- можно вообще хранить обрабатываемые данные на диске, доставая их оттуда, обрабатывая, и складывая обратно. При этом, некоторые операции вообще окажутся примерно бесплатными: вырезать кусок из середины или вставить его, например. С последовательным файлом тебе придётся двигать данные в файле с одного смещения на другое, с pcm в sql можно обойтись DELETE'ом или INSERT'ом. Не совсем правдо очевидно, как при этом не потерять порядок -- понятно, что индексами можно, но как бы так чтоб без переиндексации половины сэмплов в файле обходиться? Но опять же, sql тут даёт тебе возможности хранить в отдельных табличках дополнительные данные, например, список непрерывных диапазонов сэмплов, каждый из которых задан диапазоном id'ов из PRIMARY KEY, который отсортирован по времени от начала трека. И не просто хранить, но ещё и иметь возможность эффективно извлекать данные основываясь на этом. Меняя один формат на другой за десять минут, чтобы прогнать через бенчмарки и посмотреть, не будет ли быстрее.