From: Sar Saloth (sarsaloth_at_yahoo.com)
Date: 2002-03-14 16:27:16
At 12:22 PM 2002-03-14 +0000, you wrote:
>Sar Saloth wrote:
> > Changing just the "interleave" would be a tiny bit of code wouldn't
> > it? I would want to avoid having multiple ways of specifying
> > channels, labels, gains etc..
> >
> > I have looked at your "OpenEEG-1.0" specification but I couldn't
> > understand how it is compatible your above example. My lack of
> > comprehension was the reason I ignored it.
>
>No -- the spec I produced would be exactly as for EDF in this regard
>-- you would need all the data for the record before you could write
>it out. I was designing a disk format.
I am copying what I think to be the record data portion here....
> ?? data for first channel
> ?? data for second channel
> :: (etc)
> ?? data for last channel
> ?? padding if for some reason the data chunk length is
> greater than sum of channel byte-counts
>} x (data chunks repeated to end of file)
If each data chunk consists of one sample per channel, then nothing in the
record depends on anything later in the record. Doesn't that mean you
could start writing the data as soon as you got it?
>For an example of a complex serial format, have a look at the ProComp
>format. From the notes in Dave's code, it seems that it sends data
>like this (reading left->right, then top->bottom -- I'm missing out a
>lot of detail here):
>
> Chan-A Chan-B Chan-C
> Chan-A Chan-B Chan-D
> Chan-A Chan-B Chan-E
> Chan-A Chan-B Chan-F
> Chan-A Chan-B Chan-G
> Chan-A Chan-B Chan-H
> Chan-A Chan-B (other data)
> Chan-A Chan-B (other data)
>
>As you can see, you get 8 samples of Chan-A/B for every one sample of
>Chan-[C-H]. Neither EDF nor my format would be any good for this (or
>at least they would force you into using 1/10 sec chunks for
>transmission).
Can you point me to the specification? Is that a fixed order or is that
specified in a header?
> > As far as I am concerned, if the headers are encoded in a similar
> > enough manner that conversion is easy, then conversion between your
> > above "interleaved" format to EDF would be nearly trivial so I
> > wouldn't consider it an issue. However, your "OpenEEG-1.0" was very
> > different in some of the headers.
>
>The idea of the format I suggested was just to keep all the fixed
>binary stuff in one file, and all the variable text stuff in a second
>file next to it, probably in some kind of structured text format
>(i.e. easily editable).
Yes that would be a very nice and clean way to handle annotation and
events. What is the advantage of the header information in a separate file
over the EDF header except for some wasted space? The EDF header already
handles signals, labels, electrode location, calibration (numerical to
physical) etc.. I agree that parsing it is a little bit of a pain compared
to some nicely labeled text field in a structured text format.
If we keep the meanings of labels and values and constants consistent with
EDF then translating between the two shouldn't be such a big deal. Those
are the things that I would really like to keep the same as EDF.
> > Yes, and an excellent reason for not tying the two formats together
> > is that a tiny micro-controller could get swamped reordering the
> > data at a high data rate, but once into a PC, such a thing is
> > trivial. OK, I have been convinced, pure EDF is not such a great
> > idea for the binary data.
>
>You mean for the binary data on the serial connection, I guess.
Yes. Thanks for understanding what I mean and not what I type.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST