Yeah. 0x80 -> 0xFF are special in midi. 0x7F is the highest single data byte possible--whether its velocity, note, CC value, or sysex data.
I don't follow the explanation of blocks. For me, the next data value after the byte pair 00 7F is 01 00. Maybe I will have to read that site you mentioned.
On a related subject when I looked into E-Mu remote control (sysex), I finally understood negative numbers in hex. Had to used them to simulate rotating the main encoder counter clockwise!!
BTW, you can also check out the last few pages of the Proteus Family Sysex Manual; there's a section on 14-bit Signed 2's Complement Numbers that talks about nibbilized data.
Steve
--- In xl7@yahoogroups.com, Bruno <brunorc@...> wrote:
>
> OK, mystery solved: inside of the SysEx blob, no byte can have the most
> significant bit set. In other words, 7F is the biggest number which can be
> used *for transmission*. In order to be able to transfer bigger numbers,
> the following trick is being used:
> - split the message into blocks of seven bytes
> - for each block build an initial byte, compound of highest bits of the
> seven bytes
>
> So, for instance:
> 00 00 00 00 00 00 80 becomes 01 00 00 00 00 00 00 00
> 08 00 00 00 00 00 00 becomes 40 00 00 00 00 00 00 00
> 00 00 00 00 00 00 84 becomes 01 00 00 00 00 00 00 04
>
> (or the other way round, but you get the idea)
>
> Note, that this procedure is data-blind - it's applied to all bytes,
> irrelevant to the fact their highest bits are set or not. Obviously it
> creates some overhead, namely multiplies the data size by 8/7. That's why
> after summarizing the payload of all packets we were getting more than 3874.
>
> Just to give the credit where it's due: it wasn't me who figured it out -
> at http://blog.codepainters.com/ you can find more from this guy.
>
> Cheers.
>
>
>
> 2014/1/15 steve_the_composer <smw-mail@...>
>
> > Excellent analysis, Bruno. I will probably have to wait until the weekend
> > before I can look at the specifics to confirm what you found and to see
> > what else is going on.
> >
> > The file is 3784 bytes. I just did a binary compare of the file with one
> > having a 2001 date stamp; they are identical. At the dos prompt I did a
> > simple: >FC 1.mid 2.mid /B .
> >
> > The prospect that the sysex packets are very close to the *.mid file is
> > great news. Its just a matter of figuring out the differences and how to
> > duplicate them--which you have already started doing. I will have to spend
> > some time with it, too.
> >
> > Interesting that you found only 6 track markers (was it 6?). When I dial
> > up 043^0 StarSeeker my sequencer shows 13 lit track enables (5, 6, and 16
> > are off). Pattern Edit confirms there is no note data on those tracks.
> >
> > I have some thoughts of what to check to try to explain the size
> > difference, but I don't want to speculate just yet.
> >
> > Again, excellent data/format analysis!!!!
> >
> > Steve
> >
> >
> >
> > --- In xl7@yahoogroups.com, Bruno <brunorc@> wrote:
> > >
> > > Actually, typing too fast - it's 3784, while the dump here has 32 packets
> > > of 127 and one packet of 100 bytes, yielding together 4164 bytes, 380
> > more
> > > than expected. There are also places, where the dump shows 4D 00 54 72
> > 6B,
> > > where in the original file there's 4D 54 72 6B (track header). Either
> > > eLoader mangles the data in certain way, or MidiOx was not completely
> > > precise while capturing it...
> > >
> > >
> > > 2014/1/14 Bruno <brunorc@>
> > >
> > > > 3785 bytes, found it in Files section. Checking it against the dump...
> > > >
> > > >
> > > > 2014/1/14 Bruno <brunorc@>
> > > >
> > > >> Just to correct some of my assumptions:
> > > >>
> > > >> 2014/1/14 Bruno <brunorc@>
> > > >>
> > > >>> In your case, the dump starts with "F0 7E 00 07 02 00 7F", which is
> > the
> > > >>> E-mu SysEx header, then there's 00, and... 4D 54 68 64! The dump
> > > >>>
> > > >>
> > > >> F0 7E is the Device Inquiry message; 00 stands for Device Id; 07
> > stands
> > > >> for File Dump; 02 means "Data Packet"; next byte specify the number of
> > > >> packet (modulo 7F) and number of bytes (00 7F). Then the data starts.
> > > >> However, after the MThd there should be 10 bytes and then the MTrk
> > (4D 54
> > > >> 72 6B). That's not the case, there are two 00 bytes extra.
> > > >>
> > > >> Steve, what is the original size of the StarSeeker.mid (in bytes)?
> > > >>
> > > >> Bruno
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo Groups Links
> >
> >
> >
> >
>