Frank....

IMO the only IP they were looking for was the development of an .avi file arrangement.....which is outdated...and have it function around the original pinnings of the DigEplayer platform....requiring a host of e.Digitals ability.

.avi is kind of like a container file to hold multimedia data...audio and video allowing for a simultaneous playback...

In RIFF (Resource Interchange File Format..being native for MSFT under ``AVI 2.0``....with translation necessary by others)...it breaks the file up into three sections....with the third being optional.

The first section (file header)...holding the information of the video metadata..ie; width, height and # of frames.

The second section holding the actual raw audio/visual data that make up the AVI movie...The audio/visual data contained here can be encoded or decoded by a codec module.

The codec translates between raw data and the data format of the compression scheme utilized.

The optional third section for indexing the location of the data within the file.

DiVX is able to sit in the RIFF format for .avi....and does...with an overhead burden...this overhead burden is a hindrance of MPEG-4 type codecs increasing file size.

To elevate this problem for DivX...June 2005

``DivX, Inc. has released its own container format called DivX Media Format (.divx extension) to succeed the AVI + DivX combo.``

.avi is dated...so what is digEcor looking for in obsolescence?

IMO...what they`re looking for is a ``to do all`` multi media file arrangement for any codec with an ability to modify in house..managed without the overhead issues for MPEG-4 type codecs .....otherwise they could utilize an existing .avi container format....or the new DiVx offering.

IMO..their offer was an insult....they`re after a shortcut scheme of translation ...meeting the native ability of MSFT...tieing them to a MSFT standard with any codec....under the original security of the digEplayer.

IMO..e.Digital setting this platform for them would be giving away a lot.

doni