MIDI 解析 - 如何知道 0xFF 字节代表什么？
我只是在编写自己的 MIDI 解析器，我想知道如何区分指定完整实时类别消息 Reset 的 0xFF 与某些 Meta 的开头-event 也用 0xFF 编码，然后是一些字节（例如 FF 2F 00 -> End of track）。
I'm just writing my own MIDI parser and I was wondering how to distinguish 0xFF that designates the complete Real-Time category message Reset from the beginning of some Meta-event also coded with 0xFF and then some bytes (for example FF 2F 00 -> End of track).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在MIDI 电缆上，MIDI消息会在预期发生的瞬间进行传输。 MIDI 文件实际上是带时间戳的 MIDI 消息的记录，以便稍后播放。时间戳和 MIDI 消息的组合称为事件。 MIDI 电缆上显示的消息和 MIDI 文件中显示的事件之间存在一些差异。
您是对的，在 MIDI 电缆上，一字节实时消息可以出现在其他消息的字节中间。但是，在 MIDI 文件中，跟踪每个事件的确切字节数非常重要，因此实时消息不能存储在其他事件中间的 MIDI 文件中。
系统独占事件对于存储在 MIDI 文件中很有用，但一般来说，在 MIDI 文件中存储任何其他系统通用或系统实时消息是没有意义的。
$FF 重置：在 MIDI 电缆中，状态字节 $FF 表示重置。但是，当您播放 MIDI 文件时，在播放期间重置接收 MIDI 设备通常没有意义。因此，在MIDI文件中，状态字节$FF被重新定义以指示元事件。
$F6 调谐请求：如果设备响应此消息，我认为它会进行一些内部调谐校准，这会中断任何正在进行的播放。与重置消息类似，中断 MIDI 文件内的播放是没有意义的。
时钟、位置和开始/停止消息（$F1 MIDI 时间码四分之一帧、$F2 歌曲位置指针、$F3 歌曲选择、$F8 时钟、$FA 开始、$FB 继续、$FC Stop）：记录 MIDI 文件的设备或软件通常不会将这些传入消息记录到 MIDI 文件中。然而，设备可能有一个选项来解释这些消息，以实际重新定位、开始、停止或控制播放或录制的速度。播放 MIDI 文件的设备或软件可以选择将这些消息发送到 MIDI 输出端口，以控制除了 MIDI 文件音符之外还播放自己部分的其他 MIDI 设备。由于这种用法，MIDI 播放器负责发送这些时钟、位置和开始/停止消息，而不是 MIDI 文件。
$FE 主动感应：如果发送设备发送此消息，它将用作空闲填充符，以表明电缆仍正确连接。如果接收设备开始看到主动感应消息然后停止，它可以将其解释为电缆断开连接并使挂起的音符静音。在 MIDI 文件中存储空闲填充符没有用。发送该消息是发送设备的功能，而不是 MIDI 文件的责任。
如果您确实需要在 MIDI 文件中存储系统通用或系统实时消息，我相信它们可以存储在 MIDI 文件中的 $F7 事件中。我的理解是 $F7 事件中存储的数据字节将在 MIDI 电缆上逐字传输。 Sonic Spot 文档 将 $F7 的这种使用称为“授权 SysEx”事件（滚动至文档底部）。 MIDI技术狂热分子洗脑中心文档MIDI 文件格式 将 $F7 的这种用法称为“转义”事件（请参阅“MTrk 中的事件”页面）。 MIDI 音序器软件 Sekaiju 将 $F7 称为“SysEx（任意）”事件。
一般警告：在 MIDI 制造商协会 网站上，您可以找到一些 MIDI 制造商协会 网站。 midi.org/techspecs/index.php" rel="nofollow">官方信息（标准的表格和附录）或在论坛。但您可能知道，官方 MIDI 标准的主要内容是需要花钱的。我没有购买过它们，所以我的上述理解是基于第三方网站的描述和MIDI软件的一般用法。您应该始终意识到第三方的解释可能与官方标准的预期不同。 （例如，Jeff Glatt 的 MIDI 技术狂热者洗脑中心文档 MIDI 规范 表示 $ F9 是一条 Tick 消息，但 MMA 表示该消息 $F9 未定义并保留。说 通用 MIDI 程序 47 是管弦乐弦乐，MMA 表示节目 47 是管弦竖琴。）
On a MIDI cable, MIDI messages are transmitted at the instant they are intended to take place. A MIDI file is effectively a recording of timestamped MIDI messages for playback at a later time. The combination of a timestamp and a MIDI message is called an event. There are some differences between messages that appear on a MIDI cable and events that appear in a MIDI file.
You're correct that on a MIDI cable, the one-byte Real-Time messages can occur in the middle of bytes of other messages. However, in a MIDI file, keeping track of the exact number of bytes for each event is important, so Real-Time messages can't be stored in a MIDI file in the middle of other events.
System Exclusive events are useful to store in a MIDI file, but in general, it doesn't make sense to store any of the other System Common or System Real-Time messages in a MIDI file.
$FF Reset: In a MIDI cable, the status byte $FF means Reset. However, when you are playing a MIDI file, resetting the receiving MIDI device during playback generally doesn't make sense. So in a MIDI file, a status byte of $FF is redefined to indicate a Meta Event.
$F6 Tune Request: If a device responds to this message, I think it does some internal tuning calibration that would interrupt any playback in progress. So similar to the Reset message, it doesn't make sense to interrupt the playback inside of a MIDI file.
Clock, position, and start/stop messages ($F1 MIDI Time Code Quarter Frame, $F2 Song Position Pointer, $F3 Song Select, $F8 Clock, $FA Start, $FB Continue, $FC Stop): A device or software that records a MIDI file typically won't record these incoming messages into the MIDI file. However, the device may have an option to interpret these messages to actually reposition, start, stop, or control the speed of the playback or recording. A device or software that plays a MIDI file may have options to send these messages to the MIDI output port to control other MIDI devices that are playing their own parts in addition to the MIDI file notes. Because of this usage, the MIDI player is responsible for sending these clock, position, and start/stop messages, not the MIDI file.
$FE Active Sensing: If a sending device sends this message, it's used as an idle filler to suggest the cable is still connected properly. If receiving device starts seeing Active Sensing messages and then they stop, it can interpret that as a cable getting disconnected and silence hung notes. It's not useful to store idle filler in a MIDI file. And it would be a function of a sending device to send it, not the MIDI file's responsibility.
If you really need to store System Common or System Real-Time messages in a MIDI file, I believe they can be stored in an $F7 event in the MIDI file. My understanding is the data bytes stored in the $F7 event will be transmitted verbatim on the MIDI cable. The Sonic Spot document calls this usage of $F7 an "Authorization SysEx" event (scroll to the bottom of the document). The MIDI Technical Fanatic's Brainwashing Center document MIDI File Format calls this usage of $F7 an "Escaped" event (see page "Events in an MTrk"). MIDI sequencer software Sekaiju calls $F7 a "SysEx (Arbitrary)" event.
General caveat: On the MIDI Manufacturers Association site you can find some official information (tables and addendums to the standards) or ask questions on the forum. But as you're probably aware, the main content of the official MIDI standards cost money. I haven't purchased them, so my understanding above is based on descriptions from third party websites and general usage of MIDI software. You should always remain aware that third parties might have interpreted something differently than the official standards intended. (For example, Jeff Glatt's MIDI Technical Fanatic's Brainwashing Center document MIDI Specification says $F9 is a Tick message, but the MMA says that message $F9 is undefined and reserved. Glatt says General MIDI program 47 is Orchestral Strings, the MMA says program 47 is Orchestral Harp.)
正如 @Brad 暗示的那样，您是在解析流式 MIDI 数据还是从文件中读取它，这是有区别的。无论如何，当你从文件中读取它时，你只需要跟踪你所处的状态。你可以在文件中的很多地方遇到 0xff，但你需要始终知道你是否正在解析事件或可变长度时间戳或其他的东西。
例如，如果您刚刚解析了时间戳并遇到 0xff，那么这将是一个元事件。
另外，我发现 MIDI 文件格式的最佳参考在这里：
As @Brad hinted, there is a difference as to whether you are parsing streaming MIDI data or reading it from file. Anyways, when you are reading it from file you just need to keep track of which state that you are in. You can encounter 0xff many places in the file, but you need to always know if you are parsing events or variable-length timestamp or something else.
For instance, if you have just parsed a timestamp and encounter 0xff, then it's going to be a meta event.
Also, I've found that the best reference for the MIDI file format is here: