Wave64 . . . what is it?

Caruso wrote on 2/16/2002, 5:35 AM
I am in the process of restoring some vinyl recordings. I have already dubbed these recordings from my turntable to DAT, and have usually used WaveLab 3.0 as my program of choice to capture them onto my computer.

I decided to try VegasVideo 3.0 this morning. I opened a new project, inserted an audio track onto the timeline, armed it, recorded two hours worth of music. Vegas names the resultant file a wav, but it won't open in WaveLab (invald format), and, when I vew the file via MS Explorer, it is described as a WAVE64. In order to use the file outside of Vegas, I have to first render it to a Windows Wave file (no big deal, mind you, just an added step).

My questions:
What is a Wave64, and how does it differ from a Microsoft wav?
Is there more or less fidelity contained in the wave64 (or is there no difference)?
Is there a way to record in Vegas so as to avoid the requirement to render as an MSwav?

Is there a way to destructively trim portions of files recorded with Vegas (I generally set my computer to record over night and come back to a 6-hour file). WaveLab allows me to set stop points (based on silence or session duration), and, of course, if I delete a section in WL and save, the deleted portion is destructively deleted.

For now, I'm selecting the 2-hour portion I want to save, rendering to MS Wav, then, deleting the original 6-hour file entirely.

Just wonder if there is a better way.

Thanks for any replies.

Caruso

Comments

MarkWWW wrote on 2/16/2002, 8:18 AM
> What is a Wave64, and how does it differ from a Microsoft wav?

Sonic Foundry don't seem to have published the file format of .W64 as far as I can see - they just say that it is a proprietary format that gets round the maximum file size limitations inherent in the standard .WAV format.

But if you compare the headers of a section of audio saved as a .WAV with the same section of audio saved as a .W64 you can pretty easily see what they have done, and it makes a good deal of sense. The important part is that they have taken the standard .WAV format and modified it so that the size of each chunk is now given by a 64-bit value rather than the 32-bit value that the standard .WAV format specifies. This means that a .W64 file can store a much longer section of audio than .WAV can manage.

(There are a few other differences too, like the fact that the some of the chunk IDs (RIFF, WAVE) are now in lower case (riff, wave), the chunk IDs all seem to be padded out to 16 bytes in length rather than just 4 bytes, and the fact that the size fields of each chunk now seem to include the total size of the chunk rather than the length of the chunk remaining (i.e. excluding the ID and size fields) as it does with the .WAV format. There may be some other differences I haven't discerned too, of course, and I'm not sure if the padding in the chunk IDs is meaningful or just garbage, but that's the situation as it looks to me.)

> Is there more or less fidelity contained in the wave64 (or is there no difference)?

The actual audio data in the data chunk is identical as far as I can see. W64 seems to use the same scheme as .WAV's fmt chunk for defining what format the audio data is in and how it is represented, so the there is no difference whatsoever in the fidelity of the audio when stored as a .WAV or as a .W64.

A quick calculation using 16-bit PCM stereo 48kHz audio (i.e. 4 bytes per sample frame) will show that the longest section of audio representable in the conventional .WAV format will be a bit more than 3 hours long. This is long enough for most purposes, but there may be occasions when you need more. The .W64 format will allow for 2^32 times as long a section of audio to be stored in a single file, which I reckon works out to about one and a half million years. Should be sufficient, I suppose. :-)

All the above is subject to correction by SoFo, of course - it would be nice to have their word on the subject, and also some technical detail on the .PCA (perfect clarity audio) format too.

Mark
Caruso wrote on 2/16/2002, 4:17 PM
Mark:
Thanks for the detailed explanation.

Caruso
MacMoney wrote on 2/16/2002, 6:47 PM
"All the above is subject to correction by SoFo, of course - it would be nice to have their word on the subject, and also some technical detail on the .PCA (perfect clarity audio) format too.

Mark"

Thanks Mark
for the info on Wave64 .PCA is Sonic Foundry's answer to MP3 audio, but with better audio fidelity. But I think? SF is the only one who suppoerts it. Peter or Ted can you help me out on this?

George Ware
nlamartina wrote on 2/16/2002, 6:50 PM
Caruso,

There's actually a setting in Vegas that you can change so that it doesn't render excessive files as W64:

1. Go to the "Options" menu.
2. Click "Preferences".
3. In the "General" tab, scroll down through the list of options. There will be one that says, "Render large Wave files as Wave64." Enable or disable according to your preference.

Hope this helps,
Nick LaMartina
Caruso wrote on 2/17/2002, 4:41 AM
nla:
One of the questions I raised was: 'Is there a way to record in Vegas so as to avoid the requirement to render as an MSwav?'

Your post just answered that question for me. Thank you.

Caruso
Sonic_Curt wrote on 2/17/2002, 7:41 AM
Mark made some pretty good deductions.. here's some more detail:

Wave64 is in fact a file format for audio that gets beyond file size limitations of standard .wav files. Sonic Foundry software will use .w64 when the size of the file would exceed 2GB (minus a little for good measure). In theory, a .wav file could store up to 4GB (it uses 32-bit values for size), but a lot of software would not handle it correctly (they treat them as 'signed' values giving roughly +/- 2GB)... so we chose to create a file format that did not have these limitations.

As for details of the .w64 file format, I plan to publish that sometime.. but briefly, all chunk identifiers and sizes are 64-bits in size allowing extremely large files to be created. The chunk identifiers are actually GUIDs (globally unique identifiers) with 4 bytes of the GUID tweaked to represent lower case 'wave', 'riff', etc. This is what Mark is seeing when he 'dumps' the file. This was not necessary, but makes it easy to identify in a similar manner to what Mark did...

The 'garbage' that Mark noticed is not garbage... <g> It's the remainder of the GUID. Additionally, in a similar way to standard 'RIFF 16' (.wav, .avi, etc.), all chunks are padded to be 64-bit aligned (rather than 16-bit alignment). This can provide some efficiencies for memory mapping and other 'alignment' issues..

The 'data' in a Wave 64 file is _identical_ to standard .wav files. There is absolutely no quality difference.

Now for PCA... It stands for Perfect Clarity Audio and is a _lossless_ audio compression format. That is, it will represent the compressed audio data perfectly (unlike MP3, Windows Media, etc.). This is true no matter how many times you compress or decompress it. It will always be perfect.

PCA is not Sonic Foundry's answer to MP3 (sorry George <g>). It was designed for archival purposes. The compression ratio is usually between 2:1 and 5:1 (if you're lucky). This is far less than the ~11:1 for 128 Kbps MP3 (from 44.1 kHz). But it still saves disk space and has some very special characteristics:

1. It's lossless and can be without concern about audio degradation.
2. You can edit PCA just like .wav files (in Sonic Foundry apps)
3. It is very fast for compression and decompression allowing it to work reasonably efficiently in multitrack scenarious (that is, you don't have to 'convert' it first)

-curt.
MacMoney wrote on 2/17/2002, 8:05 AM
Thanks Curt.
A while back I was talking to someone about .PCA and I wanted to use it to convert a very large session on Vegas to .PCA and the person told me because of the de-compression scheme it would not playback well as wave. Am I wrong on this? I never tried it.

George
MarkWWW wrote on 2/17/2002, 8:16 AM
There have been some confusing statements in here from SoFo about .PCA - some SoFo people have said that it is lossless (i.e. converting the file back to an uncompressed .WAV would result in the exact same audio data being restored) like Shorten, WaveZip, etc, while others have said that it is "perceptually lossless" (i.e. converting it back to an uncompressed .WAV will not give back identical data, but merely something the human ear cannot distinguish from the original) like a very high bitrate MP3.

In my own investgations I have never found a situation where the result of uncompressing a .PCA file is not identical to the original .WAV file (as far as the audio goes anyway - some of the less important chunks do not get preserved) so as far as I can see it is a genuine lossless compression scheme. The fairly modest amount of compression it achieves suggests this too - it is rarely possible to losslessly compress audio by a factor of more than about 2. WaveZip and Shorten both achieve about the same level of compression.

But in the absence of any proper technical information from SoFo it's hard to be certain. And without a standalone .PCA compressor (or at least a standalone decompressor) it's impossible to use the PCA format for exchanging files with people who don't use one or other of the SoFo products, which means that if one wants to use a lossless compressor for this kind of file exchange one has to stick to one of the established alternatives - WaveZip, Shorten, etc.

SoFo have used the .PCA format to allow a larger number of sound effects to be squeezed onto the Vegas Content CD than would otherwise be possible, but I haven't come across its use anywhere else.

Mark
MarkWWW wrote on 2/17/2002, 8:37 AM
Ah, thanks Curt, that makes sense - I should have spotted that the padded chunk IDs were actually modified GUIDs.

Thanks also for the information on .PCA format. Please ignore my previous message which I posted before I read your reply - our messages crossed in the ether.

It does indeed seem faster to compress/decompress .PCA than Shorten or WaveZip, but seems to achieve about the same compression ratios.

I know that Shorten uses a cunning plan whereby it first compresses the file by a variant of ADPCM (very high compression rate at the expense of poor fidelity) and then uses a standard compression scheme (Huffman?) to compress the difference between ADPCM file and the original. The Shorten file contains the ADPCM and the Huffman-compressed error signal, possibly interlaced in a series of short blocks. It surprises me that this approach works, but evidently it does. I don't suppose you'd be prepared to explain how .PCA works at this sort of hand-waving technical level? Purely for my own interest of course, and I'd quite understand if you need to keep it secret.

I still think a standalone .PCA compressor (or at least decompressor) would be a helpful in getting the .PCA format more widely known and used.

Mark
Sonic_Curt wrote on 2/17/2002, 9:07 AM
It is true that using PCA files is not as 'efficient' as using uncompressed .wav or .w64 files. This is because there is a small amount of decompression overhead. In addition, there is a difference in how efficiently Vegas can read PCA files compared to .wav.

That being said, PCA is still significantly more efficient than MP3 or WMA or whatever...

Technically, you will not be able to play back as many PCA files simultaneously as you could with .wav or .w64. However, I've never profiled it. You should be able to get quite a few PCA files playing back without problems...

But understand that I'm not advocating using PCA exclusively... only that if you have PCA files sitting around (perhaps you archived them or are using a PCA compressed sound library...), you don't need to convert them to .wav/.w64 before using them. If you are running into performance problems, then you might get a little gain by converting them to .wav/.w64 first (but I wouldn't waste the time doing that until you start seeing problems).

-curt.
Sonic_Curt wrote on 2/17/2002, 9:11 AM
When I get a chance, I'll pull some sort of FAQ together about PCA. I don't mind publishing 'hand waving' technical details. You just won't see the code. <g>

As for a standalone PCA compressor/decompressor... we have one called Batch Converter available for a nominal fee. <g>

-curt.
MacMoney wrote on 2/17/2002, 12:06 PM
Thanks again
For clearing that up for me
George

BTW Curt do you work for SF?
Sonic_Curt wrote on 2/17/2002, 1:36 PM
"BTW Curt do you work for SF?"

very much so... <g>

-curt.
Cheesehole wrote on 2/17/2002, 5:27 PM
you're right... i was told by a SoFo employee that PCA is only 'perceptually lossless' like AVI RAW.

i think we can assume that was bad info.
Sonic_Curt wrote on 2/17/2002, 6:10 PM
I'm sure the incorrect info about PCA was not intentional.. remember, Sonic Foundry does a lot of very technical stuff and keeping on top of everything is very difficult. I remember when I worked at Microsoft as a developer in Multimedia Systems, I constantly got questions about Word and Excel at conferences I attended. Apparently, everyone who works at Microsoft should know all about these products. <g> Of course, I knew nothing...

PCA is perfectly lossless. That's the main reason the compression ratio varies based on content.. and that it is far less than 'lossy' codecs because PCA cannot (by design) throw anything away.

-curt.
MacMoney wrote on 2/17/2002, 6:40 PM
Curt Do you know Billy Townes? from El Paso?

George Ware
Chienworks wrote on 2/17/2002, 7:39 PM
Cheesehole, lemme wave my hand here and take responsibility for that erroneous information. I'm the one who started that whole "perceptually lossless" thing (and no, i'm not an SF employee ... but where do i fill out an application? ;) )

I was writing out a diatribe about how lossless audio compression couldn't possibly get better than 5:1 and in my newbie days confused PCA with MP3 in my explanation. Sonic EPM posted a reply in which he agreed, but apparently he was agreeing with my explanation and not with the file types.

So, my apologies if i've led anyone astray.
barleycorn wrote on 2/19/2002, 5:52 AM
> Curt do you work for SF?

SF works for Curt.

'Curtis J. Palmer has been our Chief Technology Officer since January 1997 and a Director since February 1994. Mr. Palmer is a recognized technology visionary who oversees the Company's engineering and advanced research efforts. Serving as the primary architect for the Company's full product line offering, Mr. Palmer is instrumental in maintaining an advanced market position for the Company's technology offering. Prior to joining the Company, Mr. Palmer served in various engineering capacities for Microsoft in the Multimedia Technologies group, where he worked on Windows operating system support for multimedia applications, responsible for assisting third party Windows driver developers in their development of communications, network and drivers for Windows. Mr. Palmer studied software engineering at the Oregon Institute of Technology. Mr. Palmer is a co-founder of the Company.'

I'll spare him disclosure of his remuneration and shareholdings!