Hi everyone,
 
Haven't been on the forum (posting, responding) for a few years, old username inaccessible, starting from scratch.
 
I have an old bundle that was created with Sonar 8.x (not 8.5 -- a patched version of 8.0) that is having problems with corruption.  When I try and open this bundle with a newer version of Sonar, I have the same problem as when I try to open the bundle under Sonar 8.x and XP (32-bit).  I am pretty sure the issue is not related to RIFF format and Windows 7 (64), as I've seen mentioned here in the past.  I am able to open all of my older bundles perfectly fine.  Just this one bundle is a problem.  Have tried in a friend's Sonar and it's the same thing.
 
Here's what happens: I try and open the bundle and Sonar crashes.  When I open the bundle in a basic audio editor, or rename the cwb to .wav and open in Sonar, some of the samples look and play fine, and some are demolished (corrupted, no wave forms drawn, silence, garbled audio, etc).
 
As a result, I think I have reached the point where I need to try and extract as much usable audio as possible.  Ideally this audio would be extracted in its original form (i.e. length) rather than me copying and pasting from an audio editor back into Sonar and then having to try and line everything up.  Several of these tracks are for drums, so for the obvious reasons I don't want to brute force copy/paste if there is a better way.
 
Having written that, I have a passing knowledge of the RIFF format and I suspect I may have to resort to a binary editor to do what I want to do (i.e. to extract the audio from a bundle) -- but after I dig into my bundle (e.g. using hexdump under Linux), and reach the data section of the bundle, things are not as I had expected.  Earlier reading of the Cakewalk forum, archives, and various RIFF data sheets via Google suggest that what I should be seeing is a LIST chunk of some sort.  However all I'm seeing is a 'data' marker followed by length of the data chunk, followed by the (I presume to be) data chunk payload.  I have looked at bundles I've created over the years and I can't find a single bundle that has an explicit LIST chunk.  What I see is:
 
RIFF
file length offset
WAVE
fmt data
PAD
pad length
(maybe another PAD and pad length)
data
data payload
cwp1 (I presume Cakewalk project)
 
But, again, no information that I can see that describes the list of audio chunks in my bundle.
 
The only commonality I can find between bundles is that data chunks seem to be padded with (I'm guessing) a 16-byte boundary?  Is my understanding of this correct or am I missing where LIST may appear in the bundle file?  The difference between my corrupted bundle and perfectly-find bundles is that in certain spots in the data section, I'm seeing what appears to be less than a 16-byte boundary, sometimes an odd count of 0s, and an odd count of what I presume is audio mixed in between.
 
Could anyone shed some light on this?  Am I on the right track by trying to use some kind of binary editor to grab the "tracks" (i.e. audio chunks) from the data chunk payload?
 
IMO this is one of those corner cases that I don't believe is an issue with Sonar but rather data corruption (i.e. bit rot) that happened over the years when I migrated to new systems and backups.  Speaking of backups, the backups that have been retained all show the same problem for this one bundle.  Definitely looking for some direction if you have time to entertain this.

Did you try opening the bundle in safe mode by holding shift while opening?
kakku

Yes, doesn't crash Sonar in safe mode, but still some issues with the audio files.
 

We've been through the bundle file corruption controversy before, here's the short form:
 

• I've asked if anyone saved a bundle file, opened it after saving, and there was corruption. So far no one has said that has ever happened, which would indicate the file format is not a problem. All examples of corruption occur with older files, typically many years old.
• Bundle files are like zip files because they are just a single file. If something goes wrong, it can screw up the whole file. With per-project folders, there could be media damage that destroys portions of an audio file but the rest could be recovered.
• You cannot trust storage media long-term. Flash RAM loses cells, CD-Rs (which are not as robust as CD-ROMs) deteriorate especially if exposed to heat or humidity, hard drives lose sectors, etc. A single backup to a bundle is risky. A bundle file is what I would use to transfer a project to another user, or if used for backup, as tertiary backup or temporary backup only. 

 
So...I don't know of a solution, but I seem to recall some people having success with recovering substantial portions of corrupted bundle files.

Thanks for your response.  Yes, what I'm looking for is a way to recover as much audio out of the bundle as I can.  I suspect the answer lies in the realm of either deleting corrupted portions of the data section (and rewriting the length ## of the data section) or understanding how audio is stored in the data section -- then constructing a new and separate wav from each chunk.
 
FYI, I pretty much stopped using bundles in 2004 (or maybe 2003?) once per-project folders were the norm.  It's always the old stuff that gets you.  :-(
 

I believe Cakewalk have some tools they can use to extract audio from corrupt bundles. Best contact tech support

Oh oh, here we go agin! Anyhow, my take is like Craig is saying that Buns when they go south are way worse than a CWP because you loose it all. Cakewalk should pitch in to help out with this issue because they are the ones who actually recommended Bun files as a back up when this was obviously bad advice. At least with a CWP file you still have the audio folder. 
I now recommend we also back up as a MID file as well. Mid files will always open, some of mine are 30 years old. Takes 20 seconds to back up any project as a Mid type 1 file. After all a lot of use put a lot of work into our drum tracks ect. Audio we can always re perform and do a better job right? 

johnnyV
Oh oh, here we go agin! Anyhow, my take is like Craig is saying that Buns when they go south are way worse than a CWP because you loose it all. Cakewalk should pitch in to help out with this issue because they are the ones who actually recommended Bun files as a back up when this was obviously bad advice.

 
To be fair, I think they pre-dated per-project folders and budget hard drives. Also, regardless of what backup anyone uses, "digital data is not real unless it exists in at least two places." I still have some bundle files remaining, but have duplicates of them just in case. One of these days I'll open and re-save as per-project, but I've already done that with the most important ones. 
 

I now recommend we also back up as a MID file as well. Mid files will always open, some of mine are 30 years old. Takes 20 seconds to back up any project as a Mid type 1 file.

Yes yes yes. And don't forget that if you're using any external MIDI gear, Sonar has great sys ex storage capabilities. When I was using Sonar with a digital mixer, it was great...I just played back the sys ex at the start of the file, and the mixer was magically set up and ready to go.
 
One more very important thing: You need to "refresh" backups. I archive all the articles I've written over the years. Material I wrote on 8" floppy drives back in the 70s was re-saved a few years later to 5.25" disks, along with more recent material. Then to 3.5 floppies, then zip drives. Finally CD-Rs become reasonable and then they got saved again along with other work I'd done up to that point. When DVD-Rs became affordable the data was transferred again, but I'm going to transfer again to Blu-Ray in a month or two. However, I'm keeping the previous CD-Rs and DVD-Rs so now my digital exists will exist in at least four places - the three optical media. a hard drive, and in the case of my Mac, the Time Machine backup hard drive.
 
Digital storage media is quite robust, but it's by no means purfekt. There have been several times I haven't been able to open files, and it was great to just reach for a twin and open from that instead.

Anderton
Also, regardless of what backup anyone uses, "digital data is not real unless it exists in at least two places."

I'd add "which aren't under the same roof".
 

BTW, I in no way intended to start a holy war about bundles (good, bad, indifferent, etc).  While my implementation and infrastructure for creating backups, testing backups and restore, maintaining multiple copies, and generally being a competent IT guy has improved over time, this is obviously a project where I didn't follow my own rules way back when.  I can't fault Sonar for that.
 
At the same time I am also somebody who tries to dig in and solve a problem if I can.  In this case I am trying both to learn something and to show a little bit of ingenuity to dig myself out of a hole if I can.  :-)
 
BTW, this is the hardest I've ever worked to copy 8 drum tracks from one place to another -- just so I can put them in a new project and make samples for another project where the drum sound would be "perfect".