Hi. We recently added a fair amount of metadata support to REAPER, but we haven't done anything with wavpack yet, because it wasn't immediately clear what the most useful format would be.
Presumably it's pointless to embed native WAV metadata chunks, like CART or especially LIST/INFO. http://www.wavpack.com/wavpack_doc.html refers to APEv2 and "sometimes" ID3v1 tags. Do we know what applications can decode these tags, besides the wavpack native utilities?
Er, never mind. Looking at the actual wavpack code it's clear that APEv2 is what to use.
Yes, APEv2 is the way to go. You can either use libwavpack to read and write them, or simply handle it yourself if you already have a APEv2 library that you use. Please let me know if you run into any trouble.
Thanks again for the ongoing WavPack support in Reaper! :)
That was ridiculously easy, I feel silly for posting the question now 😃 The next REAPER build will support reading and writing APEv2 metadata for Wavpack files.
This is done for REAPER 6.11+dev0525 and later. If anyone has expert feedback, it would be helpful during the prerelease cycle!
I installed 0527 and experimented with reading and writing of tags on WavPack files, especially long ones (like cuesheets) and ones using funny characters (to test UTF-8 handling). Everything worked fine; great job!
I did notice one thing though. I could tell by the stream revision of the files written that you guys are probably using WavpackSetConfiguration() instead of the newer WavpackSetConfiguration64(). Certainly not a big deal, but what it means is that the "mono optimization" mode is not being used, which is check made when encoding each stereo block to make sure it's not actually just dual mono, in which case it's encoded more efficiently (transparent to everything else, obviously). This doesn't come up often (and even some mono CDs don't have identical channels because they used a stereo ADC) but it might come up sometimes with artificial stereo tracks. Again, it's totally not a big deal, but it might be worth updating to the newer API at some point. If you do, be sure to set the chan_ids parameter to NULL.
APEv2 is a pleasingly simple/flexible tag format and we'd kind of like to support it for regular 32-bit chunky file formats, while recognizing that hardly anyone else will be able to read the data. Is there a canonical 4-byte identifier?
It has a fixed size footer that contains an identifiable signature and the size of the actual tag chunk, but it's slightly more than 4 bytes. 8 bytes for the signature, I believe? Because I'm remembering the signature of "APETAGEX". Don't take my word for it immediately, since I'm just typing this from memory, best to look at the specification.
I'm familiar with the specification 😃. To embed the tag in a standard 32-bit chunky format like .wav or .aiff, it needs a 4-byte identifier that is not part of the APEv2 specification itself. Often these identifiers become canonical based on community use, so I'm asking this community if they are aware of any application embedding APEv2 like this and what 4-byte identifier they might use. "APE2" seems reasonable if there isn't anything canonical, or maybe "APET" based on the 8-byte identifier.
I don't know of any application that has put APEv2 tags in a chunked format. I don't have contact with Frank, but I asked Matt and he hasn't done this or heard of it either.
It seems like a reasonable thing to do for your own purposes, but obviously nothing else will recognize it (at least right away). I assume by now most applications will know how to skip them... :)
And yeah, either APE2 or APET would work and Matt has no preference. Maybe even APTG.
hardly anyone else will be able to read the data.
As long as the tag chunk comes the very last in the file, some generic music programs might be able to read it from WAV: old Foobar, Frontah, XmPlay. It should have become canonical instead of 'id3' with its 4-letter codes.
foobar2000 won't read it, because each input handles its own tags.
Cog won't read it, because the TagLib reader isn't designed for reading footer tags off every single arbitrary format, only formats that are known to have such footer tags.
Having now spent a few weeks adding metadata support for all kinds of file formats, I am really impressed/depressed by what a mess the domain is. It's not unusual to come across an isrc code embedded in axml embedded in bwf embedded in ixml embedded in a flac file. The same file may also contain an isrc code embedded in a vorbis comment that may or may not match the other isrc code, depending on which applications have handled the file during its lifespan.
Given the input from this forum above, we didn't bother with embedding APEv2 in anything other than wavpack and mp3 files. We added some generic attribute=value metadata support as a front end that maps to various specifications including APEv2 depending on the target file format.
It's not scientific but we have an ongoing poll or REAPER users asking what file formats they work with most often. Here are the current results (users could choose multiple formats; the numbers are percentage of respondents who use that format). Compared to my priors, I was surprised at the strong showing for flac.
Thanks for sharing this. I was actually a little surprised by the relatively poor showing of WavPack because it seems to be recommended often in the forums as a working format in Reaper because of the low encoding CPU use and the FP32 support.
But obviously WavPack's relative lack of support outside Reaper makes it less suitable for final mixdowns or distribution, so FLAC's popularity makes a lot of sense there.