How to make WAV (Microsoft) signed 16 bit PCM

Hi,
I’m a bit puzzled here. I’m trying to make files for a client with very specific file requirements. They have asked me to supply them with “WAV (Microsoft) signed 16 bit PCM” just like Audacity (the freeware audio editor). I can’t seem to find any way to make these files with Wavelab 8 or even DSP Quattro. Eventually, I had to just download Audacity and export the files with those settings which are a default by the way.

So I’m wondering, how can I make files that match those settings via Wavelab? I’ve tried exporting and setting the settings to Wav 16 but the files do not work for the client and I don’t understand why or what the difference is.

So PG, (or anyone here), do you have familiarity with Audacity and its format settings of WAV (Microsoft) signed 16 bit PCM ? If so, can you share how to recreate the settings for file exports or batch processing in Wavelab 8?

I would be bummed to find out I have to use Audacity to convert all my sfx for this client instead of being able to do this in a batch processes via Wavelab.


Thanks!

Hmm, wav 16 bit is certainly the most used output format in WaveLab (this is “WAV (Microsoft) signed 16 bit PCM”).
2013-08-07_06-51-33.png
Maybe you include some meta data, or marker information, that your client does not like?
What does your client exactly say?

PG,
I found something in this mystery to share.
I used an application called “Media Info”. (There are free versions as well as a paid version in the app store.) and when I drag a WAV file made from WL8 onto it I see this:

Audio
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 665ms
Bit rate mode : Constant
Bit rate : 768 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 62.4 KiB (91%)


However If open the same WL8 file above and export it from Audacity, then view it in “Media Info” I see this:

Audio
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 665ms
Bit rate mode : Constant
Bit rate : 768 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 62.4 KiB (100%)



The difference is the last line (stream size).
I’ve repeated this test on 5 different files now and WL8 exports with settings of 16bit WAV always report a stream size of less than 100% while Audacity exports with settings of WAV (Microsoft) 16bit PCM) always show a stream size of 100%.

I don’t understanding this difference but file after file show this discrepancy and my client can’t use WAV files made by WL8 but can use the files if I open them and export them as WAV (Microsoft) 16bit PCM via Audacity.

Is WL8 not exporting the full header somehow?
Since quicktime will play both files without any issue I know the audio data is fully there, but the stream size shows a difference so that means the header and its “chunks” seem to be different - how I have no idea. Do you Know?

I don’t really know what this percentage means, but this could mean that WaveLab also adds meta-data, hence the audio size is not 100% of the data. This is perfectly legal.
So check exactly what you save with WaveLab.
You could send me a file, and I can check it for you if you like.

But I repeat my question: What does your client exactly say?

HI PG

I just PM’d you test files and the clients info.

Thanks for looking into this. I’m really puzzled as to the difference in .wav files made from Audacity compared to WL 8.

Thanks,
Chris

FWIW, although the client is always right, I have a suspicion that this is perhaps something that your client has seen on the internet and believes he ‘needs’.

Much like the requests we get to prepare a ‘glass master’ when what they are really looking for is a Production Master/DDP.

I have this suspicion because you have not been told why this is required and what purpose it will serve … and my humble experience is that, when you receive a genuine request for an uncommon deliverable, it is almost always accompanied with a reason why. This of course is to shift the onus of compliance onto you rather than being helpful.

As PG says … what exactly does your client say and what is the purpose of the deliverable?

In the file you sent me, I can see this option is activated:
2013-08-08_07-43-31.png
You should switch it off. It is perfectly legal, but some low quality players might not like it.
By default this option is Off in WaveLab 8.

Hi PG,

I thought I tried the optimize header checkbox both ways but I’ll try again tomorrow and see if it helps. Thanks for reviewing the files your promptness is genuinely appreciated!

And Rat,
I appreciate your response and efforts to help as well. A little more backstory here could help I suppose so here goes: My client is a very experienced audio programmer/coder and as the saying goes " this ain’t either of our first rodeo"! I can assure you there is a legitimate issue with the files and Its definitely not “something that your client has seen on the internet and believes he 'needs.” I’m working with this client on projects that use a custom built audio player and the .wav files I’ve delivered that I made in Wavelab 8 won’t load in that audio player however the very same .wav files work if I use Audacity to open and re-save them with the settings of Wav (Microsoft) Signed 16bit PCM which is an Audacity menu option for exports. So the problem is real and repeatable but the question is why? What is different. It’s got us both scratching our heads.

The client told me the .wav files made from Wavelab either had missing headers, (which I believe was an anomaly as I can’t recreate that error) or the Wavelab .wav files had extra “chunks” fields with data in them. I believe it was the instrument and sampler fields. Since, I never entered or edited the metadata I don’t know how or why those extra “chunks” would be included but this is the only clue I’ve got so I’m trying to see what the difference in headers between Wavelab .wav files and Audacity .wav files might be.

Thanks again for any and all help.
And a big shout out of thanks to PG. Its rare that in this day and age that users get to contact the main dev of a program and I try not to abuse that privilege. There may be gripes on forums about this feature or that but when push comes to shove, PG’s presence here is something no Wl user should take for granted.

Hooray to that indeed!

PG
I’m still researching this issue and came across this wiki page:
http://en.wikipedia.org/wiki/Resource_Interchange_File_Format

This sentence caught my attention:
“For instance, when the audio-editing program Audacity encounters a .WAV file with end-placed INFO data, it will correctly identify and read the data, but on saving, will relocate the INFO chunk back to the file header.”

Is it possible that Wavelab (and other commercially available audio applications) are writing the INFO chunk at the end of the .wav file? Because this would explain the errors my client is giving me.

Thanks,

Some meta data is sometimes written in front, sometimes at the end. All this is legal.
But i am pretty sure the suggestion i gave you will solve the problem (this is not the 1st time i see this case).

I’ve now got a client with exactly the same problem.
It’s dealing with samples for an Alesis SamplePad. I’ve converted the sample wave files to the required 16 Bit, Mono, 48kHz, and the Alesis refuses to use them stating that it is an invalid file format. I’ve even ensured that the file naming scheme is 8.3 standard file format just to eliminate that as a potential cause.
The aforementioned Header-Option is turned off.
The recommendation from Alesis is to use Audacity!

Your previous comment regarding header dat before as well as aft being “legal” is all well and fine, but Alesis’ definition (implementation) of just what a “Valid” file format is may be much narrower - and this indeed may be the crux of the problem.

(I know this is an old post but it was never resolved, and it would seem, still exists) :wink:

I’ve had exactly the same problem on a number of occasions. Wavelab cannot save a WAV file with exactly the same characteristics as a file saved using Audacity. Some older equipment and applications will not accept files which have been saved from Wavelab whereas they will accept the files saved from Audacity. Something about the header or the order of the data (as discussed above). It’s not the Create Optimised Audio Header option which causes this.

I’d say this is a likely explanation. Wavelab is certainly doing something differently to Audacity but of course is still doing it ‘legally’. Regardless of this, it would be excellent if PG could add an Audacity-compatible way of saving the file from Wavelab as this would avoid a lot of headaches, and make Wavelab more bulletproof.

I’ve had to go back to Audacity on a number of occasions which is disappointing. I’d prefer it if Wavelab could do the whole job, every time. Unfortunately, when clients find that files saved from Wavelab aren’t compatible they don’t blame the other application or older device they are using, they blame Wavelab and so Wavelab gets a bad name.

If you don’t use “create optimized headers” neither “RF64”, then WaveLab saves a wav file in the strict and minimal way. And I don’t see any difference with Audacity.

Did you check whether or not this works, wavcatcher? It would definitely be worth knowing, given this apparently isn’t an isolated thing.

Hi PG,
Of course, I trust your judgement 100%… but I have to ask, how do you explain BriHar’s example with the Alesis Samplepad?. Why does such a machine refuse the wave files saved from Wavelab but accept the wave files saved from Audacity? It’s logical to assume that there must be a difference. I would assume that BriHar tried saving the files without “create optimized headers” and “RF64” checked.

I would assume that BriHar tried saving the files without “create optimized headers” and “RF64” checked.

I would not assume this.

OK I checked and found that RF64 was indeed checked. Tried again after removing the check and it worked :smiley:
Thanks PG! (Edit: and you’re right - never “assume” anything) :wink:

I’ve set this up in a batch workspace and 3 of 4 files were processed correctly, one remained at 24bit. I’m trying to check and see why it didn’t process the last one. I have three plugins, Stereo > Mono, Crystal Resampler (set to 48Khz - Std) and UV22 set to 16 Bit - Hi - in that order.

I’ll have to check the specs for the original files, but is there any condition that would cause the last process in the chain to be ignored by a given wav-file?

I know that some of the files are 48Khz already while others are 44.1 and some are already 16 Bit while most are 24.
If I put a 48kHz file in I would assume that the resampler would just ignore it, but would it also cause the remain steps in the chain to ignore that file?

ignored or error?
You could try to process it via the Master Section directly to see maybe more details.

Of course PG you’re right. I should not have assumed either.

Thanks BriHar for checking this out. I’ll check my own cases from the past to see if the RF64 option makes a difference.