Odd Prompt When Converting SAWStudio64-output WAV to MP3

[Dave Labrecque]

Using SAWStudio 32-bit I don't get this. But I get this message after converting a SAWStudio64-output WAV file to MP3 using dBpoweramp:

Information converting to mp3 (Lame), 'D:\Projects\FILENAME.wav' to 'D:\Projects\FILENAME.mp3'
Warning Chunk is out of RIFF area (but still inside file). [clRIFFHandler::ScanFile]


I don't get the prompt using Sound Forge 14's output WAVs, either. What does it mean, and what can I do about it?

Anyone?

[John Ludlow]

Dave, RIFF is a file format that WAVE apparently extends for its own use. I had never heard of RIFF before or understood its relationship with wave files until Googling it just now. RIFF seems to have this concept that it calls a 'chunk'. From what I can gather, there are different kinds of chunks used to describe the content of the file, rather than being the actual content. Therefore, I presume that maybe there is a chunk for author, one for title, etc. So, the warning message seems to be indicating that dbPowerAmp believes that it has located a chunk within the data (music) area of the file, which doesn't seem good.

I'm surprised to know that dbPowerAmp is still kicking. I had understood that it was dead long ago - but a quick Google shows me that it is not. Also, my antivirus pegged my old copy as being infected (or infecting) many years ago now and I switched to FreeStar wav/mp3 converter. So, I wonder what would happen if you tried a different converter on the same file. That might tell you which software side the problem is on.

[Dave Labrecque]

Dave, RIFF is a file format that WAVE apparently extends for its own use. I had never heard of RIFF before or understood its relationship with wave files until Googling it just now. RIFF seems to have this concept that it calls a 'chunk'. From what I can gather, there are different kinds of chunks used to describe the content of the file, rather than being the actual content. Therefore, I presume that maybe there is a chunk for author, one for title, etc. So, the warning message seems to be indicating that dbPowerAmp believes that it has located a chunk within the data (music) area of the file, which doesn't seem good.

I'm surprised to know that dbPowerAmp is still kicking. I had understood that it was dead long ago - but a quick Google shows me that it is not. Also, my antivirus pegged my old copy as being infected (or infecting) many years ago now and I switched to FreeStar wav/mp3 converter. So, I wonder what would happen if you tried a different converter on the same file. That might tell you which software side the problem is on.

The weird thing is that SAW32-rendered WAVs go without complaint in dBpoweramp, but SAW64 WAVs do not. Yeah, I've been riding my $30 (or whatever it was) for years and years. There are still occasional free updates, I think. I love being able to right-click and convert as many at a time as I like in File Explorer.

FWIW, I can do the conversions in Sound Forge without issue. Just not as convenient. Oh, it also doesn't offer the 96 kbps/48 KHz/joint stereo option I'm looking for as the destination MP3 format. But it does point to a peculiarity with the specific pairing of SAW64 and dBpoweramp.

[John Ludlow]

But, what about converting the SS64 file using a a different converter? Here is what I'm trying to get at: I think that maybe there is a new format for wave files for 64 bit computers since you bought dbPowerAmp. I saw references to a format called, "Wave64" that is relatively new. If SS uses it, and dbPowerAmp is too old to know about it, then maybe there's a situation in which it is expecting data (music) at that location, but instead it's still header - and the field identifier on the 'chunk' is something dbPowerAmp recognizes from the previous version. Since it doesn't know any better - it presumes the chunk must be in the wrong place. Whereas, in reality, the header area on the file (containing all the chunks) has expanded and the data portion begins a little later.

Anyway, in that case, dbPowerAmp might report exactly the way it has. And, if a more recent conversion utility has no difficulty with the file - then it's probably confirmed.

Just a stab in the dark. For what it's worth, I see that there is an opportunity to download that codec here: https://www.dbpoweramp.com/codec-central-wave64.htm. Although - it says it must be at least Windows XP. So... maybe dbPowerAmp just isn't new enough to handle it. Worth a try isn't it?

[Dave Labrecque]

But, what about converting the SS64 file using a a different converter? Here is what I'm trying to get at: I think that maybe there is a new format for wave files for 64 bit computers since you bought dbPowerAmp. I saw references to a format called, "Wave64" that is relatively new. If SS uses it, and dbPowerAmp is too old to know about it, then maybe there's a situation in which it is expecting data (music) at that location, but instead it's still header - and the field identifier on the 'chunk' is something dbPowerAmp recognizes from the previous version. Since it doesn't know any better - it presumes the chunk must be in the wrong place. Whereas, in reality, the header area on the file (containing all the chunks) has expanded and the data portion begins a little later.

Anyway, in that case, dbPowerAmp might report exactly the way it has. And, if a more recent conversion utility has no difficulty with the file - then it's probably confirmed.

Just a stab in the dark. For what it's worth, I see that there is an opportunity to download that codec here: https://www.dbpoweramp.com/codec-central-wave64.htm. Although - it says it must be at least Windows XP. So... maybe dbPowerAmp just isn't new enough to handle it. Worth a try isn't it?

XP? Nothing new about that. I guess I'm not following your thinking.

W64 has been around for something like 20 years, originally created by Sonic Foundry. As I understand it, it's a modification of the WAV format to allow for audio files larger than the inherent WAV file size limit. It also has a different extension (W64).

This seems to lay things out pretty well: https://www.vegascreativesoftware.in...t-is-it--5373/

I'm pretty sure this isn't that.

[John Ludlow]

Does your copy of dbPowerAmp have access to that codec already?

[Dave Labrecque]

Does your copy of dbPowerAmp have access to that codec already?

It doesn't look like it. I'd have to download the codec, I guess.

I'm pretty sure WAV files aren't W64 files, though.

[John Ludlow]

Oh. OK.

Well... my thought was that if Sound Forge and SAW used the same format then dbPowerAmp should treat them the same. Since it doesn't and we presume then that they are different, then either SAW is producing a non-standard file, or else it's producing a standard, but different, file. It's hard for me to believe that Bob is building a non-standard file, so that leaves that the standard he's following is a different standard. You have an old converter program so maybe the new standard has appeared since the old converter program was made. It would fit the shape of the problem, at least.

I've read that nice explainer for wav64 now. I see why you're a little dubious. But, it seems like the only other possible explanation is that Bob has a bug in his generation of wav output files. And he's had a little practice doing those over the years. It's hard for me to believe that could be it and remain outstanding for this long. Why will other sound programs read them but not dbPowerAmp?

[Dave Labrecque]

Oh. OK.

Well... my thought was that if Sound Forge and SAW used the same format then dbPowerAmp should treat them the same. Since it doesn't and we presume then that they are different, then either SAW is producing a non-standard file, or else it's producing a standard, but different, file. It's hard for me to believe that Bob is building a non-standard file, so that leaves that the standard he's following is a different standard. You have an old converter program so maybe the new standard has appeared since the old converter program was made. It would fit the shape of the problem, at least.

I've read that nice explainer for wav64 now. I see why you're a little dubious. But, it seems like the only other possible explanation is that Bob has a bug in his generation of wav output files. And he's had a little practice doing those over the years. It's hard for me to believe that could be it and remain outstanding for this long. Why will other sound programs read them but not dbPowerAmp?

Tis indeed a mystery. But the last two dBpoweramp updates are more recent than SS's latest, so...

Actually, the last one is, for sure (I just updated tonight), but I haven't tested it, yet. So I should do that. The prior update I did a couple months ago, but who knows how long before that it had actually been released?

I doubt the WAV protocol has been expanded, but I could be wrong. But if so, why hasn't Bob made the same update to SS32's code? And why don't Sound Forge 14 WAVs cause the same prompt in dBpoweramp?

[MMP]

I use DB Poweramp Music converter every day and haven't seen this error message before. I use it for batch conversion as well. I don't have any guesses about why these particular files are causing issues other than SS typically ignoring the attribution data that can be added to Wave files in the RIFF chunks and perhaps some of your source waves had this data and it passed through in a corrupted way.