Subject:Slow op with large files. 64-bit issue?

Posted by: Angels

Date:1/22/2015 10:02:04 PM

I'm working with large files these days, between 20 minutes and 8 hours. I find Sound Forge very sluggish with working with multiple files this size. Sometimes I just sit there waiting for the program to catch up, and this is on a 2687W Xeon workstation with 32 gigs of RAM.

Could this have something to do with the fact that Sound Forge is not a 64-bit program?

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: rraud

Date:1/23/2015 11:35:36 AM

Can you be more specific? What file types? Loading or working with plug-ins?.. Which and how many?
I never had any issues with large files on my 32-bit PCs.. except my POS Vista machine is a little lethargic, though I rarely use it for A/V work.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: Angels

Date:1/26/2015 8:50:23 AM

I'm talking about 8 hour *.wav files, 44.1/24 (7 GB), hour-long 6-channel *.wav 48/24 (3 GB), sometimes multiple files like that. A 32-bit app can only use 2 GB (and maybe double that with some code magic) even within a 64-bit environment. This makes a 32-bit app handling large files like these by necessity a disk-based process, making it slow, clunky and inefficient. I'm often staring at the Forge window, having turned white and labeled "not responding", while it's busy handling stuff internally till it comes back to life.

With 32 GB available on my system, a 64-bit version of Forge should be able to run around the current implementation and take advantage of that space to increase operational efficiency. But I also I suspect that some of the basic processing, graphic routines and I/O would get a refurb in a 64-bit version.

When you talk of large files, how large are they? If it's a configuration issue, I'm willing to try to resolve this. I've tried using SSD and even a RAM Drive for the scratch and data folders to see if it could improve things, but surprisingly it didn't make much difference. The bottlenecks seem to be in Forge itself.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: rraud

Date:1/26/2015 9:36:14 AM

Since I'm on 32bit systems, I'm limited to 2GB Wave files, if larger, I transcode or record them as Sony Wave64 <.w64) or <.raw> for 'problem' files ... but since SF is 32bit, I would try that <.w64).. Or, break the file into smaller segments and mux them back together later on. A 7GB audio file is huge, poly or otherwise.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: Geoff_Wood

Date:1/26/2015 7:22:23 PM

WAV files >4GB are 'illegal'. So I would expect problems on any system. The smaller compliant files should be fine, but be restricted by disk subsystem speed.

Is your data and SF-Temp file location on a separate drive to your Win and apps ? That could help....

geoff

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: Angels

Date:1/26/2015 8:54:38 PM

Yes you're right; but they're generally source files for compressed formats; so far Forge has handled these despite the illegality (I do remember having to convert to w64 for another program to load them). Are you saying that it would work better if I used w64? I'll try that.

As I mentioned, I've tried source and temps on SSD and even Ram Drive and surprisingly it didn't make a significant difference, which points to inefficiency within Forge itself. I had to stop using the Ram Drive because of system instability. I'm definitely NOT using the boot drive for data and temps.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: musicvid10

Date:1/28/2015 8:09:27 AM

Even though Forge seems to be able to crunch through those 32 bit headers, it's logical that it would take a lot of time. Letbus know if w64 works better.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: Angels

Date:2/1/2015 2:33:02 PM

I'm questioning whether this is really a 64-bit executable issue.

I think the biggest problem is dealing with the *.sfk image files. Creating them from scratch for such big files can take many minutes. Leaving them on disk, allow the files to open almost instantly but these files create a lot of baggage on disk: one problem is the option of keeping or deleting these files on exit is absolute for all file sizes.

Some time ago (years?) I remember asking on these boards for a user-defined file size for the keeping of sfk files; that way small files where the creation time is insignificant, or at least tolerable, could be deleted on exit, but anything exceeding the user-defined threshold would not. It was "taken under advisement" but obviously never implemented. IMO it still would be an excellent option to have. It would certainly help keep the overhead of those files down.

Mind you, I'm no expert, but I suspect there must be ways of accelerating those file scans with today's multi-threaded apps and multi-core CPUs...

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: rraud

Date:2/2/2015 9:02:42 AM

The .sfk wavform files are rather small so it's usually not a disc space issue, and they can be deleted when the projects complete.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: musicvid10

Date:2/4/2015 3:22:21 PM

"I'm questioning whether this is really a 64-bit executable issue. "

This is not a 64 bit executable issue.
File allocation is something entirely different . .
Again, 2^32 = ?
.
Instead of second-guessing the math, encode pcm above 4GB as wav64. That's precisely what it was made for.

Maybe you don't understand the basics. In order to "open" a media file, every single bit gets decoded and read into memory. That's a system function, that does not "stick" the next time you open the media file.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: Angels

Date:2/13/2015 4:09:05 PM

An 8 hour stereo mp3 file generates a 9 MB sfk file. They could easily add up to significant amount. However deleting them after a project is a good idea.

Subject:RE: Slow op with large files. 64-bit issue?

Reply by: Angels

Date:2/13/2015 5:09:41 PM

By "executable" I simply meant the Sound Forge program. I've been working with Sound Forge since version 4.

Regarding the "basics", perhaps we're not talking about the same thing. Generating sfk files which are the graphic file of the wave you see in SF can take a significant amount of time. If it already exists (ie: if it isn't deleted by SF when closed; a user preference) when reopening the file, the file opens and is ready to be worked with instantly.

I don't believe every bit gets loaded into memory; even as Wav64, how could a file larger than a program's 32-bit's allotted memory in the system be loaded? Or several? File reading would have to be disk based. But I concede that I don't know with absolute certainty that it's so.

I've noticed there's a sluggishness when navigating mp3 files as opposed to uncompressed wav; even in a 15 second file, when I click in the waveform to place the cursor it takes a more time for the cursor to appear where I've clicked than in the wav. In a 15 minute mp3 it takes 1 to 2 seconds and proportionally longer for larger files. This wouldn't happen if the mp3 was decoded and loaded into RAM, unless the file was actively decoded with every search through the file.

Anyway, I'm not going to start analyzing everything that SF does; all I'm saying in the end is that SF becomes slower with larger files, especially when several are open and more so if they're in compressed formats. With processing it's understandable, but with navigation its a pain. People working with short sound effects and > 10-minute music tracks are never going to run into this.

My original query has never really been answered: would a 64-bit version of Sound Forge be better at handling large files?