Декодирование неизвестных событий MIDI - PullRequest
2 голосов
/ 31 июля 2011

Я пишу программу чтения MIDI-файлов на Java (в основном в качестве упражнения, возможно, для использования в проекте Android, так как он не включает библиотеку javax.sound.midi).Я следую этой спецификации.

У меня есть детали спецификации, реализованные в моем проекте, с фактическим чтением, прогрессирующим для каждого события.InputStream открывается в файле, и этот же объект передается для анализа различных объектов события таким образом, что, когда событие завершается при синтаксическом анализе самого себя, поток располагается на следующем событии.Все это прекрасно работает.

Мой первый тестовый файл - это просто карта темпа с пустой дорожкой данных, созданной в Sonar 8. Дорожка темпа анализируется отлично.Пустая дорожка содержит следующие данные после идентификатора куска и имени дорожки:

00 B0 07 47 00 0A 40 00 FF 2F 00

Первые байты успешно проанализированы.00 = дельта-время 0, B0 = событие контроллера на канале 0, 07 = основной регулятор громкости, 47 = значение громкости 71.

Следующие байты меня смущают.00 0A 40 Наиболее вероятный случай - это событие Pan со значением 64. 0A - это тип события Controller, которому, как я ожидаю, предшествует B0, как и событие Volume.Но так как ему не предшествует известный байт идентификатора события, мой читатель не может проанализировать это событие.

Так что я думаю, что мой вопрос заключается в том, как объяснить этот тип события?Допустимо ли в формате файла объединять события Controller вместе, например, с одним B0 идентификатором?Кроме того, если я сталкиваюсь с неидентифицируемыми типами событий в файле, есть ли способ узнать, сколько данных я могу пропустить, если не знаю, каким должно быть это событие?Я хотел бы иметь возможность пропустить неизвестные события, чтобы мой читатель не потерпел неудачу, но если я не могу определить событие, я не уверен, как его пропустить.Хотелось бы немного разобраться в этих конкретных случаях.

Ответы [ 2 ]

4 голосов
/ 31 июля 2011

Это называется текущим состоянием. Это часть спецификации MIDI. То, что вы делаете, - это совершенно правильно. Извините, что вам пришлось выяснить это путем обратного проектирования потока данных MIDI. Вот более подробное объяснение текущего состояния.

И, да, событие Note On со скоростью 0 - это Note Off. Фактическое событие Note Off имеет связанную скорость, но практически никакие устройства не реализуют скорость Note Off, поэтому гораздо чаще можно увидеть Note On с нулевой скоростью.

0 голосов
/ 31 июля 2011

Я отвечу на свой вопрос, если кто-нибудь столкнется с подобной проблемой. (Как бы маловероятно это ни было)

Мой комментарий выше. После прочтения первого идентифицированного события, если последующее событие не имеет идентификатора события, оно может рассматриваться как событие того же типа, что и предыдущее.

Итак, в моем примере:

00 B0 07 47 00 0A 40 00 FF 2F 00

может интерпретироваться как два последовательных события контроллера, даже если существует только один идентификатор события. Так что это действительно событие Volume 07, за которым следует событие Pan 0A, за которым, конечно, следует событие End of Track FF 2F 00.

Решение в моем коде состоит в том, чтобы запомнить последний идентификатор, который был замечен, и если следующий байт в потоке не является допустимым идентификатором, следующий кусок байтов интерпретируется как тот же тип события, что и предыдущее событие. Кажется, имеет смысл, и что более важно, мой читатель завершает успешно.

...