>
> 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
> >
> >
> >
> >
>