Taperssection.com
Gear / Technical Help => Recording Gear => Topic started by: hobbes4444 on August 25, 2006, 11:15:04 AM
-
So, in doing some research here, it looks like I might be able to save/recover the file I recorded last night. I have a 1.2 Gb file according to windows (i transferred the file to my PC HD), but it is not recognized as a .wav file. The Edirol shows this file as "Improper song" but thankfully it shows that the 4Gb card has 675mb remaining (there are 3 files in total on the card, each at 1+ Gb.). so i know i have a file, just likely one with a corrupt header. So is the best way to try to recover this file to get audiohack? The only other program I have is audacity. Could i import the file with that? I'm very unsavvy when it comes to using command line prompts, etc., so any handholding to work this through would be appreciated. And if anyone is interested, the corrupt file is Suzanne Vega's late set at the RegattaBar last night. Happy to share it with folks who can help before I hopefully get it on dime (DPA4061>R-09). IT should have come out better than the first set since the bar was mostly empty for the late show, and she was definitely looser. . .
Thanks as always,
Dave
-
Rename to .raw and try to import the file. Was asked before in the past few days and worked fine as a solution.
-
Rename to .raw and try to import the file. Was asked before in the past few days and worked fine as a solution.
I thought that solution was in relation to Soundforge. . . though after a little more research it seems, as you suggest, that any program that can accept .raw files could work with this out. will try this solution with audacity.
Thanks. . .
Dave
-
Rename to .raw and try to import the file. Was asked before in the past few days and worked fine as a solution.
importing raw file didn't work.
tried audiohack. not sure what exactly happened. i have a file that is 44 bytes, and i'm not sure what to do now. ..
-
If the file has valid audio data, but no or a hosed header, CD-Wave should open it. IMO, best to try on the original file, not the one that's been processed by audiohack. (Dunno if audiohack creates a copy on which to work, or if it works on the original file.)
-
Rename to .raw and try to import the file. Was asked before in the past few days and worked fine as a solution.
importing raw file didn't work.
tried audiohack. not sure what exactly happened. i have a file that is 44 bytes, and i'm not sure what to do now. ..
Audiohack creates two files. Do both have only 44 bytes? If so, then Audiohack could not determine the start of the data chunk.
To fix this manually, you would have to edit the header and then run it through Audiohack. This solution is only viable if you are comfortable with editing using a hex editor. It is not that difficult, really.
Or you could import the audio as raw into an audio editor.
Gordon
-
Rename to .raw and try to import the file. Was asked before in the past few days and worked fine as a solution.
importing raw file didn't work.
tried audiohack. not sure what exactly happened. i have a file that is 44 bytes, and i'm not sure what to do now. ..
Audiohack creates two files. Do both have only 44 bytes? If so, then Audiohack could not determine the start of the data chunk.
To fix this manually, you would have to edit the header and then run it through Audiohack. This solution is only viable if you are comfortable with editing using a hex editor. It is not that difficult, really.
Or you could import the audio as raw into an audio editor.
Gordon
yes, both files are 44 bytes, and the cmd line indicated input file has no data chunk. so i'm trying to create a PCM file with audiohack. same result.
audacity has the capability to import raw files, but i couldn't get it done properly. the original file is 24/44.1 on the R-09. there seem to be a lot of options in importing raw and i'm not sure which to use. tried 24 bit signed PCM and little endian and that yielded noise.
no clue what i'd be doing re hex editor. . .
i think i have cdwave, i'll try that next.
thanks so far, for the help . ..
-
cd wave said cannot open RIFF chuck, file is not a valid wave file. so does that mean i have a f'd header that will have to be manually edited? i think a friend of mine has cool edit, so maybe i can get the file to him to try. and i can still try chkdsk i guess, tho i tried that on the file that i copied to the HD, and nothing appeared wrong.
-
FWIW, I had the exact same problem and I haven't been able to solve it. So far.
http://taperssection.com/index.php?topic=68518.msg944528#msg944528
-
audacity has the capability to import raw files, but i couldn't get it done properly. the original file is 24/44.1 on the R-09. there seem to be a lot of options in importing raw and i'm not sure which to use. tried 24 bit signed PCM and little endian and that yielded noise.
If you have a hosed WAV header the 44 bytes are not dividable by 6 (2 times 3 bytes per sample) causing noise.
So you need to add 4 bytes to the header or lose 2 bytes.
Or copy over a 44-byte wav header using a hex-editor. You could then even fill in the length etc for the data chunk.
no clue what i'd be doing re hex editor. . .
Get one.
Have a look at the start of a valid WAV file. Have some info on the WAV header at hand. E.g. http://www.sonicspot.com/guide/wavefiles.html
Now open the problem file. See if it has traces of a WAV header. Fill in the blanks or missing info.
-
cd wave said cannot open RIFF chuck, file is not a valid wave file. so does that mean i have a f'd header that will have to be manually edited? i think a friend of mine has cool edit, so maybe i can get the file to him to try. and i can still try chkdsk i guess, tho i tried that on the file that i copied to the HD, and nothing appeared wrong.
I will continue on the RIFF header edit scenario. What you have to do is make the first 44 bytes of this file match that of a good file recorded using the same settings.
Download Ultra-Edit from www.ultraedit.com . Open up your file with it and it should switch to the hex view because it will detect it as being a binary file. Now open a good file. Set the Window so that you can compare the files in the same window. (From the menu this is Window->Tile Horizontal or Window->Tile Vertical )
Make sure that the first 44 bytes of both files match exactly. Ultra-Edit will allow you to change values by positioning the cursor on the bytes you wish to change. Save the RIFF corrected file.
Now redo the audiohack procedure and you should get two files. The first file will have the RIFF header counter and data chunk counter corrected based upon the file size.
If you get a file that can be opened in an audio editor but it contains white noise, then the actual offset to the data is incorrect. With many software pacakges the riff header should take up 44 bytes, but this is not always the case if the fmt chunk is larger or there is a pad chunk inserted into your file by some process.
In that case, you would need to import the file as raw and specify the start of the pcm data. Ultraedit can help you determine the start of the data chunk. I use Samplitude 7 for raw data import because it has a way to specify a starting offset to the samples. With 24-bit data one of six offsets would be correct. I would try separate attempts with 45, 46, 47, 48, 49, or 50.
Audiohack also has an option to strip the RIFF header from the file, but it has to be able to determine where the data chunk starts. For your file this can't be determined. However, I guess I need an option so that the user can specify a certain number of bytes to strip from the beginning of the file. That way it could be subsequently imported to any software package that has the raw import capability.
Gordon
-
If you have a hosed WAV header the 44 bytes are not dividable by 6 (2 times 3 bytes per sample) causing noise.
So you need to add 4 bytes to the header or lose 2 bytes.
Or copy over a 44-byte wav header using a hex-editor. You could then even fill in the length etc for the data chunk.
Hi Udo,
The data chunk only needs to be a multiple of 6 bytes (for 24-bit stereo).
For many softwares, 44 bytes of RIFF+fmt chunk is normal.
Gordon
-
Well I am having the same issue. Apparently the R-09 has a problem saving more than one 1+ GB file on the same 4GB card. But I don't think its a predictable occurance, or is it?
I recorded one set @ 24/48 and the file is 1.05 GB it saved fine
I recorded a second set again @ 24/48 the file is 1.4 GB and it the R-09 flashes "improper song" when I try to play it. I copied the file to my mac and it won't open in Spark XL or with the Quicktime player.
The questions is, does anyone know of a good free wav header editor for the Mac?
-
Well I am having the same issue. Apparently the R-09 has a problem saving more than one 1+ GB file on the same 4GB card. But I don't think its a predictable occurance, or is it?
Perhaps other people exprienced the same?
Maybe some more testing can do the job?
(just set for 24/48 and let it roll...)
-
Well I am having the same issue. Apparently the R-09 has a problem saving more than one 1+ GB file on the same 4GB card. But I don't think its a predictable occurance, or is it?
Perhaps other people exprienced the same?
Maybe some more testing can do the job?
(just set for 24/48 and let it roll...)
I've only had one other file the R-09 couldn't recognize like this other one. It was a 2.8 GB file (3 hour show @ 24/48) it too said "improper song", but when I transferred it to the mac it opened up fine in Spark XL. I think the only reason the R-09 wouldn't recognize it is because it was over 2GB.
So when it said "improper song" I thought I'd just transfer the file and open it up in Spark XL like the last one, but nope it won't open.
So I suspect the problem here is that the R-09 sometimes won't write the .wav file header correctly if there is already one file over 1GB on the card.
-
i might have accidently reproduced this issue tonight. 1st file was 963 mb and plays on the r-09. 2nd file was 2:15 but shows on r-09 as 1 sec and 1756 mb. i'll try to recover it on my laptop today.
-
If the bad file is a 24-bit recording I think the best way is to skip the header and copy all the PCM samples to a .raw file.
In that case there is no problem with the WAV-header not being a multiple of 6 bytes (2 times 3).
In Unix one could use the dd command.
-
i might have accidently reproduced this issue tonight. 1st file was 963 mb and plays on the r-09. 2nd file was 2:15 but shows on r-09 as 1 sec and 1756 mb. i'll try to recover it on my laptop today.
I was able to recover my file just fine with ultraedit and audiohack.
My 1756 MB file as reported on the R-09 showed up correctly as 2.4 GB on the laptop in windows file manager. I then manually edited the first 44 bytes in ultraedit and then ran the file thru audiohack which created a 2GB (2 hr 1 min 21 sec) file and then the overflow file which was about 350 MB (20 min 36 sec).
Thanks again to Gordon for audiohack.
-
Uhm, ok. So i have ultraedit running and opened the 2 files, a good and bad. I read through some of the info suggested on what the headers should look like in hex, and I'm unfortunately lost. Couldn't figure out how to cut and paste data from ultraedit. . .
i'm assuming that in ultraedit, each character is one byte, so i need to change 22 pairs in the bad file to mirror the good file.
So what I did was change the first line of the bad file that looked something like this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00000000h: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ; u'd..0Q..,ji (the xx were all 2 character combos)
to look like the good file which looks like:
00000000h: 52 49 46 46 24 F8 1D 50 57 41 56 45 66 6D 74 20 ; RIFF$o.PWAVEfmt
when i changed the characters in the bad file, the string at the end changed to read RIFF$oPWAVEfmt like the good file.
i then changed the next 6 pairs of characters on the 2nd line
I ran the new saved file with corrected info through audiohack.
Again, I wound up with 2 1kb files, but this time it reported having a PCM header. BUt still no aduio file. Do I need to change more values in ultraedit???
-
Yes. Audiohack has to find the literal string "data", otherwise it doesn't know where the pcm samples begin.
I would just change the first 44 bytes of the bad file to match that of the good one. Then re-run the bad file through the program.
Gordon
-
Yes. Audiohack has to find the literal string "data", otherwise it doesn't know where the pcm samples begin.
I would just change the first 44 bytes of the bad file to match that of the good one. Then re-run the bad file through the program.
Gordon
how does one measure the first 44 bytes? is each character a byte, or is each pair of characters a byte? i did the former in ultraedit and still no luck.
thanks to everyone thusfar for the assistance. this is really foreign territory for me, and were it not for the guidance here i would have already erased the file. but it seems like i actually have a shot at fixing this . . .
-
how does one measure the first 44 bytes? is each character a byte, or is each pair of characters a byte? i did the former in ultraedit and still no luck.
In hexadecimal, each pair of characters represents one byte. The range is 00 to FF.
Tip: If you mark or select a range of bytes with the cursor, ultra-edit tells you how many bytes are selected in the lower right.
The default ultraedit display is 16 bytes of hex on the left and the ascii representation of that on the right.
After editing the header in the bad file, make sure that you see the data marker "data" somewhere in the ascii display on the right. I haven't seen your original file, so I have no way of knowing how many bytes you need to copy. Somewhere in the range of 44 bytes is usually correct for most wav files, but it depends upon the size of the "fmt " chunk. I have seen format chunks of varying sizes.
Gordon
-
how does one measure the first 44 bytes? is each character a byte, or is each pair of characters a byte? i did the former in ultraedit and still no luck.
In hexadecimal, each pair of characters represents one byte. The range is 00 to FF.
Tip: If you mark or select a range of bytes with the cursor, ultra-edit tells you how many bytes are selected in the lower right.
The default ultraedit display is 16 bytes of hex on the left and the ascii representation of that on the right.
After editing the header in the bad file, make sure that you see the data marker "data" somewhere in the ascii display on the right. I haven't seen your original file, so I have no way of knowing how many bytes you need to copy. Somewhere in the range of 44 bytes is usually correct for most wav files, but it depends upon the size of the "fmt " chunk. I have seen format chunks of varying sizes.
Gordon
That is exactly what I needed to know, and hoped to find out! So I have some additional repair work to do. I did see a "data" marker on the far right in the good file. So I'll redo and try again. Thanks yet again Gordon!! I know this will help other R-09 users!! For now, i think I'm going to stick with a 2Gb card till Roland pushes out support for the 4Gb cards. . .
-
Make sure that the first 44 bytes of both files match exactly. Ultra-Edit will allow you to change values by positioning the cursor on the bytes you wish to change. Save the RIFF corrected file.
Now redo the audiohack procedure and you should get two files. The first file will have the RIFF header counter and data chunk counter corrected based upon the file size.
If you get a file that can be opened in an audio editor but it contains white noise, then the actual offset to the data is incorrect. With many software pacakges the riff header should take up 44 bytes, but this is not always the case if the fmt chunk is larger or there is a pad chunk inserted into your file by some process.
In that case, you would need to import the file as raw and specify the start of the pcm data. Ultraedit can help you determine the start of the data chunk. I use Samplitude 7 for raw data import because it has a way to specify a starting offset to the samples. With 24-bit data one of six offsets would be correct. I would try separate attempts with 45, 46, 47, 48, 49, or 50.
Audiohack also has an option to strip the RIFF header from the file, but it has to be able to determine where the data chunk starts. For your file this can't be determined. However, I guess I need an option so that the user can specify a certain number of bytes to strip from the beginning of the file. That way it could be subsequently imported to any software package that has the raw import capability.
So, I am making progress. I was able to fix the complete RIFF header on the bad file. I opened with audiohack and it started chugging along immediately!!! However, when I opend that file in Audacity, it was white noise as you speculated was possible. So if i rerun the file through audiohack in /N mode, will that strip the header and save only the PCM data? And then I could import to one of the software editors as a raw file. . .
-
Wow, I have never had a problem like this with one of my wav files, but I am impressed by the amount you guys know... +t's for helping someone out!
--hoyt
-
So, I am making progress. I was able to fix the complete RIFF header on the bad file. I opened with audiohack and it started chugging along immediately!!! However, when I opend that file in Audacity, it was white noise as you speculated was possible. So if i rerun the file through audiohack in /N mode, will that strip the header and save only the PCM data? And then I could import to one of the software editors as a raw file. . .
Yes. But the software you import into must have a way to specify the starting offset of the data. For some reason, the framing is off. Samplitude can do this. I'm not familiar enough with Audition or Wavelab to tell you what to do with them.
-
So, I am making progress. I was able to fix the complete RIFF header on the bad file. I opened with audiohack and it started chugging along immediately!!! However, when I opend that file in Audacity, it was white noise as you speculated was possible. So if i rerun the file through audiohack in /N mode, will that strip the header and save only the PCM data? And then I could import to one of the software editors as a raw file. . .
Yes. But the software you import into must have a way to specify the starting offset of the data. For some reason, the framing is off. Samplitude can do this. I'm not familiar enough with Audition or Wavelab to tell you what to do with them.
Wavelab v4 and v5 let you specify offset (0,+1,+2). I'm pretty sure Cool Edit Pro v1.2 doesn't have this option.
-
Good lord, is there any software under $700 that can fix this f'ing file??? Sorry, frustration starting to set in. >:( WEll, I've learned my lesson, and hopefully it is one that will not be repeated with a 2Gb card. . .
Thanks again for your contined advice and guidance. For this alone, I felt compelled to donate a little to the site, though it would more properly be directed at the folks in this thread ;) I'll try one or two more of the tips I haven't tried yet. Maybe soundforge or audition will miraculously open the file. I have a buddy with both of those programs that will give it a shot.
-
The cheap way to do it...
Create a one byte file with an ascii null (byte value 00).
Use the dos copy command to join that one byte file and your pcm data. something like copy /b file1+file2 newfile.
(I'm not sure on the syntax, but something like that).
Import that into your application. This will shift all of the framing by one byte.
Reiterate as necessary.
P.S. The Samplitude SE version may support the import feature. For 49 euro it is a good deal. But I have not used the SE version, so I am not certain of whether it has the import w/offset feature. Likely it does as this is a basic program function.
-
Wavelab v4 and v5 let you specify offset (0,+1,+2). I'm pretty sure Cool Edit Pro v1.2 doesn't have this option.
I don't recall about CEP v1.2, but v1.5 and higher (CEP / Audition) have the offset option for opening RAW files.
-
Hey now, I don't want to appear too lazy ;D but I just cannot get this file straightened out and I really want to get these 2 sets out there. This is the first show that Ms Vega has done with her daughter singing background on a couple of tunes.
So I want to grovel for some help. If some kind soul who has fixed files with these header and offset issues could please help out I would be extremely grateful! I can send the original and somewhat fixed file (replaced the header with audiohack and have a recognizable file, but shows up as white noise) in addition to discs, etc; whatever you want! I know there have been guides posted here, but after many many hours of following the advice trying to get this file sorted out, I just can't get it right and I can't take it anymore! So please please please. . .
-
I actually had something similar happen last night. My recorder froze up at 51 minutes into a show :( The only way to get the thing to do anything was to open the battery door and take them out to reboot the device. So now I have an incomplete source as well as a file that won't open in editors. I'm not impressed....
I think I found a much easier way to do this, not sure if it will work for you guys but it did for me.
1) Open the WAV file that is giving you trouble in CDWave.
2) It will ask you if you want to adjust the size of the header. Click YES.
3) Then it will say it reports that the file header has a size of zero and do you want to continue. Click OK.
4) Make a track somewhere before the band starts, only save the second track, let it discard the first track.
5) The new file you created will now open properly in any editing program.
Like I said, this worked for me, and maybe not for you but I thought it would be worth trying.
Clint
-
I actually had something similar happen last night. My recorder froze up at 51 minutes into a show :( The only way to get the thing to do anything was to open the battery door and take them out to reboot the device. So now I have an incomplete source as well as a file that won't open in editors. I'm not impressed....
I think I found a much easier way to do this, not sure if it will work for you guys but it did for me.
1) Open the WAV file that is giving you trouble in CDWave.
2) It will ask you if you want to adjust the size of the header. Click YES.
3) Then it will say it reports that the file header has a size of zero and do you want to continue. Click OK.
4) Make a track somewhere before the band starts, only save the second track, let it discard the first track.
5) The new file you created will now open properly in any editing program.
Like I said, this worked for me, and maybe not for you but I thought it would be worth trying.
Clint
Well I did try some of the other suggestions similar to this one. I didn't try creating a new track. But when this file opened up in cdwav it was white noise.
Were you using a 4 Gb card by chance?
-
Yep - 4 gig Transwhatever - same one everyone else has.
-
The cheap way to do it...
Create a one byte file with an ascii null (byte value 00).
Use the dos copy command to join that one byte file and your pcm data. something like copy /b file1+file2 newfile.
(I'm not sure on the syntax, but something like that).
Import that into your application. This will shift all of the framing by one byte.
Reiterate as necessary.
P.S. The Samplitude SE version may support the import feature. For 49 euro it is a good deal. But I have not used the SE version, so I am not certain of whether it has the import w/offset feature. Likely it does as this is a basic program function.
Just thought I would put in my .02 that this quick and dirty way worked for me... T+ for the quick and dirty solution... Just how I like it. :-}
Here is the command I used......
copy /B d.bin + CR09_0005.wav test1.wavd.bin = 1 byte file containing '00'
CR09_0005.wav = backup copy of the fubared wav file directly from the 09
test1.wav = resulting .wav file that plays properly. :-}
Thanks again,
Dana
-
The cheap way to do it...
Create a one byte file with an ascii null (byte value 00).
Import that into your application. This will shift all of the framing by one byte.
Just thought I would put in my .02 that this quick and dirty way worked for me... T+ for the quick and dirty solution... Just how I like it. :-}
Here is the command I used......
copy /B d.bin + CR09_0005.wav test1.wavd.bin = 1 byte file containing '00'
CR09_0005.wav = backup copy of the fubared wav file directly from the 09
test1.wav = resulting .wav file that plays properly. :-}
Thanks again,
Dana
This is great info. Thanks!! Could you also post how you created the d.bin one byte file for us computer illiterates! ;D
Thanks again to all of the experts here for creative solutions to this problem. Maybe the problem will go away if we ever get 4gig support. . . :-\
-
In ultraedit select a new file. Type in any character. Hit Ctrl-h to goto hex mode. You will see one set of double digit numbers. Change to 00 and save. I only had to run the copy command once. However, if your offset is more than one you will have to run it more than once.
-
Not sure if this will help anyone here or not.
Last night I taped a show on my R-09 that came out slightly larger than 2Gb. As others here have experienced I was not able to replay the file in the R-09. I was able to copy it to my PC. It would play in Winamp but Soundforge and my other wave editing programs would not open it because of a codex problem?
CDwave would open it and I was able to chop it to smaller chunks but still was unable to open them in the wave editors. My guess is there was a problem in the header info? Flac frontend would not accept these files either.
What I ended up doing was converting the two files to FLAC via CDWave and then opening them back to Wave files.
The size of both files changed by about 8 bits, and are now able to be opened in Soundforge.
I am not sure what really happened or if this was the right way to go about this, but it worked.
Now, off to upgrade the firmware in the R-09.
Oh yeah, if you have the opportunity to catch a Big Bad Voodoo Daddy show, by all means do it. Great time, great performance!
-
Do we have 110% confirmation that the new firmware is perfectly seamless?