Subject:Sound Forge vs. Wavelab

Posted by: Rednroll

Date:9/29/2001 10:44:44 AM

This problem of taking a long time to cut some blank space off of the front of a file has been around ever since Sound Forge has been released. The part I find ironic is that SF said, they totally built Sound Forge 5.0 from new code (ie...none of the code of 4.5 was used). I guess they didn't think this was a problem and didn't need fixing? I have Wavelab 3.0 installed on the same system along with Sound Forge 4.5 and 5.0. I have a song which is approx. 4 minutes long, and has 7 seconds of silence in the front that I want to cut off.
When I cut it off in SF 4.5 and 5.0 it is approximately a 5 second task. When I cut it off in Wavelab it is instantaneous...ie no time to do the cut. The same type of scenario happens when you do a simple Copy and Paste to a New file. Just to do a Copy of this 4 min song it takes 11 seconds and then another 11 seconds to do the paste. To do the same thing in Wavelab it again is instantaneous. I thought the "German Engineering" scenario only applied to automobiles, I guess it applies in Audio software also?

The even more ironic thing is that you can do these same kind of functions in Vegas and they are also instantaneous. Maybe Sonic Foundry should let the Vegas Programmers talk to the Sound Forge programmers and trade some secrets. :-) Ahhh...I know, I'm probably comparing apples to oranges with this, because Vegas and Sound Forge probably handle these tasks in a different manner.

So Sonic Foundry, when are you ever gonna truly give us an upgrade for Sound Forge, or are you just gonna let Steinberg keep kicking your ass?

Subject:RE: Sound Forge vs. Wavelab

Reply by: beetlefan

Date:9/29/2001 3:26:23 PM

...ans Syntrillium...

Subject:RE: Sound Forge vs. Wavelab

Reply by: timoheil

Date:9/30/2001 6:41:51 AM

Sound Forge probably needs such a long time to perform these tasks because it creates a new file for every step of editing!? From Sonic Foundry's point of view this is of course a feature: you won't loose any data in case of a system crash.
Wavelab (and also Samplitude Master) writes the new file when you hit "save" (in the meantime - I guess -those edits are stored as some kind of meta-data, still making it possible to "undo/redo"). For really large files the Wavelab/Samplitude solution is of course the much smarter way, that's why I use Samplitude beside SF.

BTW: Steinberg is a German company, but AFAIK the Wavelab programmer is French...

best regards
-timo-

Subject:RE: Sound Forge vs. Wavelab

Reply by: beetlefan

Date:9/30/2001 1:25:47 PM

ALL of these editors from Nuendo to Cool Edit to Sound Forge create temp files so that's NO EXCUSE!

Subject:RE: Sound Forge vs. Wavelab

Reply by: Rednroll

Date:9/30/2001 6:26:12 PM

After I wrote this post I figured that was the reason for the long process times for these actions, the constant update to the temp file. I have to admit that the temp file has saved me a few times when my system decided to crash, so I am grateful for this feature. I would like to have my cake and eat it too and I can think of 2 ways around this problem.

1. As timoheil mentioned, storing the "edits" as a meta-data file. In other words it isn't necessary to save the audio file after every process, just save what you did to the audio file, so basically you're just saving information of what you did to the file.

2. Have an "Autosave" feature, where it saves to the temp file when the system is idle. Neve Audiophiles have this feature where it will save to a temp file at a time interval that YOU set and you have the choice of turning it off or on.

Also, I usually like to save every 15 minutes just as a precaution. The problem with this is that once you save, you lose you're "undo" information. Why is this? there's a data file saved along with the .WAV file, why wouldn't this information be saved also? I work in Adobe photoshop and in that program when I save my photo I'm editing I don't lose all my Undo history. Infact in photoshop I can close the program and reopen it a week later and I still have my Undo history. These are simple things that should have been added to v5.0 to make it up to date with the competition, but obviously the only thing 5.0 added was 24/96 support, and subtracted CD architect support and got a new facelift to make it look up to date. Well looks will only get you so far as they say, we need some up to date features in Sound Forge to make it a speedy audio tool.

Subject:RE: Sound Forge vs. Wavelab

Reply by: DataCowboy

Date:9/30/2001 11:40:20 PM

I agree completely with you that these feature need to be added. While I've always avoided these problems because I increment wavefile and project names after edits ("MyProj.wav" becomes "MyProj 1.wav" etc.,), it's really irritating that I'd still have a rational reason to do this in the year 2001.

Hex
Freeside
P.S. And yes, it takes me more time to clean up my directories after finishing a project and I have a lot of wasted space in the mean time.

Subject:RE: Sound Forge vs. Wavelab

Reply by: nlamartina

Date:10/3/2001 12:57:25 AM

Brian,

In response to your original post, let me share some insight. In my own personal experiments, I've noticed that a delay (when deleting) occurs for two reasons...

1. Because an undo is being created. This makes a moderate amount of sense, as I suspect the program is writing all the original data to a temp file before it's changed.

2. Because the user is working in temp mode, versus direct mode. In temp mode, deletes from both the head and tail of files can take a while, depending, of course, on the length and quality of the file. While in direct mode, however, some edits happen nearly instantaneously if undo is turned off.

Now it's important to note that when a delay occurs, it's usually when chopping the head off a file. I've never seen a delay when taking a tail. This makes me suspect that it has to do with how the data is actually written on the disk.

Now I didn't program this, and this is only my GUESS, so forgive me all if I'm wrong, but here's what I think:

Imagine looking at a bookshelf full of books. Since you're a good librarian, you always want to have the stack leaning against the left wall, so that the "beginning" of the line of books is always at the "beginning" of the bookshelf. Now say you want to truncate that stack by removing the last five books (on the right, remember). No problem. Simply remove them, and everything is still intact. Now removing books from the left side, or the beginning, is a different story. Simply taking away the first five books is no problem, but then you've got a gap from the beginning of the shelf to the beginning of the books. To correct this, you have to slide the whole stack against the left side again to coordinate the "beginnings" once again. This of course takes extra effort, and therefore time, in comparison to simply chopping off the end. You all follow? So perhaps WaveLab simply scoots the edge of the bookshelf over to meet the leftward end of the books, avoiding the extra step.

Again, I have NO idea if this is actually what happens when you edit files on the disk. It's just my creative guess. Perhaps a tech could confirm this for us. Either way, I like your suggestions. If I notice anything further when working with the program, I'll let you know.

Regards,
Nick LaMartina

Subject:RE: Sound Forge vs. Wavelab

Reply by: pwppch

Date:10/3/2001 10:49:02 AM

The short answer is this:

Forge is a destructive editor. It always changes the underlying file - be it the temp file or the file if opened in direct mode. In order to allow for undos, we must also back up the data as it is being edited.

Wave Lab uses a non-destructive model for edits. Basically it creates an intenal EDL for all of your edits. It only destructively writes out changes when you tell it to. Undos are a matter of changing the EDL vs reloading the previous temp file.

I leave it to the user to decide on the relative merits of either approach.

Peter