Issue with bundle corruption

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.

Yes, doesn't crash Sonar in safe mode, but still some issues with the audio 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.  :-(
 

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? 

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".
 

nvp1971
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.

Thanks for the clarification. There have been several threads about how the bundle format is "flawed" from people who don't understand the limitations of digital storage media. Although bundles are not my first choice for backup, they do work. As long as people think the problem doesn't relate to storage media, then they'll continue to experience problems with backups, whether Sonar or some other program. So I take any opportunity I can to remind people that backup is an ongoing process, not a set-and-forget one.

Yes to multiple backups and media, and as Paul says to another physical place away from your work area.

nvp1971
That's exactly the thread I was looking for and somehow could not find on my own.  Thanks, scook!
 

Here is the magic Google search string I used
site:forum.cakewalk.com noel bundle riff wave
The thread  with message 1417418 was the first returned

nvp1971

scook

nvp1971
That's exactly the thread I was looking for and somehow could not find on my own.  Thanks, scook!
 

Here is the magic Google search string I used
site:forum.cakewalk.com noel bundle riff wave
The thread  with message 1417418 was the first returned

It's absolutely crazy to me that I could not find this on my own but thanks again for pointing me in the right direction!

No it's not crazy!! It was just a very good description scook came up with. I run into this often. I can't find what I am looking for. Iask around and someone finds it. When I ask how they did it when I couldn't, they give me the search "string" they used. And I keep saying to myself, "I have to learn to do that!"

scook

nvp1971
That's exactly the thread I was looking for and somehow could not find on my own.  Thanks, scook!
 

Here is the magic Google search string I used
site:forum.cakewalk.com noel bundle riff wave
The thread  with message 1417418 was the first returned

Also, you referenced forum thread 653751 in that thread but that item seems to be gone now.  Do you recall the details of this?

scook
The message is still there, use the new FindPost function .

Interesting!  So looks like I would have to extract each audio chunk (guess it's 16-byte boundaries between those), then dig into the cwp to see what length of audio I would need to extract from which chunk.
 
Maybe not worth the time but now I'm intrigued.
 

bapu
 
The other aha! moment was that I should probably open every project once after any major upgrade from CW (unless a patch was to address a specific project related opening problem).
 
Since I pretty much have upgraded (thus far) for each new version that process insures that at least once a year I will be verifying that all my past projects still "work" .

 
Yep, I do that too, and that's why I precede each filename with the SONAR version, e.g. "X2_", X3_"
Helps tons when refreshing old projects in new DAW s/w.