-something that's not in the doc either: if you read the header (before the data), then the trailer will be just that, the trailer. But if you don't read the header, then the trailer will ALSO contain the header. Which is a good thing, it's easier that way. It just doesn't seem to be documented.
I suppose that extra info should normally be stored in tags, and it would be pretty easy technically, but it's hard to get everyone agree on tags. So, standard wav chunks that everyone can read still beat proprietary sampler/markers tags.
You might be able to get away with not having to create the RIFF data that comes before the audio data because the library will do that for you, and then you can simply use WavpackAddWrapper() at the end to append trailing stuff.
There is currently a minor bug associated with this that the length field of the initial RIFF chunk at the very beginning of the file does not get updated with the full file length
I am working on a system for 3rd party applications to store proprietary information in dedicated metadata ids inside the WavPack file
Quote from: bryant on 11 August, 2009, 05:51:17 PMYou might be able to get away with not having to create the RIFF data that comes before the audio data because the library will do that for you, and then you can simply use WavpackAddWrapper() at the end to append trailing stuff.Are you sure? Because it's the first thing I tried. I basically only added the trailer data, nothing up to the data chunk. And my own reader didn't have a problem loading the encoded files, but the command line unpacker did not restore those chunks in a readable way.It may be the bug you mention, but then wvunpack.exe is affected by it as well.
Quote from: bryant on 11 August, 2009, 05:51:17 PMI am working on a system for 3rd party applications to store proprietary information in dedicated metadata ids inside the WavPack fileWhat do you mean, doesn't the DLL already allow this? I mean, through ID3v1 tags? I know there's a standard list of such tags, but is it really restricted?
The final method is basically a hybrid of these two
The minor bug in this that I mentioned is that the length field in the RIFF header that represents the length of the entire file
BTW, thanks for adding WavPack support to your application (whatever it is)...
Quote from: bryant on 12 August, 2009, 03:23:12 PMThe final method is basically a hybrid of these twoYes, what I initially tried, and it didn't work but maybe I did it wrong(I think I do use that chunk length in my parser btw)
Just to be sure: the "length of the entire file" should be the length of the (virtual) wav file, not the wavpack file, right? I mean, WvUnpack doesn't modify that length when unpacking, right?
Well, thanks for WavPack. We're most likely gonna use it to compress samples that come with FL Studio, and let users pack smaller songs to share through the net. We've been relying on OGG (actually OGG as ACM codec) for this so far, but looped samples & sliced/marked samples in general don't survive lossy compression very well.(talking about this, what'd be really interesting for us would be a lossless/lossy hybrid with lossess compression happening only for specific regions, like around loop points & markers. But that's another story)