Storing global data (GetSummaryItem/SetSummaryItem in Interop.VegasCOM)

dust wrote on 8/10/2004, 8:32 AM
I'm currently playing around with the internal Vegas COM object (Interop.VegasCOM.dll) and found that it has a feature implemented that allows you to store (probably nearly unlimited) global data in a project, which is also stored in your project files and reloaded! This would be an extremely useful feature if Sony could make this "official". I know you (Sony) probably doesn't like this kind of playing around, but I really hope you make useful, already implemented, features available to us users.

There's only a workaround for this feature using C# (it can't be done using only Reflection, because JScript doesn't allow to pass ref parameters to methods, as far as I know ... or does it?).

I wrote a C# program "Vegascom.cs" like this (only excerpt):


using System;
using System.Reflection;
using Sony.Vegas;
namespace Vegascom
{
public class VCom
{
IVegasCOM vcom;
public VCom()
{
vcom = (IVegasCOM)typeof(ScriptHost).GetField("TheVegasCOM",
BindingFlags.Static|BindingFlags.NonPublic).GetValue(null);
}
public String GetSummaryItem(uint code)
{
String s=null;
vcom.Project_GetSummaryItem(code, ref s);
return s;
}
public void SetSummaryItem(uint code, String item)
{vcom.Project_SetSummaryItem(code, item);}
}
}

This can be compiled using the command (replace the directory of your Sony Vegas installation accordingly):

csc /t:library Vegascom.cs /r:"C:\Program Files\Sony\Vegas 5.0\Sony.Vegas.dll" /r:"C:\Program Files\Sony\Vegas 5.0\Interop.VegasCOM.dll"

or use Visual Studio for .NET using assembly references to Sony.Vegas.dll and Interop.VegasCOM.dll. The resulting Vegascom.dll was copied into Vegas' script directory.

In the Vegas script directory, I then created a script "Ref", consisting of a file "Ref.xml"

<?xml version="1.0" encoding="UTF-8" ?>
<ScriptSettings>
<AssemblyReference IsLocal="true" >Vegascom.dll</AssemblyReference>
</ScriptSettings>

And Ref.js:

import System;
import Sony.Vegas;
import System.Windows.Forms;
import Vegascom;
import System.Reflection;

try
{
var vcom = new VCom();

for (var i=0; i<10000; i++)
{ vcom.SetSummaryItem(i,i.ToString());}
}
catch(e) {MessageBox.Show(e);}

This basically sets 10'000 strings to some defined values. After I run the script, teh project was stored and I left Vegas.

Finally I modified Ref.js to:

import System;
import Sony.Vegas;
import System.Windows.Forms;
import Vegascom;
import System.Reflection;

try
{
var vcom = new VCom();
for (var i=0; i<10001; i++)
{
if (i.ToString() != vcom.GetSummaryItem(i))
{MessageBox.Show(i); break;}
}
}
catch(e) {MessageBox.Show(e);}


Starting Vegas again and loading the formerly stored project, the script showed that the first mismatch happened at 10'001. So, 10'000 strings were obviously successfully stored in the veggie.

Would be really good if this feature were made permanent... or if we at least could rely on this to continue to work :-) After all the feature is there...

Comments

rcampbel wrote on 8/10/2004, 9:40 AM
This is interesting. If you look at the Vegas.Project.SummaryProperties in a Reflection tool (like LutzRoeder's .Net Reflector), you will see that it uses the Project_GetSummaryItem and Project_SetSummaryItem to store the Summary Properties (Artist, Comments, Copyright, Engineer, Title).

The code is actually a Four Character Code (FOURCC) value that was introduced by Microsoft to identify video data stream formats in media files. See http://www.microsoft.com/whdc/archive/fourcc.mspx for details. This makes sense since a .veg file is actually a RIFF file.

So, you can't just use any code value. It needs to be something that Vegas is not using. The Vegas summary values are: IENG for engineer, INAM for name, IART for artist, ICOP for copyright, and ICMT for comment. There may be other values that Vegas uses as well.

I think that I will play around with this a bit also. Interesting find, thanks.

Randall
dust wrote on 8/10/2004, 10:39 AM
Thanks for the hint, this iactually seems to be the case! Try the following (using the same Vegascom.dll):


import System;
import Sony.Vegas;
import System.Windows.Forms;
import Vegascom;
import System.Reflection;

try
{
var iart=Vegas.Project.Summary.GetType().GetField("FOURCC_SUMMARY_IART",BindingFlags.NonPublic | BindingFlags.Static).GetValue(null);
var icmt=Vegas.Project.Summary.GetType().GetField("FOURCC_SUMMARY_ICMT",BindingFlags.NonPublic | BindingFlags.Static).GetValue(null);
var icop=Vegas.Project.Summary.GetType().GetField("FOURCC_SUMMARY_ICOP",BindingFlags.NonPublic | BindingFlags.Static).GetValue(null);
var ieng=Vegas.Project.Summary.GetType().GetField("FOURCC_SUMMARY_IENG",BindingFlags.NonPublic | BindingFlags.Static).GetValue(null);
var inam=Vegas.Project.Summary.GetType().GetField("FOURCC_SUMMARY_INAM",BindingFlags.NonPublic | BindingFlags.Static).GetValue(null);

var vcom = new VCom();
vcom.SetSummaryItem(iart,"IART");
vcom.SetSummaryItem(icmt,"ICMT");
vcom.SetSummaryItem(icop,"ICOP");
vcom.SetSummaryItem(ieng,"IENG");
vcom.SetSummaryItem(inam,"INAM");
MessageBox.Show("IART="+iart+", ICMT="+icmt+", ICOP="+icop+", IENG="+ieng+", INAM="+inam);
}
catch(e) {MessageBox.Show(e);}

Checking the Properties after the script is run shows that this is setting summary/artist/etc (Alt-Enter). Actually Vegas seems to use as internal codes:


1'414'676'809 for Artist (IART),
1'414'349'641 for Comment (ICMT),
1'347'371'849 for Copyright (ICOP),
1'196'311'881 for Engineer (IENG),
1'296'125'513 for Title (INAM)

Actually, 1'414'676'809 is 0x54'52'41'49 in hex, and if you express this in Ascii characters, this is the fourcc-string "TRAI", the reverse of "IART". The same goes for the other codes ICMT, ICOP, IENG, and INAM.

Which opens the question if the user can use the "unused" codes (up to, say, one million :-) as he/she wishes - maybe using his/her own fourcc code?

I love .Net decompilers (Spice) *g*


Note: Checking the resulting .veg in a hex editor, all these codes seem to be between two Ascii tags "list/". It doesn't look as if there were other codes stored there in between. Also, I can't see any other field definitions in the .dll's (using Spice) starting with FOURCC. Of course I don't know (yet) the riff format, this may give some additional info. Last but not least, it seems data stored in these items can be longer strings than 260 characters; length fields - followig the fourcc codes in the .veg - seem to be supported for up to 4 bytes (unicode), which would give space for 65'536 (64KB) of data per string. Didn't try out that yet though :-) The 260-char limit is probably only due to the GUI (my personal guess).
rcampbel wrote on 8/10/2004, 11:39 AM
The 260 limit is coded in the Sony.Vegas.dll file for the SummaryProperties, so you are correct that you could store up to 64KB of data.

Here are some links pertaining to RIFF files:

This is the OpenDML 1.02 spec (commonly referred to as AVI 2.0)
http://www.the-labs.com/Video/odmlff2-avidef.pdf

Microsoft DirectX AVI RIFF format spec
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow/htm/avirifffilereference.asp

Randall
dust wrote on 8/10/2004, 11:56 AM
Thanks, I'll check it out... for some reason I can't access the servers right now (maybe a server overloading). Anyway, by checking out the .veg file, I found that it doesn't seem to follow the structure I found somewhere else. But it seems it uses chunks separated by "list/" tags, all followed by the hex sequence "91 CF11 A5D6 28DB 04C1 000 xxxx yyyy yyyy yyyy zzzz". The one where zzzz equals to "BC94" seems to the the chunk where above items (subject etc) are stored in. And I didn't find any other ones than INAM/ICOP/etc in any of my old Vegas files. This is just a faint hint though.
dust wrote on 8/10/2004, 11:10 PM
I verified how much data can be stored this way without Vegas crashing and foudn some limitations:

- Single items can be at most 511 (unicode) characters long - so there's something about the 260-char limit. I'm not sure how safe it is to use lengths between 260 and 511, I guess with limitting yourself to 260, you're on the safe side. Lengths above 511 crash Vegas (at least when you try to store the project).

- You got at most around 1MB of data available (for example at most 1920 items each 260 characters long) without crashing (note that one unicode character eats 2 bytes).

- Not all unicode characters seem to be acceptable. You can't use (Char)0, and I also got problems with characters above around 65000. You're on the safe side if you just use printable characters or characters in the 1-256 range (add one to 0-255 to avoid the zero), limitting the storage space to about 512KB.