Ok, I'm happy. Happy that my huge library is backup up with Wavpack and that none of the Broadcast WAV data chunks(or any other chunks for that matter) are lost during compression and decompression. Everything's perfect.

I'm attempting to gain support for Wavpack files in some professional audio databases. Answers have yet to come in from those folks, but since Wavpack doesn't touch the metadata it's probably the best option, apart from being fast, free and portable.

Here's the idea.

Upon compression the Description field, along with any other fields in the bwav chunk would be copied in to the APE tag(or whatever it uses).

It is an assumption of mine, that the bwav chunk is harder to access in Wavpack files than tags, which is why a tag containing that information could be what database software could index more easily. Most databases already do this for MP3 files and their ID3 tags.

So the encoder would detect the BWAV chunks in the WAV files and copy its contents to tag fields. The encoder or a seperate program could also check Wavpack files for bwav chunks and write the tag in to the Wavpack file, or delegate that job to 'tag.exe'.

The specs are easy to find via googling for 'broadcast wav specification' , but I'm just probing here, since the database people haven't gotten back to me yet.

What are the benefits you may ask?

Large libraries are kept on large hard disks and tapes. Whenever they're on anything but tape, a Wavpack file with a tag like this, and with support for that from the database apps, would be instantly available for use in a library app like Soundminer, Netmix or Basehead.

Like I said, it's just a probe to see if it's possible and if anyone wants to actualy do this. How much work would this be for you David, and are you interested at ALL in trying this ?

It's only been four years or so since I asked for keeping data chunks in WAV files alive .

Take care
Tony

-edit-
The chunk is acutaly called 'bext' , not bwav. Sorry.

Hi Tony,

Hehe. Just the other day I got an e-mail from someone who agreed with Josh that lossless audio compressors shouldn't store extra RIFF chunks and wanted an option for WavPack to skip them. His argument actually made sense and I think I may throw it in (but as an option).

I took a look at the "bext" chunk. It's not too bad, but it does have some binary data which is not super easy to put in APE tags, but I think it could work okay.

I don't know much about how databases work; perhaps they would be able to parse a WavPack file as easily as an APE tag. Another possibility would be to leave the RIFF data in the WavPack file and I could add an option to wvunpack that would unpack just the RIFF stuff and leave off the audio (kind of the opposite of the current -r). Then a program that already knew how to parse wav files could get their information out quickly.

Anyway, these are my first thoughts. I am always willing to explore new uses for WavPack and I don't think that anything mentioned here would be too difficult. Let me know how things go.

Thanks,

David