Saving .BUN files instead of Projects

  • Thread starter Thread starter RWhite
  • Start date Start date
R

RWhite

Well-known member
I would like to solicit some opinions about this.

I am using Cakewalk Pro 9, recording 24 bit audio only (no MIDI). Right now I save things in the standard Project file format. When I want to back up projects I save them as Bundle files (.Bun) and then write the .BUN to CDR.

It has annoyed me for a long time that Cakewalk saves its individual .WAV files with very cryptic names. So saving a project results in many .WAV files being written out to disk, but it’s difficult to tell which .WAV files belong to which projects.

Can anyone think of a reason why NOT to save in bundle files only? It would make it much easier to track which projects I have on my drive and where they are, plus MUCH easier to move projects between systems (I run Cake on two different computers connected by a LAN).

While project files seem to load quicker, I’ve noticed that it takes some time for the hard drive to fully load the audio “pictures” of the tracks, and I’m guessing it takes about the same total amount of time to completely load either format.

Any thoughts about saving as Bundle files only? And by the way, when a bundle file is loaded, does Cakewalk throw that Bundle’s .WAV files into a temp directory, or operate directly from the bundle file?
 
The only thing I can think of is that it is slightly faster to load projects. It is easier to maintain your file system with the bun files. It makes defragging my hard drive a lot quicker now that I have got everything in a bun file. But, I would also like to here other peoples opinions on this.


Vice
 
The primary issue I'm aware of is loading time. I think you will find that bundles take a bit longer to load than work/project files, but if you're loading from a hard drive they still load relatively quickly so it's not too much of a pain (not so if you're loading from CD-RW).

You will also find you can't do a "save" with a bundle file. When you click on the "save" icon it will default to a .cwp file format, and you have to then tell the machine you want to save as a .cwb, at which point it will ask if you want to overwrite the existing .cwb. Again not a big deal, but still a nuisance - particularly if you are working on a long session with multiple edits and want to do a lot of saves for safety. You could, of course, save as .cwp as an interim measure until finished, and then save as a .cwb after your final edit. Of course, then you would have to go and delete the .cwp and Clean Audio of the related .wav's, so this might be defeating your purpose.

All in all, I think your approach makes sense to me. The only caution I can think of is if the file becomes corrupted for any reason, then your .wav data might end up locked inside it. With a project file the .wav data is external to the file, so you could at least make an attempt to recreate the project. (I never had a Sonar file become corrupted, so I don't know how real this concern is.)

Lastly, I'm *pretty* sure that when you open a bundle file that it loads all the .wav files into your data directory (actually I think it's just one really BIG wave at that point :) ). However, I don't think think it actually retains the .wav's unless you resave as a project file (at least Clean Audio doesn't seem to find them). So I'm guessing they are loaded in some type of temporary fashion. It should be fairly easy to test, though. Change your data directory to a new, empty folder, and then open a bundle file. Then look in the *empty* folder to see if anything has been placed there. Close the file and take another look at it. (I might do this myself tonight, just out of curiosity.)
 
Last edited:
Thanks for the replies! It sounds like after my next disk "clean up" I will be saving as BUN files only. And I will try that experiment tonight also.
 
RWhite,

Yes, that's what buns are for. I suppose there is always a risk of file corruption, but I doubt the risk in any greater than it would be if you manually saved the WAVs and the project file manually (with the relative pathing intact) . In fact, I'd go so far as to suggest that the risk of your accidentally overlooking a WAV file while copying and hence losing it forever is far greater than the risk of file corruption to the BUN file.

One thing you will probably face (I read in one of your recent posts that you have upwards of twenty 24-bit tracks in a single song) is the size of your bun being larger than the space on a CD. I found a utility called FileSplit that lets you break large files into pieces so you can successfully capture large BUN files onto CDs. (You can do it from the DOS command prompt too, at least in Win 98, but it's very manual and tedious that way.) I've been using this tool to archive my rendered DV projects to CD when they get bigger than 650 MB.

-AlChuck
 
RWhite -

Well my curiousity is satisfied, the wave data from a bundle file works exactly like I thought it did.

Here's what I did and the results

1. Created a new directory on my hard drive called TestingBuns.

2. Opened Sonar and reset the default Data Directory to TestingBuns. Closed Sonar.

3. Opened Windows Explorer and checked the new directory to insure it was still empty (it was :) ). Closed Explorer.

4. Opened Sonar again, and loaded a bundle file (for info., the bundle file size was 218,654 Kb).

5. With Sonar still open, I reopened Explorer and checked the TestingBuns directory. It now had a single .wav file in it - size 218,564 (almost as big as the bundle file itself). Closed Explorer.

6. Closed Sonar without resaving anything.

7. Reopened Explorer and rechecked TestingBuns. It was now empty again.

Obviously, Sonar "temporarily" writes the .wav information from your bundle file to your data directory. I assume that if I had saved the bundle file as a project file, the .wav data would have been *permanently* written to the data directory.

This is how I imagined it worked. Now I know for sure. :D (BTW, I didn't clock the amount of time it took to open the bundle file, but I'm guessing it took a full 2 minutes or more.)
 
Thanks very much for the info! I have not had time to do my own tests yet, but I will definately be working on it this weekend.
 
RW,

Here are my thoughts on using Bun files (mostly negative) -

Cons:

1. It violates the "all your eggs in one basket" rule. If something happens to corrupt the Bun file, you have lost everything. With separate .cwp and Wave files you at least still have the original recordings in case you ever have to piece it all together.

2. It takes extra time to unpack a project before you can work on it, and to pack it when saving.

3. If the Bun exceeds 650 MB (or 700 MB) you can't easily back it up to a CDR.

4. Every time you save a Bun, or unpack one, your hard drive becomes more fragmented. Versus keeping all the Wave files intact and saving only the small .cwp file which is all that changes as you work on a mix.

5. It "finallizes" your region edits, and converts non-destructive editing to become destructive. If you use slip-editing to change a region, you can never get it back as it was.

Pros:

1. Sometimes you WANT to remove the extra junk in regions you aren't using, so saving as a Bun can serve as a "session packer."

All in all, I can see some advantages to saving projects in a Bun file, but I'd probably reopen it immiedately after saving just to verify it's all intact, before deleting the original pieces. I even do that with my Word files, reopening them right away to confirm they're not corrupted. Otherwise, if you copy a file on top of your only backup (to update the backup), there's a risk you will trash your only backup with a now-corrupted file.

Maybe I'm overly paranoid, or maybe not.

--Ethan
 
One advantage to bundle files is portability. I sometimes use different boxes for recording and editing. It's easier to load/save a project as a bundle across a network. If you do this with a .wrk file, CW then prompts you for the location for every associated temp .wav file. (unless you change your data directory to point across the network which gets cumbersome with increasing numbers of boxes.) The .bun files also work well with projects transported on CDs (space permitting). The disadvantage with bundles here is (as mentioned) load time, especially with big projects. I used to drag the .wrk files and the .wav files between PCs, but this only makes sense if you are transferring all your projects. It's impossible to tell which .wav files are associated with one (of many) projects.

On the flip side; WRK files can save disk space is you are using the same audio clips in several projects (like multiple mixes/versions of the same tune). Using bundles here creates multiple copies of the same audio information.
 
Max,

> One advantage to bundle files is portability. <

Good point.

> CW then prompts you for the location for every associated temp .wav file. <

Actually, I think it asks for the first one only, and then finds the rest automatically. I did that only once, but that's what happened that one time.

Which brings up another problem: Sonar and Cakewalk really need to let us store Wave files anywhere on a per-project basis. I've already told them that, and offered specific logic for defining the folder and how Sonar should search. Dumping every Wave file for every project you've ever done into a single folder is, well, disorganized to say the least!

And if we could store all of the files for each project in a separate folder, then the portability issue of Bun files goes away. All you'd have to do is copy the entire folder to a CDR, or in your case across the network, and open it from there.

--Ethan
 
Hey Ethan, are you the same guy who's writing for ProRec.com?

Welcome to Homerec.com!
 
> Hey Ethan, are you the same guy who's writing for ProRec.com? <

Yep, that's me.
 
Personally, I like the Pro-Tools approach to file management.
When you open a new session, it creates a folder and saves all audio recorded within a sub-folder. The folders can be moved around/archived/etc. and you can still open the session. I guess I just don't like CW's way of naming audio files and lumping them all in one giant data folder. I am aware of the CAF program too.. I just think it would be unnecessary if CW would just polish their file management a bit.
 
I agree; a bigger problem in my opinion is that the file nameing system they use make it almost impossible to figure out which wavee file goes with which project.
 
Yah.. the file naming system only adds to the problem.
I wonder if Cakewalk would consider giving an option on how to save projects in a future update.
 
The random file names are just an easy way to ensure that you don't accidentally generate duplicate file names, or open an old .BUN file and overwrite newer audio files. It's the only way I can think of that they could ensure that each audio file is uniquely named to avoid catastrophic overwrites.

I personally don't like the Pro Tools approach, I like having all my digital audio files on one super-fast optimized hard drive, away from my project data files and other garp.
 
RW,

> a bigger problem in my opinion is that the file nameing system they use make it almost impossible to figure out which wavee file goes with which project. <

Yes. All they have to do is list the file name when you right-click an audio clip and select Properties. I mean, the information is in there. All they have to do is tell us!

--Ethan
 
I would prefer that Sonar take the name of the song, track # and take # and build a name out of that. It would make life easier when you need to do a rebuild.

Hear that Mr. Hendershott!
 
Assuming that one temp.wav file = one audio clip (I haven't tested this theory):

Naming the temp.wav files based on clip/take numbers could make sense. It gets a little problematic when you start splitting/combining/editing the clips. The temp files could mirror the edited clips, but what if you used the same clips in multiple projects, then edited them in only some of those projects? It can get messy.

There ARE ways to determine which temp.wav files are associated with which projects, but they're cumbersome and it depends on the program you are using. For example; If I open a .wrk file across the network or otherwise open a project in a manner that "Guitar Tracks" doesn't find the [temp.wav] files where it expects; I will get a dialog box telling me that it can't find [tempfile.wav], and do I want to look for it? (Here's where I would have to capture the cryptic associated filename) After pointing Cakewalk to the file location, another dialog box pops up asking if I want to look for the next missing [tempfile.wav]. Note that CW is now often defaulting to the directory that contains the second (and subsequent) missing [tempfile.wav], but it does not load it automatically. The filenames that CW is looking for are revealed! PA9 behaves in a similar manner as far as I remember.

OTOH, If I open a .wrk file in "Guitar Studio" and CW can't find the missing [tempfile.wav], I get a dialog box telling me that some missing audio files cannot be found and will be replaced with silence. No browse, no choices... SOL. This is another situation where the .BUN files are the way to go.

Obviously I'm using old software. I don't know how Sonar etc. handles these situations.
 
Max Doubt -

You could just get a copy of Cakewalk Audio Finder (CWAF), which will tell you which wave files are associated with which projects. It's available for downloading from the CW web site.
 
Back
Top