Topic: Edirol R-09 bad file

[gewwang]

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.

[udovdh]

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.

[gewwang]

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.

[hobbes4444]

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???

[live2496]

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

[hobbes4444]

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

[live2496]

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

[hobbes4444]

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

[hobbes4444]

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

[hoyt]

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

[live2496]

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.

[gewwang]

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.

[hobbes4444]

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.

[live2496]

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.

[Brian Skalinder]

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.