it IS a PITA - for sheer convenience i simply mark them hidden. prior to this i used a temp file cleaner that allowed me to add such files to a list, but then vegas would go and create them all over again ;-(

Pros and Cons ...

But the dreaded .sfk's can be useful too in your media folder: if you sort on names the .sfk files show which media you already used.

Have been looking for a "smart" file explorer which could show media thumbnails with some kind of marking (maybe just a dot in the upper right corner) if that media was used or not.

Directory Opus could be the right basics for it - if somebody could write a plugin to show that dot.

Vegas already has a "use" counter.

I'm now using Beyond Compare and the .sfk files cause it to tell me there's a difference. Probably there's a way to filter them out of the comparison but still.

Ppro creates all manner of files but they go where I tell the app to put them. That means precious media files can be protected at the OS level, no such luxury is afforded us by Vegas.

Bob.

Yeah, I agree it's annoying but the alternatives are worse... This applies to .sfvp0 proxy files too. We call them "sidecar" files.

Option 1: save them with the media (as we do today)
Pro:
- if you move the media folder, the sidecar stays with the media
- if you move the media to a new folder, it's easy to grab the sidecar too
- if multiple projects use the same media, you only generate the sidecar once
- computing the sidecar filename is really easy from the media file name
Con:
- media folder is littered with extra files
- some media folders (e.g. dvd) are read-only
- if you rename the media file, the sidecar file is forgotten

Option 2: save them next to the .veg
Pro:
- keeps your media folder clean
- if you delete your project, it's easy to delete all the sidecars at the same time
Con:
- all the Pros from option 1 are now Cons here
- file naming is hard. if you have D:\movie1.mp4 and E:\movie1.mp4, what do you call the sidecar file in C:\Projects ?

Option 3: save them in a user-specified folder
Pro:
- never have to see the ugly sidecar files
Con:
- same Cons as option 2
- hard to know what to delete if you need disk space back

Option 4: save the sidecar *inside* the media file
Pro:
- cleanest option
- delete/rename/move is really easy
Con:
- not all media formats have compartments to store custom data
- worst performance impact (multiple reads to the same file)
- file timestamps keep changing, which makes it hard to know what's current
- bloats the media file
- possibly incompatible with other NLEs or players

Option 5: store extra data in .veg
Pro:
- pretty clean from a filesystem point of view
- never any issues with file naming
- no file compatibility issues from option 4
Con:
- makes the .veg file really huge, which slows down save/undo dramatically
- increases contention for the .veg file
- wasted effort if you share media between projects

In summary, option 1 has consistently come out on top as least problematic. In the earliest days of Vegas (before my time) the devs tried option 4, but it caused more trouble than benefit. Some other NLEs do something like option 4 or option 5, or solve it with an external metadata database.

I just sort my folders by file type -- keeps them all in one spot.

+ 1

I just wanted to say that too about sorting on file type. That is that I do.

Option 6

I have a suggestion for another option for how to handle sidecar files: put all of them inside of a single zip file, with one zip file for each folder containing media. It provides exactly the same "Pros" as Option 1, and eliminates the most aggravating con, namely the huge number of files that litter each media folder.

As for the other two cons in Option 1, if I were going to make the change I suggest above, for read-only media I would put the sidecar zip file in a single folder (specified by a Vegas preference) so it can easily be found (programming logic: "if media folder is read-only, look in Vegas sidecar folder"). You can either have one single zip file, or have a zip file for each read-only folder and/or media (e.g., DVD). I would vote for the second of these two options.

As for renaming the media file causing the sidecar files to be unnecessarily re-built, I don't think that any of the five options provides any solution to this. However, since you brought it up, I think it might be possible to solve this by building a CRC for each media file while it is being scanned during the building of the sidecar. A file containing a small database of CRCs would then be put in the zip file (this is another advantage of using the zip file approach). Building this CRC should add virtually no time to the operation since you are already reading the entire media file. If, when the media file is next opened, there is no sidecar file found, you would simply need to do a lookup in this database (an instantaneous operation) for the CRC of the media file for which no sidecar is found. If one is found, you rename the sidecar in the zip file to match the new name of the media file, and then use that renamed sidecar file, but without taking the time to rebuild it. The only engineering issue here is whether the unique identifier (CRC in my example) can be regenerated more quickly for the renamed file than rebuilding the sidecar. A true CRC takes some time, but you might be able to create an identifier that takes far less time, while still being 99.9% certain of being unique (even a CRC is not guaranteed to be unique to a given file).

[I]"Yeah, I agree it's annoying but the alternatives are worse..."[/I]

Any alternative would be better.

Option1:

Pro:
- if you move the media folder, the sidecar stays with the media
Except Vegas will rebuild the sidecar files anyway.
- if you move the media to a new folder, it's easy to grab the sidecar too
Except Vegas will likely rebuild the sidecar.
- if multiple projects use the same media, you only generate the sidecar once
If you're lucky, like the points above it might happen, normally not.

- computing the sidecar filename is really easy from the media file name
I know, writing good code to deal with this is difficult

Con:
- media folder is littered with extra files
This is non trivial problem. My media libraries are kept on a server.
- some media folders (e.g. dvd) are read-only
Ideally all my server folders should be read only. Basic rule of security is to only grant rights that are absolutely required.
- if you rename the media file, the sidecar file is forgotten
It gets forgotten by Vegas pretty regularly anyway.

This whole area of Vegas needs urgent attention:

1) Building these sidecar files takes forever and the application is locked up and flagged by the OS as "not responding" while this is happening.

2) Some of my media folders contain 1,000s of files. The amount of clutter Vegas generates is diabolical. Sorting by file extension is not really a practical option.

3) It interferes with backup processes, doubling the amount of work being done.

4) The competition's approach suffers from none of these problems.
I can pull media files into Ppro and they play immediately with a proxy screen, nothing is locked up.
By comparison simply touching a file in the Vegas explorer causes Vegas to lock up with no way to escape. This isn't a bug, it's by design.

5) Media files are getting bigger and as a result the time it takes Vegas to do its thing building these sidecar files is increasing. The files are also more difficult to decode again adding to the time it's taking Vegas to build its sidecar files. My caffeine intake is increasing as a result and that's not such a good thing. I want to get on with editing and Vegas is preventing me from doing it.

Bob.

+1 - could not agree more. Why not provide us the possibility to choose where the sfk files are created. Every time VP does not find the sfk files (need to recreate if not existent) it would first ask:

Cannot find sfk files...where would you like to store them:

(a) save sfk files in same directory as the source files
(b) define a location for the sfk files ... "browse..."

This path setting is then stored in the veg file so the project remembers it. If Vegas cannot find the sfk files where the project setting indicates it asks the same question again (per above) and re-creates them. The same tool could provide an option to "delete sfk files at their destination" so that the application shows the path before you press "delete" or "cancel". Not dangerous since they can always be recreated.

This would not remove the need to build the sfk files if they don't exist (takes a while if source files are huge but normally this happens only once). This change (or huge improvement) in the Vegas functionality would be very easy to add, implement and verify, a nobrainer for the SCS programmers. Someone should make a product suggestion... (me?). Want to probe this first and get yout comments about it.

Christian

Let's say you have set up Vegas to put all .sfk files in a specific folder, and you have these two media files:

E:\vidprojects\weddings\2012\myrna_and_floyd_part_3.mts

E:\funvids\student_work\2013\myrna_and_floyd_part_3.mts

Where the first is a wedding of two friends, and the second is a music video created by two students. When you open up the wedding video Vegas creates myrna_and_floyd_part_3.sfk. Now later on when you open up the music video, what does Vegas do? Does it say "oh, i already have a .sfk file that matches that" and uses it for the wrong video? Does it say "hmmmm, that doesn't seem to match. I'll overwrite that old .sfk with this new one." Which of these choices would you prefer? Keeping the .sfk files with the media avoids this problem.

Of course, Vegas could always create unique arbitrary names instead of using the same name as the media file. That would make for a huge nightmare trying to maintain and clean them up though, unless Vegas also had a utility for doing the housecleaning AND you remembered to use that utility.

That's a very common problem even within the one project. Say I have three EX1s on a multicam shoot and they're all reset so all the files start from 051_0001_01
The problem can be solved in two ways:

1) Use a temp file below the folder that holds the media.
2) Use a user specified temp folder to store all the files the project needs to create.

I'd much prefer option 2) as 1) still requires write access to the drive where the files are. Hashing can be used to create unique file names.

Bottom line is professional NLEs don't do what Vegas does. On this point alone Vegas is excluded from being considered "professional".
Oddly enough SCS and Sony do know a thing or two about all this:

Planning Metadata Addin

I'd add Sony's Content Browser which is now under SCS's control as another application that looks and feel "professional".

It's well past the point where the left and right hands at SCS need to talk to one another.

Bob.