SoundForge 6 and Direct Mode -Sound Forge - PC - MAGIX Community Forums Archive

Subject:SoundForge 6 and Direct Mode Posted by: Labtec Date:6/1/2002 3:07:52 AM Hi to all, I downloaded the new version 6.0 and I'm missing a great function. I'm always working with sound files greater than 1 GB and I miss the Direct Mode function. I have tried everything. No properties where I can tell SoundForge to work always in Direct Mode nore if I try to open a file I have no choise to choose the Direct Mode. Is this function taken out or is something wrong. Thanks Peter
Subject:RE: SoundForge 6 and Direct Mode Reply by: beetlefan Date:6/1/2002 3:41:43 AM I think they removed it. Besides, working in direct mode, or 16-bit can degrade the sound quality. You can tell SF to NOT use 32-bit temporary files and you can disable undo, which would be the same thing. I honestly thing the goal of 6.0 was for SF to act more like other editors, like Cool Edit.
Subject:RE: SoundForge 6 and Direct Mode Reply by: Labtec Date:6/2/2002 6:09:24 AM I hate the new version. Without Direct Mode function its a pain to work with it. As I'm told before, I'm working with large sound files with 1-2 GB. Now in version 6 I need the double the free HD space to work with these files, because SF always generate a copy of this. This takes a damn long time and also the saving takes a nother time to save the file. In SF 5 is was not the problem, because I always opend the files in Direct Mode. Beetlefan I do not know what this have to do with 32 bit temp files and undo. SF 6 generates also to copy of file during opening. There were other things to fix in SF5 to SF6 but not to take out the Direct Mode editing. I think I'm using again WaveLab or CoolEdit Pro. They are able to handle this. Also the CPU usage during recording is a pain. This is one point that Sonic should try to fix.
Subject:RE: SoundForge 6 and Direct Mode Reply by: Sonic Date:6/4/2002 2:54:17 PM Direct Mode is a bit irrelevant in a non-destructive editor like Sound Forge 6.0. If the file is compressed (e.g. mp3), Sound Forge 6.0 creates an uncompressed proxy for optimal performance, but should otherwise not create a copy of the file upon open. Maybe you are confusing peak files (.sfk) with proxies and temporary files? Cut/Copy/Paste type operations are essentially free in a non-destructive editor. Other processes will create temporary files of the processed data, but only of the length of the process. The temporary files are used in conjunction with the original files and edit history to represent the changed state of the file until it is saved. Upon save completion, the file is re-opened (and a new proxy is built if necessary), the edit history is cleared, and unused temporary files are deleted. While the plumbing was a bit different in Sound Forge 5.0, you'd still generate pretty much the same amount of data, even in direct mode, because it would copy of the original unmodified data into the undo file (or vice versa on redos). You could disable undos to avoid this, which is a risky, albeit occasionally useful mode of operation. The undo system is different in 6.0, since it really just represents different conglomerations of the original file (or proxy), temporary files created by processes, and it's internal edit history. It essentially boils down to a set of multi-file playlists. We've attempted to optimize Save in 6.0 such that several common editing scenarios will save very quickly or at least get a head start with an existing file that can be safely used for the ground level of the save. One caveat to this is that Sound Forge's temporary directory must reside on the same volume as the original file (and/or save location). But no, it isn't always going to be as efficient as Direct Mode saves in 5.0. Essentially, 5.0 was much more pay-as-you-go and 6.0 is more pay-at-the-end. While we obviously think Sound Forge 6.0's non-destructive editing model is superior to the earlier versions' traditional destructive model for many reasons, it would be naive to assume that it is appropriate for everyone's particular editing needs, and your arguments have been noted for consideration in future versions. We'll also look into the CPU usage thing. Regards, J.

Subject:SoundForge 6 and Direct Mode

Posted by: Labtec

Date:6/1/2002 3:07:52 AM

Hi to all,

I downloaded the new version 6.0 and I'm missing a great function. I'm always working with sound files greater than 1 GB and I miss the Direct Mode function. I have tried everything. No properties where I can tell SoundForge to work always in Direct Mode nore if I try to open a file I have no choise to choose the Direct Mode. Is this function taken out or is something wrong.

Thanks
Peter

Subject:RE: SoundForge 6 and Direct Mode

Reply by: beetlefan

Date:6/1/2002 3:41:43 AM

I think they removed it. Besides, working in direct mode, or 16-bit can degrade the sound quality.

You can tell SF to NOT use 32-bit temporary files and you can disable undo, which would be the same thing.

I honestly thing the goal of 6.0 was for SF to act more like other editors, like Cool Edit.

Subject:RE: SoundForge 6 and Direct Mode

Reply by: Labtec

Date:6/2/2002 6:09:24 AM

I hate the new version. Without Direct Mode function its a pain to work with it. As I'm told before, I'm working with large sound files with 1-2 GB. Now in version 6 I need the double the free HD space to work with these files, because SF always generate a copy of this. This takes a damn long time and also the saving takes a nother time to save the file. In SF 5 is was not the problem, because I always opend the files in Direct Mode. Beetlefan I do not know what this have to do with 32 bit temp files and undo. SF 6 generates also to copy of file during opening. There were other things to fix in SF5 to SF6 but not to take out the Direct Mode editing. I think I'm using again WaveLab or CoolEdit Pro. They are able to handle this. Also the CPU usage during recording is a pain. This is one point that Sonic should try to fix.

Subject:RE: SoundForge 6 and Direct Mode

Reply by: Sonic

Date:6/4/2002 2:54:17 PM

Direct Mode is a bit irrelevant in a non-destructive editor like Sound Forge 6.0. If the file is compressed (e.g. mp3), Sound Forge 6.0 creates an uncompressed proxy for optimal performance, but should otherwise not create a copy of the file upon open. Maybe you are confusing peak files (.sfk) with proxies and temporary files?

Cut/Copy/Paste type operations are essentially free in a non-destructive editor. Other processes will create temporary files of the processed data, but only of the length of the process. The temporary files are used in conjunction with the original files and edit history to represent the changed state of the file until it is saved. Upon save completion, the file is re-opened (and a new proxy is built if necessary), the edit history is cleared, and unused temporary files are deleted.

While the plumbing was a bit different in Sound Forge 5.0, you'd still generate pretty much the same amount of data, even in direct mode, because it would copy of the original unmodified data into the undo file (or vice versa on redos). You could disable undos to avoid this, which is a risky, albeit occasionally useful mode of operation. The undo system is different in 6.0, since it really just represents different conglomerations of the original file (or proxy), temporary files created by processes, and it's internal edit history. It essentially boils down to a set of multi-file playlists.

We've attempted to optimize Save in 6.0 such that several common editing scenarios will save very quickly or at least get a head start with an existing file that can be safely used for the ground level of the save. One caveat to this is that Sound Forge's temporary directory must reside on the same volume as the original file (and/or save location). But no, it isn't always going to be as efficient as Direct Mode saves in 5.0. Essentially, 5.0 was much more pay-as-you-go and 6.0 is more pay-at-the-end.

While we obviously think Sound Forge 6.0's non-destructive editing model is superior to the earlier versions' traditional destructive model for many reasons, it would be naive to assume that it is appropriate for everyone's particular editing needs, and your arguments have been noted for consideration in future versions.

We'll also look into the CPU usage thing.

Regards,
J.