peak — это пиковое значение амплитуды. Зная, сколько байт выделяется под один сэмпл, можно высчитать ее максимальное значение: 256 (макс. амплитуда для 1 байта) возвести в степень числа байт на сэмпл и разделить пополам.
А по поводу чтения по кусочкам — совершенно верно, но это уже дальнейшая оптимизация.
В модуле wave есть класс для записи wav-файла. В гугле можно найти примеры, как генерируют вейвы с шумом на основе random. А как читать звук с девайсов, к сожалению, не знаю.
Да, можно парсить через struct, не спорю. Но я где-то читал (к сожалению, не помню, где), что mathplotlib заточена под numpy, выше производительность по сравнению со стандартными списками. И кроме того, если со звуком будут выполняться какие-либо манипуляции (нормализация, фильтры, компрессия, преобразования Фурье), то лучше numpy-массивов ничего лучше быть не может.
Дергал API еще до официального релиза — подсмотрел, как общается с сервисом Гуглобар. И помню, жутко грустил, когда прочитал в описании, что выпуск публичного API не предвидится.
Дропбокс хорош тем, что отсылает только модифицированную часть файла. Он работает на S3, а у амазона в апи есть возможность слать диапазон байт. В GAE-блобах такой возможности нет, каждый раз придется заливать файл целиком. Так что Ник (автор оригинала) малость погорячился, что решил написать «свой дропдокс». В лучшем случае это будет хостинг картинок.
Не факт. Как описано в статье, любой API-вызов можно сделать асинхронным, проблема в том, как распутать ответ. Гугловский webapp далеко не айс, и по сути, разработчики пишут на сторонних фреймворках и библиотеках, используя GAE просто как платформу.
Думаю, вскоре должны появиться первые либы для асинхрона.
Для твиттера существует немало сторонних средств аналитики и статистики, в т.ч. и платных. С появлением бесплатной официальной службы статистики их будущее туманно, но для вконтакта такого нет, и, возможно, вы в этом первооткрыватели.
А по поводу чтения по кусочкам — совершенно верно, но это уже дальнейшая оптимизация.
Изображение с программы SoundBooth:
Мой график:
Видимо, меня подвел коэфициент k для прореживания графика. Чем он больше (ближе к числу сэмплов), тем лучше график.
/ ушел писать python-клиента /
Думаю, вскоре должны появиться первые либы для асинхрона.
Это не устоявшийся перевод? Советуете так и оставить: «buffer protocols»?
Может, сделать приложение для вконтакта? С монетизацией бонусных фич.
По поводу API: лично меня бесит, что не используется OAuth, ставший де-факто на западе, и отсутствие библиотек для не-PHP.