Historically, MIDI files have always used big endian, and this has always been the more common byte order for interchange and network protocols.

OK, thanks for your answer.
It's a bit unfortunate that most if not all software that deals with the files will run on little-endian systems, so all UMP dwords have to be byte-reversed all the time.

Otherwise the file format seems nice and simple BTW 🙂

I did (do) have some implementation code for a UMP-based SMF alternative format in my MIDI 2.0 library, and it is also based on big endian. https://github.com/atsushieno/ktmidi/blob/main/docs/MIDI2_FORMATS.md

It is better than little endian when inspecting what we actually load the file on some binary editor, or in memory on some debugger. If everything is in big endian, then we can easily understand the UMP contents like `40 90 30 00 F8 00 00 00` as a MIDI 2.0 Note On message. It would have been `00 30 90 40 00 00 00 F8` if it were little endian (I found it quite annoying).

The same could go for Flex Data text messages (`EMOS` `IRTS` `\0SGN`).

Hi, sorry to bother, did the specification for midi 2.0 files come out? 😮 😮 😮

[quotePost id=18925]Hi, sorry to bother, did the specification for midi 2.0 files come out?[/quotePost]
Hello Carlos. Check out the following articles on this midi.org site that were posted or updated around the beginning of this month (June 2023).

What Musicians & Artists need to know about MIDI 2.0
Details about MIDI 2.0, MIDI-CI, Profiles and Property Exchange (Updated June, 2023)

These articles announced several updated and new MIDI 2.0 specifications. One of the new specifications is about "MIDI Clip Files" which is like a MIDI 2.0 version of a MIDI 1.0 Format 0 Standard MIDI File (a single-track stream of MIDI events). That specification also mentions a "MIDI Container File" which will be like a MIDI 2.0 version of a MIDI 1.0 Format 1 Standard MIDI File (a multi-track file), but the specification for that format apparently isn't publicly released yet.

After those articles were posted, people have been reading the new specs and asking questions and discussing them on the forums here.

One downside to requiring big-endianness for clip files is that it means every implementer that uses native-endianness for its packets where "native" is little endian (which is the sweeping majority of contemporary computers) must byte-swap the packets as they are read. This also means you can't use zero-copy semantics to stream clip files, which eliminates memory-mapped file I/O (which is the lowest latency way to read bytes off disk into a program on modern computers).

It's also inconsistent with the UMP specification which allows implementers to choose their endianness. To be consistent the file format should support both little and big endian, perhaps by using different magic numbers. (`SMFCLIPB`, `SMFCLIPL`, just as an idea).

There is prior-art for this, for example ELF files (the executable format on many systems including Linux) embed their encoding into the magic number at the start of the file to allow for loaders to identify if its encoded in big or little endian format. This is actually a critical feature for allowing ELF files to be read/written on platforms where either read/write performance can be traded off (for example, writing a big-endian file on a little-endian system for a target architecture that is big-endian).

ELF file reference: https://man7.org/linux/man-pages/man5/elf.5.html