I'm just curious as to why the .veg files are not backward compatible with previous versions of Vegas. Certainly some of you software gurus can explain.
Don't know the answer and it's remarkable that they've never been. I recall they weren't even completely compatible between two point releases of V7 either.
It'd be interesting to do a Save As text and compare.
Actually the reason is very simple and obvious. New versions of Vegas can add new features that didn't exist before. These often require storing new data structures in the .veg file that didn't exist before. Older versions of Vegas wouldn't know what to do with these new features.
Vegas certainly isn't unique this way. Microsoft office files aren't backward compatible either. With the exception of file structures based on very standardized, mature, and long-standing formats, this is true of almost all data files. I think you'll admit that the .veg file is neither standardized nor long-standing. I'll bet it's not even close to mature yet either, as evidenced by the fact that hundreds of new features have been added in just a few years.
How would an old application know about future features? (i mean without a crystal ball or anything?) I can explain in "generic" terms:
The project file consists of data structures that the application understands. Let's say that Version 1 knows about structures A, B, & C. Version 2 adds some new features and they are kept in structure D. I open a V1 project file which contains ABC in V2 and when it saves it it saves ABCD. Now I go back to open that same file in V1 and it has no idea what to do with D! If the file itself was structured such that all of the "new stuff" came at the end then you might be able to have the previous version simply ignore the new stuff... but if the file is saved in the format ADCB then the previous version would not be able to read past D because it doesn't know how big D is an where C starts.
This is why backward compatibility is so hard to do. Certain data formats can be written in ways that they can be ignored of not understood and some cannot. Apparently Vegas project files cannot. :(
This is what makes XML so popular as a data exchange format. XML has a standard structure that is arranged in a hierarchy of "nodes" which allows an application to simply ignore the XML nodes that it doesn't understand giving you instant backward compatibility.
In an NLE... export an EDL and open in the previous version.
I don't know how much will carry over since the old version may not have the same resources available.
Which kind of begs the question of why Vegas doesn't use XML for its project files. It has another advantage, it's fairly robust compared to the packed binary file structure that Vegas uses which can need only a single bit error to make a project file unloadable.
On the other side of the coin XML is extremely inefficient by comparison, a complex Vegas XML project file with lots of keyframes and masks would be huge and could take considerable time to load.
It would be nice to have the option to Save As in both formats.
Good point, Johnny re xml, I'm seeing that in flash files a lot more as well. btw great book on Acid, just bought it and am reading it, well done... trying to learn it, and sonar..
I just checked this between V9 and V8 using a very simple cuts only project. Both EDL and AAF files seemed to open to perfection.
Of course as noted above, FXs will be problematic. This only adds to my view that step one of editing should be getting the project cut before doing anything else.
Being able to save a veg for VP8 would be a nice feature in VP9.
On the MS Office example, they provide a plugin filter for older versions of office that opens the newer XML file types, so there is some forwards compatibility available.
I would think that xml files would be slower reading and writing. I don't know if that would have an impact on things like saving while previewing, etc.I realize we are not talking about high volume here but efficiency & performance is what it is all about.
>> a complex Vegas XML project file with lots of keyframes and masks would be
>> huge and could take considerable time to load
I am not sure this is correct. I would say that the only reason that Vegas files are not backwards compatible is that it is not on the project requirement list. If it was, it would probably not be hard at all to do. There is probably no reason a Vegas project file could not be 100% backwards compatible for years and years.
A timeline consists of
- A list of events with a file reference, a timeline id, a start and a duration, this covers overlap
- Each event might have event markers
- Each event has a list of envelopes with markers and changing values
- A list of timeline markers etc
- A list of transitions with timeline reference or envelope references, start and duration
- and a few other things
These things have not changed since I started using Vegas, which would make it trivial to have full backwards and forwards compatibility. There is nothing that has changed in any of the versions of Vegas that I have used that makes this impossible. That is, if it is a requirement and the file format is designed for it.
Honestly, I think it is really bad when a file format changes arbitrarily and for no real reason, but then again, I don't think this is a "problem" Sony should expend a lot of engineering effort on, there are other problems that should be much higher on the list.
Again though, the issue here seems to be with Product Management, which in my opinion all the most problematic Vegas problems point to. Perhaps it is time SCS go out and get some new Product Managers. People who knows how to manage software teams in such a way that they produce customer oriented results.
Shouldn't be. It should be trivial to have a dialog like this
Missing effect
Sorry, this project uses the "Amazingly Gross Starburst and Brittney Spears" effect. This effect does not appear to be installed on your system. Would you like to replace the effect with an alternate effect or leave it un-effected?
The only thing missing is a Prod Man with a requirement that says: Project file must remain unchanged.
The devils in the detail. Don't forget we've got parent / child compositing and motion, all with its own keyframes. We've got envelopes and media generators. That's just on the video side.
On the audio side we've got busses, an unlimited number of them and routing to consider. All of which can have effects and envelopes.
Then all of the effects modules need to have their parameters updated at around every 10uS during playback.
"Not entirely true. M$ do offer the ability to Save As in a format that is backwards compatible."
Which also loses any features that are available only in the newer version, and in some cases leaves you with a butchered document of very little use. I'm not saying it's completely useless, but in some cases it's simply not worthwhile. Microsoft can get away with it much more readily because Office was a mature product a decade ago. There haven't been any fundamental changes to it's abilities in many years and newer versions aren't adding much more than occasional fluff. Not so with Vegas, which is a young and dynamic product.
In Vegas, we're not talking about just a list of effects. How useful would a V8 project with nesting be if opened in V5 that didn't support nesting? What would you do with a project that made use of buss tracks in a version that didn't have them? What if all your source is HDV and you try to open it in V4? These are simple examples of cases where a project would simply be useless if opened without the newer version's features. Every version of Vegas, and sometimes even incremental updates, add features that would kill a project if you tried to open the file in a version without them. What's your advice there? Don't use the new features? If that's the best option then why aren't we all still using Vegas Video 2?
Two additional points ...
We all want Vegas to improve and grow and be able to do more for us. We want the programmers to make Vegas more powerful and more capable. Accepting that also means accepting a break with the past and that moving forward sometimes means abandoning old things. This is just the way the industry works and we have to accept it or remain stagnant. Many folks complain that Vegas is falling behind in some areas. Well, the effort and constraints needed to maintain more backwards compatibility would slow down and hinder advancement to a much greater degree. Do you really want that?
Seriously, how often is it really required to be able to open a project in an older version? I suspect the cases where it's most desired is when someone has recently obtained the new version, has begun a new critical project, and comes across a bug or a workflow change that would be most easily avoided by going back to the familiar previous version. So that brings up the question of why that person is doing a critical project on a new and unfamiliar version of Vegas? If the project is that important then it should be begun in the known, familiar, and stable environment of the previous version. The new version should be used only for experimentation until the user is confident that it will serve all the needs and can be relied upon. And at that point, who needs the previous version?
Don't worry about backward compatibility. Upgrade cautiously and intelligently. Be happy that Vegas is advancing!
"So why do some folks keep more than one version on their computer?"
Because the older version are more than adequate with less overhead so things run smoother. I used to do a lot of audio only work, heck I've probably made more money out of doing audio with Vegas than video. For that V6 was more than adequate and it still runs to this day under Win2K on a lowly 486 with 512K of RAM. Should I mention it wasn't until V7 arrived that I ever had a problem with Vegas, prior to it "crash" was not a word in my Vegas vocabulary.
I still have V4 installed on an old laptop. It's worked quite well with my firewire 410 for doing on location multitraking. It gets done what needs to be done.