Thanks for all the help and suggestions!!!

It turns out that the files were the correct size, but since the files never got officially saved, the length parameter in the wave file header block wa set to -1. I used AUdition to find this out.

It turn out that wav files for audio recorded in standard formats, are aligned in such a way that they can be read in as raw data, with the conversion set the correct format.

So in my case I used AUdition to read in a 44.1 mono 16 bit file in intel format and WALA the whole thing was there!!

I converted them to wave files, and saved them and I am up and running!!

Thanks again...

Hi,
 
New here.
 
Something very similar just happened to my Sonar 7 system, but instead of power off, Sonar crashed when I hit space bar to stop recording. 
 
Computer is :
3.01GHz pentium 4 with 1.00GB RAM
RME Hammerfall HDSP-9652 Sound card
Sonar 7
Has been running stable for a while now. 
 
2 1/2 hours,
26 tracks,
48KHz, 24 bit
Live recording of open air Carols show
ADAT direct outs from PA mixer - a Yamaha M7CL-48 with PA mixer running word clock master and the computer slaved to the console
I sat my PC monitor behind the console's touch monitor so I could observe sonar's record levels without moving my head and nothing went over -9dB all night

I did have to increase the latency on the sound card driver to get it to record all the tracks without dropping out
 
Each file is 1.3GB and a bit, so it lt all appears to be there.
 
I tried to find my way around audition, but not happening..  maybe still too gig tired.  When importing raw data, in little endian, I get very distorted high level signals, When importing BIG endian, I get distorted low level signals.. or maybe vice versa ... either way, niether is clean and usable.  Audition always says the imported file is 32 bit float, but my files were recorded at 48Khz, 24 bit PCM(?) so I am guessing it is a bit depth problem.  only downloaded audition this morning and the manual doesn't appear to say how to change the current project's bit depth. 
 
Any hints?
 
Regards
Linz

Sonar does use 32 bit, Funny, I just recorded an over 2 hour choir performance too!  6 tracks on an old P4 laptop. Might be that I had put a 7200 RPM HD in, I think that's important for streaming. CPU never passed 12 %. 
You'll just have to get used to the new software.  I should open those files no problem.

I saved between breaks in the music, The MC gave me his cue sheet so I new where they would be. There is a few things you need to do for a successful live recording,

Prepare, Prepare Prepare.   

Linz, a few points.

First, this thread is 5 years old, you'll get a much better response by posting a new topic

Second, now don't take this the wrong way, but your pc is MASSIVELY underpowered for this sort of activity. 1Gb of RAM simply isn't enough.

Thirdly - depending on your Operating System, you might have reached the 2Gb limit on file size which any 32 bit version of Windows imposes, hence the crash

HTH

Perhaps they are actually 64-bit files, not 32-bit. Starting at version 7, SONAR automatically writes 64-bit audio files whenever the recorded data would otherwise exceed the 2GB limit for 32-bit files. The version of Audition that I have (3.0) does not support 64-bit audio, but Sony (who invented the w64 spec) Sound Forge should be able to. 64-bit files, according to CW documentation (I've never created a 64-bit audio file myself), are given a .w64 extension rather than .wav.

Download HexEdit and save 2 alternate versions of the WAV file...  remove 1 byte from the top of one and 2 bytes from the top of the other.. then try again...  24 bit audio is saved using 3 bytes... you should attempt to load the RAW data using an offset into the top of the sound file... Sound Forge allows that without having to use HexEdit.

Rail

That's going to corrupt the file, I'm afraid. The first 4 bytes are what identifies it as a RIFF WAVE file. Altering that with a hex editor would most likely make most audio software just barf it back out.

bitflipper


That's going to corrupt the file, I'm afraid. The first 4 bytes are what identifies it as a RIFF WAVE file. Altering that with a hex editor would most likely make most audio software just barf it back out.

He's opening the files as RAW files - so the headers are going to be noise at the top and have to be edited out -- if he's trying to do a raw data recovery it'll work

Some free utilities I've written: 
 
http://railjonrogut.com/HeaderInvestigator.htm

http://railjonrogut.com/sdTwoWav.htm

http://railjonrogut.com/WAV%20Saver.htm


Rail

OK, I see what you're saying. Treat the file as raw data and the header can be ignored completely, save for a few milliseconds of noise at the front. Figure out what the header should contain and re-write it, thus salvaging pretty much any wave file as long as you can figure out what its format originally was. I'll buy that. But it still wouldn't be the first course of action I'd recommend to the average user! 

Thanks everyone for your help.

I finally got it solved, but audition wasn't enough on it's own.  I had to re-create as much of the headers as I could by hand first, including calculate the file length twice (in hex) with different offset values for each block it occurs in, then audition was able to read the data section accurately.  After fixing the headers for one file, I simply copied it to the other 24 files as they were all the same format and length.

It took a while with loading the files into hex edit, copy/paste, save as, load into audition, save as 24 bit with dithering, load into sonar.... And don't forget to move the original corrupt file and the hexedit output file to the other hard drive to make sure I didn't run out of space.

Regards,
Linz...