Subject:".sfk"'s are like dog poop...

Posted by: DaSoundGuy

Date:8/7/2002 9:52:42 AM

Sound Forge 6 doesn't always clean up it's .sfk's despite the "Delete temporary files on close". Is it not possible to configure Forge to keep its .sfk's in its user defined TEMP folder, instead of the directory of the source file?

I'd like to use a batch file to clear out months of decaying (to continue the analogy) .sfk's throughout my hard drives, but since Vegas also uses them, it would erase these as well. Are there any issues there, other than the time Vegas will take to redraw the sfk's?

Trying to live in a poopless world, ;)

DSG

Subject:RE:

Reply by: CDM

Date:8/7/2002 10:46:52 AM

there shouldn't be. It will just have to redraw them. .sfk's are harmless.

Subject:RE:

Reply by: Sonic

Date:8/7/2002 11:05:07 AM

Three points:

1) If the .sfk already exists when the file is opened, Sound Forge 6.0 uses it and does not delete it on close since it didn't create it.

2) A bug in Sound Forge 6.0/6.0a let a few delete-worthy .sfk files through the cracks under some circumstances, even though the pref was set. This will be fixed in the forthcoming 6.0b update.

3) We've considered alternative .sfk management schemes, but we do want to take advantage of using existing .sfk files created with our other applications. If it isn't sitting next to the original file, we don't know where to look unless we know where to look...that is, we'd have to add the path information as custom metadata inside the file (yuck) or do outright searches that would only be slightly optimizable if we went fishing in other apps' preferences (another yuck). It also means that if it does exist and we fail to find it, we'd end up duplicating it.

When the pref is working as desired (6.0b), then the only .sfks that should stick around are the ones created by Vegas. I suppose we might consider adding a similar pref to ACID and Vegas, but Sound Forge users seem to be the most vocal about .sfks for some reason.

You can *always* just delete .sfk files outright, though I wouldn't bother doing it while either application is running (or at least using the file). Just be forewarned that you will have to suffer a rebuild when it is re-opened in either app.

Subject:RE:

Reply by: DaSoundGuy

Date:8/7/2002 1:52:56 PM

Glad to know you're concerned. Whenever our project app folders are compiled, forgotten sfk's cause all manner of havoc, and we constantly have to clear them out manually, which is why its an issue for us.

"but Sound Forge users seem to be the most vocal about .sfks for some reason."

With Vegas, a pool of files is kept together in one location, so the sfks are just a part of that pool, contained within a folder. Like a cat-box :)... With Forge, files come from all-manner of folders and locations, so these dregs are more of an issue, especially for people like me who open ALL their wav files with Forge. I also work with Vegas, but its much less of a concern for the above reason.

Which opens up another Forge issue: why is it that when files are closed in Forge, the system still registers them as opened? Forge has to be closed before the system will acknowledge the files as closed. This is also a minor issue that we encounter day in day out. Maybe we've missed a pref...

Thanks,

DSG

Subject:RE:

Reply by: DataCowboy

Date:8/8/2002 11:54:43 AM

I'd guess Forge users also are more likely to open huge batches of files at a time. I open tons more files for editing (usually personal sample libraries) in Forge than I ever do in Vegas.

It gets quite messy looking a directory sorted by name when you have a thousand drum machine samples plus a thousand .sfk files wedged in between them.

Let me slide over to this question -- why can't the .SFK's info be appended to the .WAV as it's own chunk?

Is the overhead of a
OpenWaveFile/FindSFKChunk/ReadSFKChunk process
versus a
FileExists(SFK)/OpenSFKFile/ReadSFKFile/CloseSFKFile process
that much more? Or does it produce some other nasty side effect I'm not thinking of?

Hexadecimal
www.freesidemusic.com

Subject:RE: removing .sfk

Reply by: Erik_Nygaard

Date:8/9/2002 6:03:01 AM

"It gets quite messy looking a directory sorted by name when you have a thousand drum machine samples plus a thousand .sfk files wedged in between them."

Try sort by type, then you can at least delete them all in one swoop.

Subject:RE: removing .sfk

Reply by: DataCowboy

Date:8/9/2002 3:58:59 PM

Oh believe me I do. Every time I go into a directory and see them I sort and delete them all, but there's always a few getting orphaned here and there (like when Opcode's old FilterFX crashes out SF).

The aggravation comes from trying to quickly grab a couple related loops (and hence have the same name) and ending up grabbing an .sfk file along with them. It's a process that should take a split second that then takes a couple seconds. Not much time cost, but (and this has been delightfully shown in interaction studies) it causes a person to stop a rather automatic action and make a adjustment, and thus becomes an interruption, which accumulate into serious user frustration.

-Hex
Plus I like to keep my hard drive tidy.