What's on the T/L is only a pointer to what's in the Project Media.

If so: why do they (the TL and the Project Media) point to 2 different medias in 2 different folders?
If TL points to PM which again points to the media then the final result shound be the same media?

"If so: why do they (the TL and the Project Media) point to 2 different medias in 2 different folders?

Maybe the pointer from what's on the T/L points to the wrong entry in the Project Media?

Sorry but I long ago deleted the project file with this problem to check that out.
I can say with 100% confidence that the incorrect media was something that was once on the T/L and would have been in the Project Media pool but no longer on the T/L


Bob.

Good argument - but then again: After the footage replacement the active Take Name is still shown correctly - while the content of a take with another name is shown - so: at least the Take Name is stored at 2 different locations: once for the TL and once for the Project media.

In the mean time I have been doing some further tests (I have been programming the first 30 years after my M. Sc. - and this gives some feeling for the issue).
What I found is really strange: when a take on the TL is deleted then its Use Count in the Project Media is decreased by 1 - of course.
BUT: what I also saw is that simultaneously the Use Count of another take is also decreased by 1 (they were not in a group or otherwise connected) AND the Use Count of a third independent take is increased by 1.

See:
https://www.dropbox.com/s/s4i8wout4tu5xx0/Vegas11-TLPM01a.jpg

Then I delete take 00037 and then the first 00049 is decreased by 1 while the second 00049 is increased by 1 (the two 00049 takes are different takes in different folders - like also the two 00037 takes are independent)

https://www.dropbox.com/s/4ie11jba82arokl/Vegas11-TLPM01b.jpg

If I undo the delete of 00037 then the Use Counts of the two 00049 takes are undone back to before the deletion of 00037 - but still a delete/undelete of one take should certainly, in no way, affect other, independent takes.

Quite surprising, this is.

The take approach is interesting but when this has happened to me I didn't have any takes on the TL. Also, unlike Bob, my footage was replaced by a clip that was still on the TL. And I don't have any SSDs nor have I switched any hard drives.

One thing that occurred to me is that maybe its from using footage in different places with the same filename (ie: 00049.MTS). Just a thought, but I don't remember any of my DVCPro being replaced, and the numbering system prevents there from being a duplicate file name.

kairosmatt

I hate to speculate on coding, because none of us here can really know... but here's my wild, unsubstantiated speculation:

(Also, C++ is very foreign to me -- I work on embedded controls in C -- so my terminology below will make many of you cringe. But hopefully the concept is clear enough for other old-school programmers.)

In my imagination, each Event data structure on the timeline has one or more Take data structures associated with it.

Each Take data structure is likely to reference a "media asset number" rather than having each Take contain the full path, filename, media type, etc. of the media. So conceptually the Take simply has an index/pointer into a big Project Media table that lists all the media items in the project, and that Project Media table is where the actual filename and media details are stored.

This media asset table would look very much like what you see in "Details" view of the Project Media tab, except that if the row number shown in the first column of that table was the "Media Asset Id", the number value in that first column would "stick" with the data in the rest of the row as you click on the columns to reorder the rows by Name, by Use Count, etc.

So it would seem that when the "Vegas replaced the media" bug occurs, the particular Take.MediaAssetId field somehow ends up with a swapped value and now is selecting a different item from the Project Media table. (If it was the Project Media table that was getting messed up, then ALL timeline references to that media would get messed up.)

The reason the "Take Name" doesn't change even when the media asset reference has changed is that the Take Name is a local string that is stored in the Take itself (conceptually). You can rename any Take uniquely -- the TakeName string simply starts out by default using the name of the original media.

So drag a clip or photo to the timeline and a new Event item is created, with one Take item associated with it. That Take has a simple MediaAssetId number or pointer that references the associated media item in the master Project Media table. That Take item also has a local string "Take.Name" or whatever, that starts out holding the filename of the original media (but not the complete path, etc.). You can right click on the event, select "Take", then select "Rename Active", and type in any name you want -- i.e. change the take name to "Emotional" to identify one of multiple takes of the same scene where the actor's dialogue was more emotional.

So when the Take.MediaAssetId gets swapped to some other value, the local Take.Name string is unaffected and still holds the name that identifies the original media filename.

But again, I do hate to speculate on this sort of thing when none of us really knows. Hopefully this explains how the timeline event/take can still have the right name even when the media it is using is wrong. I don't know if its the kind of thing that one of our resident script geniuses could write a script to detect or repair?

Yep, i agree with Tim, although the terms used may be a little different, id say its correct.
If i may put it another way:
After some inspection and testing with a Veg file. (slight amount of reverse engineering here...) When you import a media file in the project manager, you do see the address to that media file in the file. If you then add that media file to the timeline, you still only see ONE address to the media file. Nothing has changed in terms of absolute addressing. But... a reference pointer to the media file is added to the file ie. a reference from the TL to the PM media.
This is indeed a reference pointer. And if the reference gets messed up for whatever reason, this would cause 'media swapping'.
The Take name is indeed a separate string from the reference pointer - although they are both part of the same media 'object'. That's why the Take name is not effected. There is a bug in Vegas which is corrupting the reference only within the media object - not the Take name.

Some background info, basically, a Veg file is a variant flavor of RIFF file format.
After the header you have chunks or blocks of data if you like.
These have data types like LIST, IENG INAM ICOP... etc. (sorry, i have not gone very far into this). But, inspecting the veg file shows these clearly which confirms what the format of the file is. The format could be reversed and mapped if needed. Not sure how happy SCS would be about that! But in doing so, it would be possible to create a veg fix utility or media index repair tool. That's possible. There is also a scripting option to control the vegas COM object, some have already done this years ago (search 2004 in the scripting forum).

But - better still, obviously fixing the reference pointer within the media object would be ideal in Vegas.

Paul.

Interesting answers.

I hope that also some users from "later" time zones (like the US) have comments to this topic.

I can add that it seems to be assumed that the replaced footage issue could be linked to the copy-and-paste of media from one instance of Vegas to another - In the few cases I have seen this was the case too - except for one case where I definitely did not change anything at all in an old projects TL - I merely opened the project and then the Project Media and then clicked the lightning bolt icon to remove unused media from the project. That was all. I have submitted an error report to SCS stating this too. Of course I have tried to repeat these simple steps to recreate the problem - but it did not occur again.

And yes, paul_w: if somebody could make a script that can go through the whole TL and compare the Take Names to their media file names then this really would be a good tool to check the integrity of the TL/media relations.
This would really save many people from having to rewatch each and every second of their projects over and over again after every change fearing these replaced footage issues - until the problem is fully solved in a future Vegas 11 update.
Please?

Of course this will only work for users that do not change the Take Names on the TL from the originally assigned media file names - but it would save very much time for many of us.

I don't know if this will help or not.
Try Saving As .txt and see what you get.

Bob.

A very good idea - have tried too, but the Vegas txt file does not contain the take name.

Still hoping for a Script guru to make a script that runs through the TL and compares all Take Names to their file names (i.e. Take Name 00037 to File Name E:\Pictures\00037.mts) and gives an error message or a list if they are different.

I know that this will only work for users that do not change the Take Names on the TL from the originally assigned media file names - but it would save very much time for many of us.

I'm also looking forward to hearing a comment from SCS to my questions in the above posts.

I've just placed version v1.0.34 of Timeline Tools on the web site. This include some bug fixes and a new display filter that shows only those events that have a mismatch between the Take name displayed in the event, and the media file name that was the source of the take.

This is especially useful for those of you who've experienced the infamous Sony Vegas Changed Media bug.